Saying 'No' as a Product Manager
They said it’s important, but noone told you how to do it right
While many product managers acknowledge the importance of saying ‘no’, little resources and guidance has been given to guide this process. Having made my fair share of mistakes, I hope this writing serves you well if you are facing difficulty saying no as a product manager.
It’s a tough job
Saying 'no' is a tough job, and my advice to you is to lead with courage and do what’s right. My first no was rejecting an on-prem feature work assigned to me as an associate product manager after 2-3 weeks of explorations and discovery because it didn’t make sense for the product at that stage. It was a long process but it saved us months of engineering effort pursuing something that's not our focus at the time.
A few years later, I had to say no to a new product line with an ambitious plan to disrupt a new market a few months into a new role at a different company. I was called upon to take ownership after the MVP was ready with more than 30 engineers poured months of work into this (‘YIKES’). I knew that something was off but didn't have enough evidence and courage to say no to the C-Suite. Upon aligning with my direct manager, we shifted most of our engineers away from the project. The product was a flop and we pivoted away to start from scratch.
I was right both times, but in the latter scenario, I lack the courage to do what’s right so I came up with a framework I can refer back to when I have to do it again.
A step-by-step guide to communicating 'NO'
Step 1: Prerequisites
team culture: established product culture on what it takes to ship a great product
questions to ask: what kind of team culture do you work in? how does your team think about building a great product? Is it about shipping bloated software or delightful software?
product leadership: shared understanding on the necessity and value of saying no as a product manager
questions to ask: do you have leaders who understand the value of saying no when necessary? have there been circumstances where your leader had to say no for the team? how did that pan out?
Step 2: Evaluate your 'no'
what’s the current stage of the project you are working on? As depicted above, the later stage is generally the most difficult to execute your ‘no’. In a healthy product team, you should be saying no at the planning stage so the cost is at its lowest, not when the code is cooked up.
what’s the cost and benefit of saying no? This is particularly important when your ‘no’ is simply a delay in consideration. What is the cost of delay versus the cost of doing? lay it out and be transparent about this with your team
Step 3: Know thy stakeholders
Identify and list down the stakeholders who will be impacted by your decision. The list varies depending on the:
organisation size (e.g. the larger it is, the longer the list)
type of product team (e.g. product vs platform team)
type of market (e.g. B2B, B2C, D2C)
Step 4: Identify communication channel(s)
Based on the stakeholders you listed, what are the communication channels that’d best allow you to reach them? For example:
Step 5: Write up
Depending on the scope and impact of your no, your write-up can vary from one paragraph to a written document. While there is a lot of approaches you can use to convey your decision, here’s a checklist you can use:
WHAT is the final decision?
WHY is such a decision being made? Are there hard cold facts or evidence that leads to your conclusion? what are they?
HOW does pursuing or not pursuing this impact the product and business? does it have any ripple effect that your stakeholders should be aware of?
WHEN can we revisit the decision to check if we’ve made the right call? When can we revisit the feature work if your ‘no’ is a decision to delay?
The key here is to be transparent about your thought process and address key questions your stakeholders may have.
Step 6: Share
You did it, it’s the big moment to share your decision with your stakeholders. Good luck!
pro-tip: if unsure, run the finalized draft with your direct manager or immediate team
Conclusion
While it is easier to take up as much as you can, it is the act of knowing what to say no to and why is when you can truly work on what matters most. Be proactive about what you work on, not reactive.