Product managers must effectively understand when and how to reject stakeholder demands while maintaining an open and innovative culture to execute product strategy effectively. How to do this is as follows.

Achieving excellence in product development involves finding and focusing on the mystical intersection of attractiveness, feasibility, and viability—the place where creativity thrives. Product managers are continuously defending the balance between these areas, opposing pressures that want to push a product too far in one way at the cost of the others. This requires saying no many times and to numerous individuals during the product development process.

Earlier in your career, you worked on an automobile project, creating an app that utilized machine learning to offer intelligent recommendations to drivers based on environmental data and user behavior. When you joined the team, the app was nearing completion, and management was anxious to deploy it, but you quickly saw that it was far from production-ready.

While the app was aesthetically attractive, it lacked answers to some of the most basic design concerns, such as “What issue are we addressing and for whom?” and “How desperate are people to find a solution to this problem?”

The app had a function that displayed the current weather conditions at the driver’s location. The system could deduce a driver’s intended destination and estimate travel time based on user behavior and traffic data. A simple weather API interface displayed the destination’s weather prediction at the time of arrival. This appeared to be an appropriate application, but in fact, no one was interested. When you performed your user research, which included a sponsored poll of European drivers, the overwhelming answer was “Meh.” That is probably the worst possible feedback: This implies that your solution addressed an unimportant issue, and its attractiveness is very low. Therefore, its viability is a non-starter: creating a successful business around a product no one wants is challenging. You were forced to abandon the whole project.

Effective product strategy entails declining new ideas that threaten to upset the delicate balance of product attractiveness, practicality, and viability.

How did this happen? The solution is complex but ultimately comes down to one crucial word not being said when it should have been: No.

Machine-learning inference engines and highly scalable architectural designs were the company’s key competencies and assets. The head of data science was a significant stakeholder who wanted to see his inference engines used effectively in a client application. His influence, in part, resulted in a purely technological product. Instead of focusing on what consumers wanted, development was driven by technical feasibility.

Nobody seemed to have told this stakeholder no, and if they did, it was ineffective.

Saying No to Products Is Part of Product Strategy

It’s difficult to say no. Individuals do not always like hearing the term, and there is often a concern that using it may jeopardize critical connections. Relationships are essential to your job as a product manager but ensure that your products are successful and balanced.

Thus, how can you decline someone’s request while maintaining the relationship? You endorse the following practices:

• Create a favorable environment for success;
• Avoid a hasty refusal;
• Change the request’s context;
• Contribute to the development of participatory culture; and
• Prepare Yourself for Success

At the outset of a project, all stakeholders must agree on a shared vision for the success of the product (“Why are we doing this?”) and on a framework of performance metrics (“How will we know whether we’re doing it right?”). Conflict is unavoidable if you and your colleagues cannot agree on what defines success.

It’s beneficial to utilize a framework to record objectives and associate them with something quantifiable. For example, you like to use a simplified version of the HEART framework, which divides user experience into areas such as Happiness, Engagement, Adoption, Retention, and task success. Then, you can then articulate objectives, signals, and metrics for each of those categories. Goals define what you’re attempting to accomplish, calls break down each goal into user actions, and metrics monitor those actions to provide quantitative feedback on your performance.

You intended to run a small pilot on a recent consumer app project to see if consumers found your prototype helpful and want to continue engaging with it; you were mainly concerned with the Engagement category of the HEART architecture. You next needed to select indicators and measures that would allow you to monitor my progress toward that goal:

• Users want to engage with and continue using the app;
• Signal: Users often open the app; and
• Percentage of users that open the app at least twice a day

While the process of defining and agreeing on objectives may seem straightforward, it is not. This instance included client and sales team conversations, independent research, and numerous team sessions. You presented the entire HEART framework to the client at the launch meeting using the knowledge gleaned from this discovery. Look through each item and make necessary adjustments.



HEART Framework

Happiness: Subjective elements of the user experience, such as contentment, aesthetic appeal, recommend ability, and perceived ease of use.

Engagement: The level of commitment someone has to a product, as measured by behavioral proxies such as the frequency, intensity, or depth of employment during a specific period.

Adoption: The number of new consumers who begin utilizing a product within a specific period.

Retention: The percentage of users from a specific period still present in a subsequent time.

Task Success: Comprises many established behavioral measures for user experience, including efficiency (e.g., the time required to complete a task), effectiveness (e.g., percentage of jobs completed), and mistake rate.

Engaging all stakeholders in the goal-setting process is essential. Everyone must agree that the signals and metrics should be monitored to remove the need to say no again as a project advances. Additionally, it provides facts to refer to whenever someone approaches you with a request that deviates from the plan’s criteria.

Avoid Saying No More Frequently

Even if all stakeholders agree on the definition of success and the path forward seems obvious, one thing is sure: Someone, somewhere, will approach you with an unexpected request.

When this occurs, avoid saying no too fast. Even if you are convinced the request is ridiculous, flatly rejecting it ends the discussion and may sour the connection. Additionally, it hinders the process of product discovery. As product managers, you need a holistic view, and listening to those who disagree with you helps narrow your blind spots.

You may still say no, but you must avoid knee-jerk reactions. These conversations devolve into binary ones due to black-and-white, right-or-wrong, win-or-lose thinking: Either you put something in place or don’t.

