Stakeholder Management: The Art of Saying No

Good product development requires identifying and homing in on the magical overlap between desirability, feasibility, and viability—where innovation lives. Product managers are constantly in the position of having to defend the balance among these domains, countering the forces that compete to pull a product too far in one direction at the expense of the others. This means saying no—many times and to many people—over the course of the product development journey.

Earlier in my career, I worked on a project in the automotive space, developing an app that used machine learning informed by environmental data and user behavior to provide smart suggestions to drivers. At the time I joined the team, the app was poised for launch and management was eager to release it, but I soon realized that it was far from ready for production.

While the app was visually appealing, some of the most fundamental design questions had been ignored, such as “What problem are we solving, and for whom?” and “How desperate are people to have this problem solved?”

The app boasted a feature that would display the weather at the driver’s destination. From user habits and traffic data, the algorithm could infer where a driver might be headed and how long it would take to get there, and a simple weather API integration showed the weather forecast for the destination at the time of arrival. This seemed like a nice use case, but in reality, no one cared. When I conducted my own user research, including a paid survey of European drivers, the response was a resounding “Meh.” That is arguably the worst feedback you can get: It means your product solved an irrelevant problem and indicates that the desirability dimension is extremely low. Viability is then a lost cause: It’s impossible to build a viable business with a product no one wants. We had to scrap the whole thing.

How could this have happened? The answer is complicated, but it boils down to the fact that a critical word wasn’t uttered when it should have been: No.

The company’s core competency and assets were machine-learning inference engines and highly scalable architecture design. The head of data science was a powerful stakeholder who wanted to see his inference engines put to good use in a customer application. His influence, in part, had resulted in a product that was completely tech-centric. Development had been driven by what was feasible technologically instead of what customers desired.

It seemed that nobody had told this stakeholder no, and if they had tried, it hadn’t been effective.

Product Strategy Means Saying No

Saying no is hard. People don’t always like hearing the word, and there is often a fear that saying it will damage important relationships. As product managers, relationships are central to our role, but so is ensuring that our products are successful and remain in balance.

So, how do you reject someone’s request while keeping the relationship intact? I recommend these practices:

• Set yourself up for success.
• Don’t say no too quickly.
• Reframe the request.
• Encourage a climate of contribution.

Set Yourself Up for Success

At the outset of a project, it is essential that everyone agree on a shared vision for the product’s success (“Why are we doing this?”) and on a set of metrics that will be used to measure progress (“How will we know if we’re doing it well?”). If you don’t agree on what success looks like, it’s only a matter of time before conflicts arise.

It’s helpful to use a framework to document goals and map them to something measurable. I like to use a loose version of Google’s HEART framework, which organizes user experience into categories for Happiness, Engagement, Adoption, Retention, and Task Success, and then articulates goals, signals, and metrics for each of those categories. Goals address what you are trying to achieve, signals break down each goal into user actions, and metrics track those actions to gauge how you’re doing in a way that is quantifiable.

On one recent consumer app project, I wanted to conduct a limited pilot to determine if users found our prototype useful and wanted to keep interacting with it; I was focused primarily on the Engagement category of the HEART framework. I then had to identify signals and metrics to track progress toward that goal:

• Goal: Users want to interact with the app and continue using it.
• Signal: Users open the app frequently.
• Metric: Percentage of users who open the app at least twice per day.

This process of identifying and aligning on goals may appear simple, but it’s not easy. In this case, it involved calls with the client and our sales team, independent research, and multiple team workshops. Based on the information I gathered from this discovery, I was able to present the completed HEART framework during the kickoff meeting with the client. We went through all the items and adapted where needed.

Ensuring that all stakeholders are involved in the goal-setting process is critical, and getting everyone to agree on what signals and metrics need to be tracked eliminates the need to say no repeatedly as a project progresses. It also gives you data to point to if someone approaches you with a request that falls outside the parameters of the plan.

Don’t Say No Too Quickly

Even when key stakeholders agree on what success looks like and the road ahead seems clear, one thing is certain: Someone, somewhere, will approach you with an unforeseen ask.

When that happens, don’t say no too quickly. Even if you’re certain the request is unreasonable, rejecting it outright shuts down conversation and could damage the relationship. It also undermines the product discovery process. As product managers, we need to see the full picture, and listening to people who disagree with us reduces our blind spots.

You can still say no, of course, but you need to avoid knee-jerk responses. Those lead to binary discussions that are the result of black-and-white, right-or-wrong, win-or-lose thinking: Either you implement something or you don’t.

To move toward more effective, nuanced discussions, you need to organize requests according to the agreed-upon criteria you’ve established as part of your goal-setting process.

