Product owners must learn to say NO if they hope to build successful products.
“It’s only by saying NO that you can concentrate on the things that are really important.”
As a product manager, you will be constantly faced with competing requests and priorities. If you cave into everything, your product will fail, and eventually, so will your company.
The three major issues caused by an inability to say NO:
The quality of your product will suffer
The development of your features will slow to a halt
Your engineering team will be demoralized
A product that tries to please everyone will truly fix problems for no one, as the goal is to solve for safety, not innovation. The reasons are many: non-product professionals don’t spend their time thinking through complexity costs (and nor should they). They don’t experience first-hand how it’s often actually ok to let fires burn. And lastly, they are not responsible for delivering the entire roadmap, and are instead just focused on a small subset of issues.
Furthermore, by deflecting a large percentage of each sprint to issues, you will slow down your engineers on feature development. Causing them to context switch and preventing them from fully committing to features, will be some of the biggest hidden costs to engineering velocity. This will also demoralize engineering teams, and that will have impacts that will take mountains of effort to recover from.
Of course, saying NO is hard. It’s your account managers who are on the front lines defending the product. It’s your sales team who need just that one little thing to close a deal. But all of their needs should already be baked into your roadmap, and prioritized correctly. You have to stay focused on your vision.
So what are some good approaches to saying NO… diplomatically?
As a product owner, quite honestly, you don't need to give your life story as to why you are saying NO. You are the owner, you are the gatekeeper, and the needs of your engineers are as important as all the other stakeholders. However, if you would like to be a little more collaborative (which is always a good idea), you can provide more rationale behind your decisions.
Put together a few slides to present what the prioritization process looks like, count of issues in the backlog, and ETA to get through 10%, 25%, 50%. Visually show what happens when you insert things in between. Show them what happens when you make engineers context switch.
Without insulting people's intelligence, give them some scripts on how they can say "no" to their constituents while still preserving their relationships. Provide good estimates on when things will be delivered in the future (but be honest internally if you really never intend to build something). Bend over backwards to help people figure out workarounds.
If it's a handful of people doing constant escalations, pull them into a room and present this detail and process to them. If the entire company is escalating things, then a company wide meeting is appropriate. Maybe make it part of a product roadmap kickoff.
One other thing you can do, if they don't exist already, is build out tier 1 and tier 2 support teams to deflect the majority of escalations and bugs away from the core engineering team, so they can focus on feature development.
In the end, just make sure you are making rational decisions, and that you truly do understand the needs of your users and your business counterparts. By effectively saying NO, you will be helping everyone succeed in the long term., even if they don’t realize it now.