Saying no is a time honored tradition in product management.
As a Product Manager your ability to be successful depends on building sound relationships inside and outside of your product team. So how can you say No without negative consequences?
Let’s start with understanding why product managers need to say No.
As a product manager your primary concern is figuring out how to maximize the odds of success in providing a solution to the market. In order to do this, you must come up with a vision and strategy to see that through. Working closely with your team, you must go into a lower level of detail on problems, solutions, and priorities among them.
Why Prioritize?
No matter how big your organization or tiny your product, I have never met a product manager, team, or sales exec that didn’t want to see more delivered in the product than the team has capacity to deliver. This holds true for new products and for established mature ones.
In fact, too often, I hear PMs constantly asking for more resources. If they just had another engineer or designer on the team, all this imbalance would magically disappear. I have some bad news for you. Constraints will always exist and your job will always be to determine how to prioritize work within those constraints.
The Product Vision and Strategy set the table for effective prioritization to happen. When a request falls outside the scope of the Product Vision and Strategy the Product Manager must say No.
Saying No, is the key to remaining focused. Focus is the key to optimizing execution results.
Determining when to say No is a little more complicated than that.
Stakeholders have lots of great ideas. They don’t only have bad ones, although there are plenty of those.
Ideas and specific requests may come from senior executives, your best sales exec, or your best reference customers.
Further, many of these ideas are so good you want to do them too.
Remember, when gamification of enterprise applications was all the rage. What PM didn’t want to include something in their app to gamify workflow and reward their users?
Therefore, you need a framework where saying No is easier (it will never be easy).
I suggest the following easy starting point. Ask these questions, in this order of descending granularity:
- Does the request fit the Product Vision?
- Does the request fit the Product Strategy?
- Does the request fit within the current Outcome Roadmap?
- Does the request fit within the current Sprint?
If the answer to all of these questions is No, then you can be pretty sure that should be your response to the stakeholder as well.
Most of the time, the answer will be yes up until a point. For example, yes it fits the vision and strategy but the near term roadmap dictates a different plan. So, for any request that is yes (or maybe) up until a point, your answer should never be no but more likely, not now.
Perhaps the request is a possible solution to an outcome planned to be worked on in the next Sprint.
Clearly, then, it is important to have a model for how you screen new incoming requests.
How to say no?
If the request does not meet the basic 4 fit questions then you must say No. Spending any additional time thinking it through will be a waste of your time and that of the stakeholder and teams members potentially dragged into the analysis.
Here is the basic response:
- Thank the stakeholder for their request.
- Tell them No, clearly, you cannot deliver on it. Without ambiguity.
- Tell them it does not fit with your Product Vision / Strategy. Be sure they have visibility into this strategy to help them understand.
- As such investing in it will have an opportunity cost and actually reduce your ability to successfully deliver on an existing Product Strategy.
Saying No like this does not usually feel great for most of us, especially when you like the request. However, if you give a half-answer like “let me check into it” those stakeholders will always hear “Yes”. Be firm, polite, and share the context to help them understand the response.
What if the answer is “Maybe” or “Not Now”?
Following the principles for determining if a request fits, if you are not sure or simply can’t tackle the request in the timing being asked, you also need to be clear on your response.
The fact is that new ideas, requests, and information comes to you all the time and you need to be able to consume it and adjust priorities moving forward if warranted. If the request is truly aligned with your plans but can’t be tackled immediately then you need to provide the stakeholder the same context as if you were saying no.
If this is an internal stakeholder, it is worth sharing some additional information like how this request would impact OKRs, product, or other team objectives.
Why be so transparent?
If you have a solid Product Strategy and Outcome Roadmap that you are working towards, guided by well articulated team objectives then you are actually empowering this stakeholder to determine on their own that this can’t be done now. Importantly, it also gives them a framework to analyze the situation and present you with why their request should be done sooner.
After all, if they can determine that your plans are actually better achieved by addressing their request sooner, then you want this to happen. Keeping your rationale hidden from stakeholders will undermine trust and credibility in the long run. Transparency is empowering for you, the product team, and the success of your product.
What about customers?
The days of companies and product managers hiding in obscurity are long over for enterprise software companies. You can’t simply let customers log requests and then allow them to go unanswered.
Here again transparency is your friend. While your specific product strategy might be too sensitive to share in detail with the outside market, you Product Vision should not be. After all, in enterprise software, we frequently sell new customers in taking a ride with us based on a well articulated vision of the future.
Today, I recommend coupling this articulated and re-enforced Product Vision with transparency in how you handle the many requests you may receive from your customers. Multiple Product Management tools in the market now have Idea and Feedback Management Tools (e.g. Aha!, craft.io, ProductHQ) where customers can submit and vote on the ideas of their peers.
By actively responding to these requests you demonstrate that you are listening. Even better, your customers are telling you exactly what they believe will make your product better. When you flag ideas as “Not Planned”, you are also telling your customers just how focused you are in delivering value.
Conclusion
Saying No, like other other things in Product Management, is much easier when you have a clearly articulated Product Vision, Strategy, and Roadmap. In fact, when these things are in place, you end up having to say No less frequently because there is a shared clarity of the future.
Instead requests from stakeholder become conversations about how some idea might support that plan. Providing transparency and giving a voice to your stakeholders will end up providing you with greater leverage of your own time. Stakeholders will effectively become an extension of the product team helping you deliver on that Product Vision.