Are you a Yes-Man or a Mister No?

In product organizations, stakeholder conversations usually get two main responses: an eager yes or a defensive no. One leads to chaos, the other to paralysis.

Most product and engineering teams have people who fall into one of two groups.

The first group treats every stakeholder request as an order. A new feature? Yes. A last-minute change? Yes. Another urgent request from another department? Yes again. Calendars fill up, roadmaps get longer, and teams quietly work evenings and weekends to keep all the promises. The Yes-Man seems helpful and flexible, but eventually, deadlines slip, the team burns out, and everyone wonders who approved it all.

The second group is the opposite. Every request gets pushback. “Not in the roadmap.” “No resources.” “Come back next quarter.” Sometimes it’s just a polite no. Mister No protects the team from overload, but over time, stakeholders stop sharing ideas, innovation slows, and the product team starts to seem more like a gatekeeper than a partner.

Both attitudes make sense. One focuses on keeping stakeholders happy. The other focuses on stability and control. But both avoid the same uncomfortable task: negotiation.

The real job of product leadership isn’t just saying yes or no. It’s turning requests into priority decisions.

When someone asks for a new feature, the honest answer is rarely just yes or no. It’s usually something like, “Yes, if we move something else out of the plan,” or, “Yes, but that will push the analytics work back by three weeks.” The conversation shifts from approval to discussing trade-offs.

This is when priorities become real. When requests are considered alone, everything seems important. Every idea feels urgent by itself. But once you compare it to other planned work, the question changes from “Is this useful?” to “Is this more important than what we’re already doing?”

And that’s a much harder question to answer.

In practice, good teams make trade-offs clear as soon as possible. They show the roadmap, the backlog, and what the team is working on, along with available capacity. Instead of saying, “we’ll try to fit it in,” they explain each request in terms of time, effort, and impact. This isn’t to block ideas, but to bring clarity to the conversation.

At this point, something interesting often happens. Many requests get smaller. A “must-have feature” becomes “maybe a smaller version would work.” An urgent request turns into “maybe next quarter is fine.” Sometimes, two stakeholders realize they’re competing for the same resources and start negotiating with each other instead of pushing the team.

In other words, being transparent does half the negotiating for you.

Another key point is to separate ideas from commitments. Product teams should welcome ideas, but making commitments should be much harder. Anyone can suggest something new, but deciding to build it should follow the same prioritization process as everything else. This keeps the team from making accidental promises that turn into obligations.

This approach also takes much of the emotion out of these conversations. If a team just says “no,” the discussion feels personal and stakeholders feel rejected. If a team says “yes” but sacrifices its own capacity, resentment builds within the team.

But when the answer is, “here are the trade-offs,” the decision is no longer personal. It becomes about structure. The conversation shifts from asking for permission to discussing how to allocate resources.

Interestingly, many requests disappear once trade-offs are clear. When stakeholders see that their urgent feature would delay something else they care about, priorities become clear much faster.

Good product teams work differently. Instead of making promises or refusing requests, they set conditions. Every request goes through the same process: what’s the impact, what’s the effort, and what needs to be postponed to make room for it.

This approach has an unexpected benefit. Stakeholders start negotiating with each other instead of with the team, which is usually a much healthier dynamic.

So next time someone asks your team for something new, try not to be a Yes-Man. Also, avoid becoming Mister No.

Try something a bit more uncomfortable. Say, “Yes, we can do this. Let’s decide together what will no longer be a priority.”