“They Said They Wanted It”

​
Every product manager eventually faces the same challenge. A senior stakeholder drops a feature request in your lap. Sometimes it comes from Sales, sometimes Marketing, sometimes the CEO.

They usually come with a deadline and a reason that sounds urgent. If you don’t know how to push back thoughtfully; or worse, if you just say yes, you’ll find yourself buried under work that doesn’t move the needle.

They confuse being collaborative with being compliant. They think saying yes earns trust, when in reality it erodes it.

When product managers deliver exactly what stakeholders ask for without investigating whether it solves a real problem, they trade long-term impact for short-term harmony. And then they wonder why no one uses the feature they shipped.

If you’re not actively interrogating feature requests, you’re not managing a product. You're just the order taker.

It's not lost on me that some companies offer no flexibility, or room fo discussion in these situations. If that's the case, you may be out of luck.

But many do, especially if they have a halfway decent Product culture.

Let's talk about how to better manage these scenarios where you can.

Takeaway 1: Every request is a clue, not a command

When someone tells you, “We need a dashboard for enterprise clients,” treat that like a symptom. Not a diagnosis. Not a solution. Not an order. Just a clue.

Maybe enterprise clients are asking for it. Maybe Sales promised it. Maybe there’s a dashboard-shaped hole in your competitor’s demo.

That’s all fine. But the first instinct should never be “how fast can we build it.” The first instinct should be “why do they think they need it.”

A feature request is a starting point. Dig. Ask for the original conversation. Ask for context. Ask what decision the dashboard is supposed to support.

This won't always work. I once pressed a stakeholder on the reasoning for a request. His response? He had a friend who worked at a competitor. They did it and like the results.

That's it. Millions of dollars on the line. This was his logic. And he did NOT appreciate being questioned. This was the plan end of discusison.

But I have had similar discussions with other (more reasonable) stakeholders and these requests have been de-prioritized quickly.

Stakeholders won’t always love the probing, but typically they’ll respect the fact that you’re trying to solve a real problem, not just check off a box.

Takeaway 2: Business cases make bad north stars

Stakeholders love to anchor feature requests in big numbers. “If we build this, we’ll land a $2M deal.” “This client said it’s a dealbreaker.” “We lost a renewal over this missing feature.” (Sales teams LOVE to blame lost deals on Product)

The numbers are probably real. But the interpretation is usually off.

That $2M client might be dangling a dozen requests. The actual contract might not depend on the feature at all. And even if it does, you have to ask: what will this cost the rest of the roadmap? Who are we saying no to in order to say yes to this?

Don’t chase business cases. Assess leverage.

If the feature unlocks a new segment or improves retention across the board, that’s leverage. If it’s a one-off shortcut to a deal that might not materialize, that’s risk. Don't let urgency disguise itself as importance.

Takeaway 3: You have to speak both languages

It’s easy to villainize stakeholders. Sales doesn’t understand how hard this is to build. Marketing doesn’t get tech debt. The CEO doesn’t care about process or ramp-up times.

But most product managers don’t realize how confusing we are. We talk in terms of edge cases, dependencies, timelines, and experiments. That can make us sound evasive or bureaucratic when someone just wants a very simple answer.

If you want to influence feature requests, you have to translate. That means summarizing your thinking in simple terms.

Say things like:

“We looked at this, and while we can do it, we’d be delaying a feature that improves retention across all new users by x%.”

“We tested a lightweight version and saw that only x% of users engaged with it.”

“Here’s what we’d have to trade to get it out by end of quarter. We're forfeiting $x in revenue. Is that a trade the business wants to make?”

You don’t need a 30-slide deck. You need clarity. They don't care about the nitty-gritty, in the weeds details.

Speak plainly and let the stakeholder see the tradeoffs. That’s how you earn real influence.

Takeaway 4: Never commit in the room

This is one of the most basic rules, but almost everyone breaks it early in their career.

Someone senior asks, “Can you add this to the roadmap?” and you feel pressure to respond right away. You say yes to avoid conflict. You say maybe, thinking it sounds diplomatic. But even “maybe” can be heard as “probably.”

So here’s the rule: never commit in the room.

Thank them for the input. Ask the questions. Take notes. Tell them you’ll review it alongside current priorities and come back with a recommendation.

This tiny delay gives you time to do the real work. You can dig into the problem, explore alternatives, talk to users, and frame the decision in context. Once you’ve done that, then you can give a clear answer.

Stakeholders don’t need instant agreement. They need to feel heard. There’s a difference.

Takeaway 5: Saying no builds trust (If you do it right)

A lot of product people think pushing back will damage relationships.

But saying no isn’t the problem. Saying no without context, or with attitude, or too late in the process. That’s the problem.

A good “no” sounds like this:

“We looked into it and it’s a significant lift. We’d have to cut two other roadmap items to fit it in this quarter.”

“We agree it’s an issue, but we think there’s a faster way to solve the problem than building this request directly.”

Notice how each response is backed by evidence, framed in tradeoffs, and positioned as a business decision. Not a personal rejection.

That’s the key. You’re not saying no because it’s hard or annoying or “not agile.” You’re saying no because the team has limited capacity and you’re protecting that capacity for the work that matters most.

Over time, stakeholders respect that. Even if they’re frustrated in the moment, they’ll learn that when you say yes, it means something. That’s how trust works.

In Conclusion

The best product managers aren’t the ones who say yes the fastest. They’re the ones who slow down, ask better questions, and solve the right problem.

You won’t always get it right. You’ll have moments where you cave, or over-explain, or let something slip through that should’ve been blocked.

But if you can get comfortable living in the space between stakeholder wants and customer needs, you’ll be more than just a roadmap jockey.

You’ll be a strategic partner.

And the next time someone drops a “must-have” request on your desk, you’ll know exactly what to do.

Not commit.

Not cave.

Just think.

Thanks for reading. See you next week.