Defaulting to NO is limiting your success
Contrary to popular advice, "No" is not the first word you should learn as a PM
The opinion: Most B2B PMs are saying NO too quickly. This leads the rest of the organization to believe that product usually just works on “strategic initiatives” that rarely succeed, and they’ve lost (or never had) a connection to actual customers.
How PMs are raised
When I started as a PM, one of the first things I was taught was that I should say NO and dig down to the why.
Yet somehow, many PMs I’ve met over the years actually interpret this as, “I should say NO.” This is usually justified by PMs thinking they need to manage stakeholders’ expectations to keep their backlog lean and ensure they can deliver on everything that’s required of them.
Stakeholder management
I saw a meme on LinkedIn the other day that made me think:
And it makes so much sense, right? Saying yes to everyone will overwhelm you, and you’ll just drown in priorities and work. You won’t have time for discovery on big strategic bets because you’re too busy solving the issues you’ve already said yes to.
Many would call this “stakeholder management”: don’t create expectations that are too high, or you’ll get into trouble down the line.
How this is (often) applied in practice
The problem, this is how most PMs implement this advice on common questions:
Sales: “We got a request from an enterprise account; we need to solve “…” to close the deal.”
PM: “We need to focus on building what is important for all customers, not just build something for a single enterprise account”
Generally a great idea. Don’t invest 300k in development for a 50k deal.
CEO: “Our biggest competitor released this feature, we need to build it as well.”
PM: “We should focus on our customers needs, not on what others are building”
We shouldn’t just build what others do, who knows if it even works for them.
CS: “We need to fix our user experience, customers are churning because we can’t onboard them well.”
PM: “We can’t just fix our UX, this would take months”
Yes we need to communicate technical complexity to set expectations.
The problem with this approach
Here’s the issue with these answers: all the other person hears is, “The PM is just saying no again to the request I have. Yet we’ve released 15 things this year that no one is using or has asked for.”
The assessment by your stakeholder is probably fair. About 80% of what product teams produce is crap. The rest is great software (simply because it’s hard to build things that create a huge amount of value).
Down the line, your stakeholders won’t be “managed well”. Since you say no to everything, they’ll simply lose trust that product is actually trying to solve customer problems. Most likely, if something important comes up, they’ll reach out to the PM’s boss, not the PM.
The first time I realized this was at the very beginning of my PM career. I started in customer service, and when I made the switch to product, one of my colleagues said, “Make sure not to lose your sense of what customers need.”
This sounded crazy to me at the time. Doesn’t product want to deeply understand customers and solve their problems? Yet those on the front lines with customers often believe product teams are doing the opposite.
On the other side of the spectrum, PMs who say yes to everything to avoid confrontation are they’re just as bad.
What great thing could happen if I say yes?
“Always say no” feels like a tempting framework. Complex requests come in, often half-baked, from different parts of the business, and for a PM juggling priorities, an automatic “no” can feel like a lifeline. It simplifies things, keeps you in control, and might even feel like it gives you authority over the chaos.
But when we get too comfortable with “no,” we stop looking for opportunities hidden within the ask. A request from sales, a feature the CEO wants, or a complaint from customer support might seem like distractions, but they could just as easily be signals pointing to unmet needs or areas where your product can stand out.
Ask yourself if saying yes could be a way to make real progress. Will it get you closer to your product’s vision? Could it lead to a solution that serves a wider base? Saying yes doesn’t have to mean overhauling your priorities or abandoning your roadmap. It’s about making a decision that isn’t just defensive but strategic.
In short, the question shouldn’t be “Do I say yes or no?” but “What’s the opportunity here?” If there’s nothing valuable to gain, sure, say no. But if there’s a chance that yes could bring you closer to your goals or strengthen your connection to real customer needs, then that yes is worth considering.
Applying this to the requests from before
Sales: “We got a request from an enterprise account; we need to solve “…” to close the deal.”
PM: “Awesome, let’s schedule a call with this customer to better understand what they need.”
Use this call to determine what problem the customer has and if there might already be a solution to this within your product. If not, assess if the problem is something common within your customer base. → You can still say no after that!
CEO: “Our biggest competitor released this feature, we need to build it as well.”
PM: “Let me look into past requests if this is a problem we have identified as well.”
Many times features lose against other priorities until a competitor builds it. Use this to review past priorities and see if this problem was on the table to be solved but lost to other, apparently more promising things.
CS: “We need to fix our user experience, customers are churning because we can’t onboard them well.”
PM: “Let’s have a look at the onboarding flow together and see where we could make improvements.”
When others come to you with problems that you know are true but would be “mega-projects” try to find smaller fixes that can have impact on the problem.
Conclusion
Next time you’re hit with a request, pause before defaulting to “no.” Assess what’s really being asked, explore the potential value, and see if there’s a way forward that serves both the product and the people invested in it.