To facilitate more productive and nuanced conversations, you must arrange requests according to the agreed-upon criteria established throughout the goal-setting process.

Instead of asking a stakeholder, “Do you value this feature?” “How important is this feature to you?” The ensuing discussion should provide you with the knowledge necessary to agree on a prioritized list of “wants.” This rating must be between 1 and n, without enabling several things to occupy the same position in the hierarchy. This involves everyone in the prioritizing process and eliminates the need to reject proposals unilaterally. Instead, specific requests will be shelved in favor of more pressing ones as the group prioritizes them.

Request Restructuring

With some modest reengineering, an initially absurd request may produce good outcomes. To begin, pay attention to what is being stated. Take time to listen. Set your preconceptions aside and attempt to comprehend the other person’s perspective before establishing common ground. If you go a bit further by asking “Why”—not necessarily the five times you’ve heard it; two to three times is usually sufficient—you may discover a component indicating a common objective.

Even the most logical request may benefit from a deeper investigation and rephrasing. For example, you recall working on a business intelligence product for a B2B mobility service. Unexpectedly, your customer requested that you increase subscription numbers. While the motive for expanding the number of paying subscribers may seem self-evident, you wanted to be sure you were getting the whole picture, so you asked, “Why?”

As it turned out, the product in issue was nearing the end of its life cycle, and your customer wanted to wring every last drop of profit out of it before replacing it with a new one. So, with this knowledge in hand, you restructure the request as “How can we significantly boost income in the short period while simultaneously laying the groundwork for the future product launch?”

Ultimately, the best option was to ignore subscription counts entirely and instead focus on better aligning price with value. Customers were previously charged a flat monthly fee regardless of how often they utilized the service for rider transactions. However, the more rider transactions they completed, the more value the tool provided. Customers varied from individual cab drivers who had a few transactions per month to multinational freight companies with dozens of subsidiaries and thousands of vehicles that conducted hundreds of thousands of transactions each month. The same monthly membership set was prohibitively expensive for small customers and cheap for large clients.

It boosted revenue by making minor price changes while taking baby steps toward a tiered pricing system (depending on the number of transactions) for the soon-to-be-released product. The new approach lowered prices for most consumers while raising them for the largest, who had previously benefited disproportionately.

By rephrasing requests in this manner, you may create win-win scenarios. The requester feels heard and appreciated, and you get valuable information without jeopardizing the product development process.

Encourage a Contribution-Oriented Environment

One of the most serious risks of saying no is that rejections may damage the atmosphere of openness and cooperation you’re attempting to create both inside and beyond your organization. Ideas inspire, regardless of their relevance, and the last thing you want to do is stifle creativity and communication.

You once worked with a young quality assurance engineer brimming with ideas. He asked many questions and offered recommendations at almost every meeting. Unfortunately, his remedies were often ineffective, and some of them might have been regarded as irrelevant or useless. However, his dedication and passion were priceless. He was utterly committed to producing the most refined product possible, and his efforts energized and encouraged others. Such an attitude is infectious.

You want to foster an atmosphere where individuals are encouraged and rewarded for sharing their views and ideas. Your team should be driven by the prospect of improvement, not by the possibility of being rejected, ignored, or mocked. By implementing a few basic measures, you may guarantee your team’s psychological safety.

Publicly acknowledge ideas and requests. This establishes trust and demonstrates that you appreciate and are dedicated to evaluating assertions. Create a request box, a Confluence page, or another public venue accessible to all stakeholders when a request is received. Log in and send a message to the requester expressing gratitude for their assistance.

You understand this may be contentious, but you sometimes go so far as to expose the product backlog to everyone. This is especially beneficial for increasing product team involvement and enabling team members such as QA testers and designers to document issues they find. The rules are straightforward: Anyone may contribute to the backlog’s conclusion, and team members discuss what they’ve contributed and why during refinements (or other weekly meetings). Only the product manager can rearrange or remove problems. Many people believe that giving this degree of access to everyone would result in chaos and anarchy, yet this is not the case. You’ve done this in organizations of all sizes, and it only works when individuals are afraid to offer their thoughts.

If you develop a solution or release a feature that is even remotely linked to one of these recorded requests, publicly acknowledge the requester. This is particularly true when the answer is not a direct fulfillment of the original request but rather a reframed version. Demonstrating gratitude for all those who contributed to an accomplishment fosters goodwill, fosters camaraderie, and motivates individuals to continue engaging.

Weighing the Benefits and Drawbacks of Saying No

If you take the time to listen and comprehend stakeholders’ perspectives, you will seldom need to reject ideas outright. Active listening, open communication, and mutual respect are critical components of successfully managing requests that first seem difficult or out of scope. Frequently, the skill of expressing no does not need the use of the word “No.”

There may be times when finding common ground becomes impossible, and a firm no is needed to preserve the product and the project. In other instances, you may be forced to carry out actions you disagree with. While it is your responsibility to balance attractiveness, feasibility, and viability, a fourth factor must be considered: pragmatism. Compromise is necessary to keep things going ahead, and sometimes it means avoiding a no entirely.

Agile product development’s attractiveness is that its iterative nature provides many chances for course correction. After all, the objective is to construct-measure-learn, not to argue-dispute-derail.