A product manager will have to juggle different and sometimes competing requests from internal and external stakeholders. For example, the sales team wants you to include as many features as possible, the engineers want to set realistic goals, and the C-suite pressures you to deliver on time and under budget.
The big question is, how do you know when to accept their requests and when to say no?
Learning to say no to stakeholders means the difference in making a product that delivers on a coherent vision or one that is just a grab bag of features. However, you must also do it in a way that doesn’t create friction within your team and still encourages collaboration.
That’s because being a product manager is all about relationship management. Learning how to say no — without jeopardizing those relationships — is key to building a successful product.
Why Product Managers Must Learn to Say No to Internal & External Stakeholders
Product managers are under pressure to make the best decisions for their team with limited resources. As a result, they can’t afford to say yes to every request they get from internal and external stakeholders. Here’s why:
It Prevents You From Building Unnecessary Features
The goal of building a new feature is to solve an issue a customer is experiencing—not just because it’s “nice to have.” Otherwise, you’re just building a product with a bunch of features that nobody uses.
Being able to say no to stakeholders when it’s appropriate allows you to focus only on features that will significantly impact the product experience. Doing so will save you money and countless hours, as well as put the user experience first.
For example, a small portion of your customers may request that you include a specific feature that solves one of their challenges. However, this feature could be irrelevant to over 95% of your customers. By saying no, you avoid investing time and money in features that won’t make a difference for most users.
It Improves Your Prioritization Skills
Saying no to a feature request doesn’t mean that it doesn’t have its place in the product roadmap. It could just mean that it isn’t a priority right now.
By learning how to say no, product managers get to improve their prioritization skills and consider the development of features based on their importance. It helps product managers make decisions based on the value the feature will bring to the user experience, its feasibility, and whether there are sufficient resources to build it.
In the long term, both your product team and user base will benefit from better prioritization skills.
It Prevents Burnout
You never want to make your product team bite off more than it can chew. Saying no to building certain features prevents your team from getting overworked and not meeting deadlines.
But it’s easy to underestimate how long it could take to build a specific feature. Even the most minor feature could require complex functionality or specialized knowledge to build, adding extra workload to your engineering team and reducing time-to-value.
As a result, saying no when it’s due reduces the burnout of your developers and creates a better product culture. Your relationship with the development team will improve as well.
How to Listen to Stakeholder Feedback—And Say No
Saying no to stakeholders is not an easy task. And without strong relationships with execs, sales and marketing leadership, engineering staff, and customers, you’re already dead in the water.
“If you say no in the wrong way, like from a place of ego or defensiveness, your team will shut down, and the pipeline of ideas will start to die away,” says Peter Rivera, advisory executive at Avanade. “Ultimately, that will start to appear in the quality of the product.”
Here’s how you can effectively manage the feedback of different stakeholders while not saying yes to each request:
1. Empathize and Adopt an Open Mind
Don’t forget that you don’t have all the answers as a product manager; you need the collaboration of your team and your users to make the best product. So, always adopt an open mind as you’re listening to the feedback of your internal and external stakeholders.
The key is to make the stakeholder feel that you empathize with them by asking questions as they express their ideas for upcoming features. That way, even if you end up saying no, they’ll know you made an effort to hear them out, and it won’t create friction between parties.
“To say no well, you really have to be a good listener,” continues Rivera. “Don’t overlook camaraderie and creating an environment where people feel they can share an idea with you.”
The goal here is to understand your stakeholder’s thinking: ask them how their new feature ideas align with your company’s product vision. In addition to showing them you take their ideas seriously, it could provide you with unique insights you may not have thought of on how to approach product development.
If the feature request helps you reach your objectives more effectively, you should consider including it in product development. If not, then you can decline and explain why.
2. Clarify That No Doesn’t Mean No Forever
Just because you said no to a feature request doesn’t mean that it will never be part of your future product roadmap—and your stakeholders need to know that. So always clarify what your no means and whether or not you plan to work on their requested feature ideas.
To do it, show your stakeholders what’s on the roadmap—and more importantly, WHY it’s already on the roadmap—to help them make more educated decisions on priority. It also helps them better understand the process you go through to prioritize certain features.
If you like your stakeholder’s feature idea and you think it could fit in your future product development, let them know when they can come back to you with their request. It gives the stakeholders extra time to think about whether the new feature is truly urgent or not.
When it comes to external stakeholders such as customers clamoring about new features, however, you need to be more circumspect in talking about plans. The best approach is to show appreciation and tell them: “We thank you for your request and we’re currently investigating it.”
3. Check if Existing Features Already Solve the Issue
Sometimes stakeholders may simply be unaware that your product already solves a problem they want to fix. So when a stakeholder comes with feature ideas, understand the challenge that the feature idea is trying to solve and research to see if any existing feature is already solving the issue.
If it’s not the case, then you could say yes to the feature idea and include it as part of your product roadmap. If not, then you’ll have to say no and explain how you’re already solving the issue in the product experience.
A simple way to determine if your product already solves the issue is to ask your customers directly. You can either run user surveys via your email list or conduct interviews with customers to understand whether your features are already meeting their needs. You can also run A/B tests to see if the feature solves the problem or fixes something completely different.
4. Explain What Would Happen if You Said Yes
One of the best ways to say no without creating friction is to explain the consequences if you said yes to their feature request. Making a stakeholder understand what is at stake gives them room to rethink their feature request.
According to Tim Maliyil, CEO at the data security consultancy AlertBoot: “The PM should be able to understand the consequences of what they’re asking for. What parts of the product is that going to impact?”
For example, could adding the new feature create more workload for your engineering team and make them miss their development deadlines? Or, is this new feature incompatible with your underlying architecture?
“Whether it’s manpower, money, whatever it may be — what’s it going to cost to make this happen," asks Maliyil.
Ultimately, stakeholders want the same thing as you: to create the best product and engage more users. Moreover, they’ll be more likely to empathize with your position if they understand how their feature requests could prevent the company from achieving its goals.
5. Provide Alternatives
While you might reject their new feature idea, the stakeholder may make a solid point about a problem that’s hurting the user experience. Depending on the situation, instead of saying a hard no, you could offer alternative solutions to the challenge that the stakeholder is trying to solve.
For example, let’s say that the stakeholder’s goal is to improve user onboarding. To do this, they propose to include a longer product walkthrough to showcase all the benefits of your solution to users.
The stakeholder’s intentions are good. However, a longer product walkthrough isn’t what you need—if anything, it can create more friction by adding extra hoops that the user has to go through.
What you can do is acknowledge the stakeholder for identifying an issue in the user experience while explaining to them the consequences of including a product walkthrough that’s too long. As an alternative, you could propose including a live chat feature to answer any questions the user may have 24/7, which will also save you money from hiring more customer service agents.
Saying No Will Make You a Better Product Manager
By better managing feedback from stakeholders and saying no when you have to, you’ll become a better product manager, improve your communication, and develop better feature prioritization skills. In return, you’ll deliver a better product that engages more users and meets their expectations.
“Focus means saying ‘no’ to 1,000 things,” said the legendary Steve Jobs. “I’m actually as proud of the things we haven’t done as the things I have done. Innovation is saying ‘no’ to 1,000 things. You have to pick carefully.”
