Product Managers and the Art of Engineering a 'Yes'

If you spend any time reading about product management online, you'll frequently encounter a piece of advice: saying no is the product manager's superpower. There are countless guides on how to say no, why to say no, and frameworks for saying no with empathy. The narrative has become so dominant that many aspiring PMs believe their primary job is to be the gatekeeper who protects the team from distractions.

This isn't entirely wrong: saying no is part of the job, of course. But framing it as the defining skill of product management is dangerous. Worse, it creates a culture where product managers optimize for the wrong outcomes: process compliance, roadmap rigidity, and risk aversion.

Illustration of a "PM" sitting at a desk with a roadmap, saying "No" to a line of people with feature requests. Another group of people (the team and management) appear happy, thinking "Thanks for the focus!"

Why saying "no" feels like a superpower

Let's be honest: saying no is actually easy. You point at a roadmap. You cite committed priorities. You deflect by adding stuff to the backlog. Done. It's a defensive move that requires little courage and no creativity. Why do I think it’s easy? For at least a couple of reasons.

You’re protected by the process. Especially in organizations that operate with rigid methodologies and strong commitments to roadmaps and planning cycles. When you have a well-defined plan and established priorities, declining new requests becomes a routine exercise that is actually encouraged by organizational principles.

It provides immediate social rewards. Your engineering team appreciates that you're shielding them from constant context switching and scope creep. Your manager values that you're staying disciplined, following the process, and delivering what you had committed to deliver. There's a pleasant sense of being the responsible adult in the room, protecting everyone from chaos.

But here's the uncomfortable truth: there’s nothing special about saying “no”. In most product management careers, there will be far more instances of saying no than yes. The opportunities you don't pursue will always outnumber the ones you do.

The PM who always says “no” is perceived as an obstacle

Worse, encouraging PMs to default to "no" enables a dangerous pattern: product managers who reject everything outside the plan train stakeholders to work around them.

When business stakeholders or customers present something urgent, they're not trying to derail your carefully crafted plans. They're bringing you a problem they believe is important. In many cases, they're right. They're closest to the customer pain, the market dynamics, the competitive threats. They have information you might not have.

Great product managers recognize this and treat it as valuable input, not an annoyance to be deflected. They ask questions: Why is this urgent now? What happens if we don't address this? Who is affected and how severely? What outcome are you trying to achieve? After asking questions, they ponder and offer options.

When product managers consistently demonstrate the willingness to find a way forward, they build tremendous stakeholder confidence. Stakeholders learn that this person is thinking first and foremost about solving the right problems, not blinded by process for the sake of process. They will see them as a partner in achieving business outcomes.

Conversely, product managers who shut down conversations about unplanned work will be seen as obstacles. Stakeholders lose patience after hearing for the third time that their customer pain point is "in the backlog." They escalate to executives, who then mandate the work anyway. In the worst cases, stakeholders might even secure budget to build shadow solutions outside your product. In the process, you lost the chance to own the problem space. Worse, you lost credibility and authority, neither of which is easily regained.

Comic illustration with two stick figure characters. One says they need a "shadow" solution without informing the PM. The other hands over money and says, "Here's the budget. Bypass them."

What actually defines great product leaders

Great product management is about understanding the "why" before the "what" and "how." A product manager's core responsibility is to own the “why”, i.e., to maintain focus on business outcomes and end-user needs.

This means that the real differentiator of their success is not how often they say no, but which opportunities they say yes to and the impact they will generate on the business.

The challenge—and the art—lies in spotting the right opportunities that make you go: "Yes, we're going to change our roadmap. We've found something that is actually more important and more impactful to do."

This shouldn't happen every day. If you're constantly changing direction, you create chaos and undermine trust. But when the right opportunity presents itself, great product leaders (at any level: ICs, directors, C-level) have the instinct to recognize it and the courage to act on it.

The anatomy of engineering a "yes"

So, what does it mean to engineer a “yes”? At DataChef, we believe it involves three things that are part of the core skill set of a good product manager.

Rapid validation. When a potentially important opportunity surfaces, skilled product managers quickly validate whether it's worth pursuing. They have a strong instinct that helps them uncover the underlying problem, even when the pain point is poorly articulated or buried in raw feedback. They spot patterns and connect the dots, tying new requests to problems that surfaced earlier or recognizing similarities with already-prioritized work.

Creative solution design. Here's where the engineering comes in. Saying yes doesn't mean accepting the proposed solution at face value or dropping everything else. It means coming up with options to address the high-impact problem while managing constraints. For example, descoping less critical work, negotiating scope to deliver 80% of the value with 20% of the effort, or identifying overlaps with existing priorities that address the same need.

Stakeholder alignment without creating uncertainty. The hardest part of engineering a “yes” is doing so without creating chaos in the team or losing stakeholder confidence. This requires clear communication about why this opportunity matters more than what was planned and transparency about what's being deprioritized.

It’s on leaders to build a culture of options

If you’re a Director of Product, or a Chief Product Officer, here’s my advice to you. Companies get the product management they incentivize. If you reward product managers for sticking to the plan, minimizing stakeholder requests, and keeping teams busy with predetermined work, you'll get gatekeepers and coordinators. In many organizations, especially in Europe, that is the status quo.

If instead you reward product managers for delivering measurable business outcomes, solving high-impact customer problems, and building strong stakeholder relationships, you'll get product managers who think creatively and take calculated risks while driving real value.

The real trap is confusing process compliance with product excellence. Leaders should be careful about the metrics they pick to measure success and the stories they promote as virtuous examples.

And when performance review time comes, remember: it takes courage to engineer a “yes”. The product managers who get invited to strategic conversations, the ones who build loyal followings among stakeholders and teams, are the ones who figure out how to say yes to the right things.

So the next time you hear someone say "the product manager's superpower is saying no," push back. Because at the end of the day, nobody remembers the product manager who was really good at saying no. They remember the product manager who found a way to solve the most important problems, even when it wasn't easy.