Early in my career, I thought the job of a PM was to say yes.
Yes to the feature request from the sales team. Yes to the “quick win” from the CEO. Yes to the user research finding that suggested we needed a new flow. Yes to the engineer who had a great idea during sprint planning.
I was wrong. The job of a PM is to say no — thoughtfully, respectfully, and often.
Why no is hard
Saying no feels like failure. It feels like you’re blocking progress, disappointing people, being negative. In a culture that celebrates shipping, saying no feels like the opposite of shipping.
But every yes has a cost. When you say yes to a feature, you’re saying no to:
- The engineering time that could have gone to something else
- The design attention that could have improved something existing
- The focus that keeps the product coherent
- The simplicity that makes the product learnable
The product that tries to do everything does nothing well. Every feature you add makes every other feature slightly harder to find, slightly harder to learn, slightly harder to maintain.
The yes bias
Product teams have a structural bias toward yes. Here’s why:
Saying yes feels productive. You’re adding things. The backlog is growing. The roadmap is full. It looks like progress.
Saying no requires justification. You have to explain why not. You have to defend the decision. Saying yes is the path of least resistance.
The costs of yes are invisible. When you add a feature, the cost is diffuse — a little slower, a little more complex, a little harder to maintain. No one writes a post-mortem about the feature that made the product 2% more confusing.
The costs of no are visible. When you say no to a feature request, the person who asked is disappointed. That disappointment is immediate and personal.
How I think about it
I’ve developed a few heuristics for saying no well.
“Not now” is often better than “no.” Most feature requests aren’t bad ideas — they’re just not the right priority right now. “We’re not doing this in Q2, but let’s revisit in Q3” is more honest and more useful than a flat no.
Ask for the problem, not the solution. When someone requests a feature, ask what problem they’re trying to solve. Often the feature they’re requesting isn’t the best solution to the problem. Understanding the problem opens up better options.
Make the tradeoff explicit. “If we build this, we won’t build X. Is that the right call?” This forces the conversation to be about priorities, not about the feature in isolation.
Use data to depersonalize. “Our data shows that only 3% of users use this flow” is easier to hear than “I don’t think this is important.” Data makes the no about the product, not about the person.
Say no early. The later you say no, the more it costs. Say no at the idea stage, not after someone has spent three weeks designing it.
The thing I’ve learned
The best products I’ve used have a strong point of view. They know what they are and what they’re not. They’ve said no to a lot of things.
That clarity comes from a PM who was willing to disappoint people in service of a coherent vision.
Saying no is an act of respect — for the user’s attention, for the team’s time, and for the product’s integrity. It’s the hardest skill in product. It’s also the most important.