Instead of asking a stakeholder “Is this feature valuable to you?” ask “How valuable is this feature to you?” The resulting conversation should give you the information you need to collaborate on a list of “wants,” ordered in terms of importance. It is essential that this ranking range from 1 to n, without allowing several items to share the same place in the hierarchy. This gives everyone a voice in the prioritization process and excuses you from having to reject requests unilaterally. Some requests will fall by the wayside when the group downgrades them in favor of more important ones.

Reframe the Request

A request that seems unreasonable initially can yield positive results with some subtle reengineering. First, listen to what is being said. Really listen. Put your assumptions aside and try to understand where the other person is coming from, and then find common ground. If you dig a little deeper by asking “Why”—not necessarily the five times you’ve heard about; two to three will generally suffice—you might unearth a factor that speaks to a shared goal.

Even a perfectly sensible request can benefit from a deeper dive and bit of reframing. I remember a situation in which I was working on a business intelligence tool for a B2B mobility service. My client asked me, not unexpectedly, to get subscriber numbers up. While the motivation for increasing the number of paying subscribers may seem self-evident, I wanted to make sure I had the full picture, so I asked, “Why?”

It turned out that the product in question was approaching the end of its life cycle, and my client wanted to squeeze out the last drops of profit before replacing it with a new product. With this information, I reframed the request to “How might we considerably increase revenue in the short term while laying the groundwork for the upcoming product launch?”

Ultimately, the best solution was to not bother with subscriber numbers at all but to better align pricing with value. Customers had been paying a fixed monthly subscription, regardless of how often they used the tool for rider transactions. The more rider transactions they processed, however, the more value they derived from the tool. Customers ranged from individual taxi drivers making only a handful of monthly transactions to multinational freight carriers—with dozens of subsidiaries and thousands of vehicles—making hundreds of thousands of monthly transactions. The same fixed monthly subscription was too high for the small clients and too low for the big ones.

By making small pricing adjustments, we increased revenue while baby-stepping toward a tiered pricing structure (based on number of transactions) for the soon-to-be-released product. The new model reduced the price for most customers while increasing it for the biggest customers, who had been benefiting disproportionately.

By reframing requests in this way, you can create win-win situations. The person bringing forward the request feels heard and respected, and you gain insight that can add value without derailing the product development process.

Encourage a Climate of Contribution

One of the biggest risks of saying no is that rejections can undermine the spirit of openness and collaboration that you’re trying to foster, both inside and outside your team. Ideas inspire, whether or not they become relevant, and the last thing you want to do is stem the flow of creativity and communication.

I once worked with a junior QA engineer who had a wealth of ideas. At nearly every meeting he asked multiple questions and volunteered suggestions. His solutions were often not actionable ones, and some of them could have been dismissed as unhelpful or irrelevant. But his commitment and enthusiasm were invaluable. He was totally invested in delivering the best possible product, and his contributions energized and inspired others. An attitude like that is contagious.

You want to create an environment in which people feel encouraged to share thoughts and ideas, and are rewarded for doing so. Your team should be motivated by the possibility of improving things instead of discouraged by the thought of being dismissed, ignored, or ridiculed. Implementing a few simple practices can help ensure the psychological safety of your team.

Acknowledge ideas and requests publicly. This builds trust and shows that you value suggestions and are committed to considering them. Set up a request box, or a Confluence page or other public forum that all stakeholders can access. When a request comes in, log it and send a message to the requester, thanking them for their contribution.

I know this may prove controversial, but I sometimes go as far as to open the product backlog to everyone. This can be particularly helpful in fostering engagement from the product team, as well as allowing team members like QA testers and designers to note things they have encountered. The rules are simple: Anyone can add to the end of the backlog, and during refinements (or other weekly meetings) team members share what they’ve added and explain why. Only the product manager can change the order of issues or delete items. Many people assume that granting everyone this level of access will lead to chaos and anarchy, but it doesn’t. I’ve tried this at organizations of different sizes and it only fails when people are too shy to contribute their ideas.

Once you’ve implemented a solution or released a feature even roughly related to one of these logged requests, credit the requester publicly. This is especially important when the solution is not a clear fulfillment of the original request but more of a reframed version. Showing appreciation for everyone involved in a success creates goodwill, builds camaraderie, and encourages people to continue participating.

Weighing the Pros and Cons of Saying No

If you take the time to really listen and understand where stakeholders are coming from, you rarely need to reject proposals outright. Active listening, transparent communication, and mutual respect are key ingredients in handling requests that may initially seem problematic or out of scope. Most times, the art of saying no never actually involves saying “No.”

There will be situations in which it proves impossible to find common ground, and a direct no is required in order to protect the product and the project. In other cases, you may be compelled to follow through on things you don’t agree with. As much as your job is to protect the balance of desirability, feasibility, and viability, there’s a fourth dimension to consider: pragmatism. To keep things moving forward, compromise is key, and sometimes that means avoiding a no altogether.

The beauty of Agile product development is that its iterative nature offers many opportunities for course correction. After all, the goal is build-measure-learn, not debate-dispute-derail.