Sales wants a feature for a deal. Engineering wants time to fix recurring failures. Support has a list of customers who are tired of waiting. Each request makes sense when you hear it separately.
The problem starts when they all need the same team next week.
I would not start by asking everyone to vote. I would start by making the competing consequences visible. Stakeholder management in product work is partly communication, but the difficult bit is reaching a decision when agreement is not available.
Translate the request into a consequence
“We need bulk export” is a proposed solution. “A customer spends two hours rebuilding this report every week” is a problem we can investigate.
Ask who is affected, what they are trying to do, and what happens if nothing changes. When someone gives you a deadline, ask what creates it. A signed commitment is different from a preferred date for a demonstration.
This is not a way to catch people out. It is how you stop comparing a customer problem, a technical risk, and a presentation preference as though they were the same kind of request.
Put the choices on one page
Consider a fictional enterprise product with three requests:
| Request | Reason to act | Reason to hesitate | Evidence still needed |
|---|---|---|---|
| Bulk export | Could remove repeated manual work | Permissions and data exposure need review | Which customers need it, and what they export |
| Reliability work | Could reduce recurring interruptions | Delays visible new functionality | Failure frequency and affected workflows |
| Dashboard redesign | Could improve comprehension | A redesign may not fix the actual problem | Where users get stuck today |
Nobody needs to pretend those options are equally attractive. The point is to put their assumptions in the same place.
For comparable planned work, RICE can help. If there is unacceptable immediate harm, use the incident process instead of trying to win a scoring debate.
Decide who decides
A meeting can produce a lot of agreement about the problem and still no commitment to a choice.
Before the discussion ends, name the decision owner, the people whose input is required, and the people who need the outcome. The exact roles depend on the organisation. Security, legal, and operational obligations may constrain what the product team can decide alone.
I would also set a point at which the decision is made. Otherwise, every new conversation becomes an unofficial appeal process.
Say no without making the request disappear
“Not on the roadmap” is technically an answer. It gives the requester almost nothing to work with.
A more useful response is:
We are addressing the recurring failure first because it interrupts an existing customer workflow. Bulk export remains under consideration. We need to confirm the access requirements before committing to a scope. We will revisit it after the reliability review, unless the customer commitment changes sooner.
That example does not promise a delivery date. It explains the current choice and the condition under which it could change.
There is a small but important difference between acknowledging a request and agreeing to build it. Keep that difference clear in the meeting notes.
Reopen the decision for evidence, not volume
Sometimes you should change your mind. A newly discovered risk, a verified customer commitment, or a much smaller implementation can alter the trade-off.
“Someone asked again” is a weaker reason.
Write down the assumptions that matter. If the export request was deferred because access controls were unclear, resolving that uncertainty is meaningful progress. If it was deferred because one customer needed it, evidence of a wider need is relevant too.
Intercom's roadmap discussion is useful here: it describes balancing different kinds of work rather than treating every idea as interchangeable. 1
Try the uncomfortable part
In The War Room, you make fictional stakeholder decisions while balancing stability, growth, and morale. The consequences are simplified game mechanics, not a model of an actual business.
What I like about the format is that it does not let you keep every option open. You choose, then deal with what the choice costs.
Real product work needs more evidence and more conversation than a game. But the same useful question survives: if we say yes to this, what are we saying no to?