Saying “no” to various stakeholders, ideas, and requests is a routine part of every product manager’s job. To some extent, how good you are at saying “no” directly translates into how well you do your job as a product manager.
In this article, I’ll share my tips on how to say “no.” It’s part of the job — learning how to do it effectively is important to prevent anyone from wasting time or resources.
There’s this saying that a proper strategy is what you don’t do, rather than what you actually do. It makes sense.
In reality, there are always more pain points to be solved and opportunities to pursue than you possibly could tackle:
If you pursued all of them, you’d bury yourself in an unfocused catch-up game trying to make everyone happy. But your job is not to make everyone happy. It is to drive lasting business results.
Mastering how to reject unrelated requests that don’t contribute to your product strategy is essential to stay on track for long-term success.
The best thing you can do is to avoid situations when you have to say no in the first place.
You can do that by building transparency and understanding how things are decided and what you are focusing on and why, as well as by communicating with key stakeholders frequently.
Instead of telling people no, teach them how to filter their ideas before even approaching you.
You do that by:
Keep your roadmap and backlog transparent at all times.
This will reduce duplicate requests. When a stakeholder can see that a similar idea is already in the backlog, there’s a lower chance they’ll come to you with “a similar yet different” idea.
It also shows what you currently have on your plate. If you have five big yet valuable initiatives planned on your roadmap, it’ll be a signal to stakeholders that you won’t have time for their “nice-to-have” request.
If, on the other hand, you keep your roadmap for yourself, stakeholders might think that you are getting bored and longing for a bunch of new ideas from them.
Identify which stakeholders are most likely to bring you ideas and requests and stay in touch with them regularly.
Routine 1:1 meetings are a great tactic here. Try to have them at least once a month and more frequently with more engaged stakeholders.
Firstly, it’ll allow you to help them understand your product strategy. Regular catch-ups allow you to refresh your product strategy in stakeholders’ minds. By constantly reminding them of your strategy, direction, and goals, you frame their way of thinking and maximize the chances that their next pitch will be relevant to your goals.
It’ll also help you unpack ideas at an early stage. Touchpoints encourage stakeholders to share their ideas with you. And you want to hear them early on.
It allows you to collaborate with them and turn their ideas into more meaningful, strategy-related directions. If the concept is completely flawed, it gives you a chance to reject it early on.
On the other hand, if a stakeholder works on their “new game-changing idea” in their silo, they’ll grow attached over time, and you’ll have a significantly harder time rejecting these ideas later on.
Finally, having regular 1:1s with stakeholders will help you understand them and their perspectives. And the more you understand them, the better. You’ll be able to understand where their ideas come from and you’ll have an easier time redirecting or rejecting these ideas — you’ll know how to talk to the stakeholders, their pain points, and what they’re trying to achieve.
So you have a transparent roadmap and objectives and always stay in touch with key stakeholders. That should mitigate many unnecessary requests.
But plenty of them still will come. Before jumping to say “no,” first assess if you actually should say no:
The fact that something is not on your quarterly roadmap doesn’t necessarily mean it’s a bad idea. And you should not be scared of changing the plan if a new, more valuable opportunity arrives.
Every request that comes your way is, in reality, a need to be addressed. But it often comes hidden behind an overly specific feature request.
Don’t focus on the request. Focus on uncovering the underlying need and how you can solve that.
Say a stakeholder requests that you implement a new feature allowing users to chat with customer support. Instead of focusing on the feature, try to unpack where the request comes from. Why do they need that?
It might turn out that customer support is getting triple the number of request tickets and can’t keep up, so the chat would help ease their workload.
Now, take another step back and determine why there’s such a spike in customer support volume. When you dig deeper, you might discover that 70 percent of the tickets concern similar issues and that a new bug in the product causes the complaints.
Instead of implementing or rejecting the requested feature, you can now solve the underlying need by fixing the bug.
Ultimately, you catered to a stakeholder’s request, solved their pain point, and drove the product’s value without saying either “no” or “yes.”
Focus on problems stakeholders’ have, not feature requests they bring.
If you identified an underlying need and concluded that the feature requested is indeed the optimal solution to cater to the need, give it a shot.
Assess the potential of the newly proposed initiative by running it through your prioritization framework and see where it lands.
Best case scenario — You’ll discover that it’s indeed pivot-worthy, and you should adjust your product roadmap to drive even higher impact than you expected. It’s okay to change the plan if the request actually makes sense.
Worst case scenario — You’ll arm yourself with additional argumentation. There’s also a higher chance that the stakeholder will feel heard and respected since you assessed the idea rather than just rejecting it on the spot.
If you did all the previous steps and you…
…then saying “no” is the easy part.
All you need is to be transparent and honest.
Explain to the stakeholder what you are currently focusing on, how expensive the tradeoff would be, and your reasoning behind the decision. As long as you make the stakeholder feel heard and respected and give them solid argumentation behind the call, they should understand.
Please, don’t disrespect them by using the common PM tactic of saying, “I’ll put it in the backlog” if you don’t intend to pursue the idea any time soon. You only do yourself a disfavor and invite even tougher discussions in the future.
Sometimes, you might meet a stakeholder who is so attached to their idea or so pushy that reasoning doesn’t work.
Invite them to an additional coffee chat and try to unpack the request step-by-step. And if it doesn’t help, there are two things you can do: redirect them and do some lobbying.
If you don’t have the position to deal with them directly (for example, the stakeholder is a big fish in your company), redirect them to someone more senior.
There’s no point wasting your energy on the discussion if you know you won’t change the stakeholder’s mind yourself.
What I like to do is to explain the tradeoff and redirect them to a key stakeholder of the other initiative. You could say something like, “The feature you want to build might bring us roughly $50,000 in revenue. We are currently working on a new feature for the marketing team that is estimated to bring us $80,000 in revenue. If you still believe your idea is better, then you must convince the VP of marketing to drop their idea.”
Delegating a problem to someone else is okay, especially if that person is better suited to tackle the problematic stakeholder.
Some special cases might require lobbying. Get other key stakeholders on your side. Talk to your boss and others involved in decision-making, explain the situation, and pitch them your decision.
Don’t frame it as an “alliance versus the problematic stakeholder.” It’s unhealthy. Just contact people and consult your decision with them for their opinion. If your call was a good one, they should support it.
Then, if the stakeholder pushes for the idea, you can back up that it’s not only your decision but also consult it with other decision-makers.
If they try to challenge your call, they’ll have to deal with multiple people supporting you, not just you.
It might seem like messy politics, but hey, that’s part of the job, whether you like it or not.
Frequently saying “no” is a part of every product manager’s job.
The best thing you can do is to limit poor requests in the first place. You achieve that by being transparent with the topics you pursue and why you pursue them and by frequently collaborating and discussing with key stakeholders.
Once you get a request, don’t take it at face value. Understand the hidden need behind that request and figure out if there’s a simpler way to achieve that need.
If there isn’t any, run the idea through your prioritization framework. The fact that it’s an unplanned request doesn’t mean it’s a bad idea. If your assessment tells you it’s more valuable than what you are working on, treat it as a new opportunity, not an interruption.
If you still have to say no, you can now transparently explain what you are focusing on, how the requests compare to other things on your roadmap, and why you decided not to pursue the idea.
Some tougher stakeholders might require additional 1:1s, redirecting to “higher-ups,” and even some lobbying.
Although still sometimes uncomfortable, if you follow tips from this article, saying “no” should become easier — both for you and the person hearing the rejection.
LogRocket identifies friction points in the user experience so you can make informed decisions about product and design changes that must happen to hit your goals.
With LogRocket, you can understand the scope of the issues affecting your product and prioritize the changes that need to be made. LogRocket simplifies workflows by allowing Engineering, Product, UX, and Design teams to work from the same data as you, eliminating any confusion about what needs to be done.
Get your teams on the same page — try LogRocket today.
Learn how to use Fibonacci story points for Agile estimation, avoid pitfalls, and explore alternatives like T-shirt sizing and #NoEstimates.
Randolph D’Souza talks about how he works to align different teams together, such as product, OEM engineering, and sales.
Understanding the root causes of project bloat is essential for aiming to improve productivity and streamline workflows.
Mahesh Guruswamy shares experiences learning from and coaching others on how to have tough conversations and how this inspired his book.
Learn more →
