How to Prioritise Features When Every Stakeholder Says Theirs Is Essential

When every stakeholder says their feature is essential, the real problem is usually not a lack of ideas. It is a lack of shared decision criteria.

A feature request may represent a genuine customer problem, a commercial commitment, a risk, a personal preference or an untested assumption. Treating every request as equally urgent turns a roadmap into a negotiation between the loudest voices.

The answer is not to remove stakeholders from product decisions. It is to give everyone the same transparent route from request to evidence, trade-off and decision.

“Essential” is a claim, not a priority

A stakeholder may say a feature is essential because:

• a customer asked for it;
• a competitor appears to offer it;
• it would make a sales conversation easier;
• it fixes an internal operational frustration;
• a senior leader likes the idea;
• the team has already started discussing it.

Each point may be relevant. None is a complete prioritisation case on its own.

Start by replacing “we need feature X” with four questions:

1. Which user or business problem are we solving?
2. For whom, in what situation and how often?
3. What evidence tells us that the problem matters?
4. What outcome would show that solving it worked?

This shifts the conversation from a preferred solution to a testable product decision.

The UK government’s digital guidance similarly distinguishes user needs from solutions, preferences and business requirements, and recommends maintaining a prioritised list of needs based on evidence. See Understand users and their needs.

Convert requests into comparable opportunity cards

Use a standard card for every meaningful request.

Do not make a card burdensome for minor fixes. Use it for decisions that compete for meaningful capacity.

This structure also improves stakeholder conversations. A stakeholder is no longer being asked to “justify their idea”; they are helping the team understand the problem and evidence behind it.

Use familiar frameworks for the job they are good at

Frameworks are useful if they create a shared language. They become harmful when they produce artificial precision or hide a decision behind a spreadsheet.

The original RICE framework uses reach, impact, confidence and effort. It is especially useful when a team has several comparable opportunities and needs to avoid prioritising ideas only because they are exciting or easy.

MoSCoW can be helpful when protecting the scope of a specific release. However, it should follow evidence and trade-offs, not replace them.

Use one weighted model for your roadmap

For teams facing many competing requests, use a simple score out of 100.

Score each positive criterion from one to five, then multiply it by the weighting.

Then apply an explicit opportunity-cost deduction of zero to ten points.

For example, a feature may score well on user value but deserve a deduction if it would delay a more important dependency, create substantial maintenance burden or distract the team from the agreed product goal.

Priority score = (outcome value + evidence confidence + reach + risk reduction + strategic fit + urgency + feasibility) - opportunity-cost deduction.

The score does not make the decision automatically. It makes the reasons for the decision visible.

Separate commitments from discoveries

Not every high-potential item should become a delivery commitment.

Use three queues:

This prevents two common mistakes:

• building a feature because it has a persuasive sponsor but weak evidence;
• discarding a useful idea simply because it is not ready for delivery yet.

Discovery is a real product outcome when it reduces uncertainty. A short research or prototype task may be more valuable than a large feature commitment.

Handle dependencies and non-negotiables openly

Some work should not compete purely on a score.

Examples include:

• a security vulnerability;
• a legal or regulatory obligation;
• an existing contractual commitment;
• a critical production reliability issue;
• a dependency required for a higher-priority outcome.

Mark these clearly as constraints. Then state the effect on the roadmap. Hiding them inside a generic feature score creates false debate and makes the rest of the plan less credible.

For delivery work that is not a hard constraint, ask: what must happen first for this outcome to be possible? This reveals dependencies before a team promises dates it cannot meet.

Use a practical tie-break rule

When two items have similar scores, choose the one with:

1. stronger evidence;
2. a lower cost of being wrong;
3. a smaller or more reversible first experiment;
4. fewer critical dependencies.

If the tie remains, choose the item that best protects the agreed product outcome—not the stakeholder with the greatest seniority.

Communicate the decision, not only the result

A backlog becomes political when decisions disappear into it.

For every significant request, communicate:

• the problem being addressed;
• evidence considered;
• criteria and score;
• decision made;
• what was deprioritised as a result;
• the trigger for revisiting the decision.

Useful language includes:

• “This is valuable, but the evidence is not yet strong enough for delivery. We will run discovery first.”
• “We are deferring this because it solves a narrow problem while the current release protects a core journey.”
• “This is a non-negotiable risk item, so we are adjusting the release scope around it.”
• “We will revisit this after the next customer-research cycle or when usage reaches the agreed threshold.”

Transparent decisions are easier to accept than unexplained rejections.

Revisit priorities when evidence changes

A roadmap is not a promise that priorities will never change. It is a record of the best current decision.

Review the priority set when:

• customer behaviour changes;
• a product metric reveals a different bottleneck;
• a new risk or dependency appears;
• a commercial commitment is confirmed;
• effort estimates materially change;
• an experiment invalidates the original assumption.

The key is to change priorities for evidence-based reasons, not because the newest request feels urgent.

Conclusion

Feature prioritisation is not about proving that one stakeholder is right and another is wrong. It is about making finite capacity serve the clearest product outcomes.

Use common criteria, preserve evidence, make opportunity cost visible and separate discovery from delivery. When teams can see how decisions are made, stakeholder conflict becomes more productive—and the roadmap becomes easier to defend.

Sources and further reading

• Department for Education: Understand users and their needs
• GOV.UK: Government Functional Standard GovS 005 Digital
• Intercom: RICE prioritisation framework
• Turn customer interviews into a product roadmap
• The product discovery sprint