How to Prioritise: Make Trade-offs, Not Just Rankings

A backlog can be perfectly ranked and still contain no real priority.

If the team expects to do items one through twenty eventually, the numbers describe an order. They do not reveal what deserves investment, what will wait, or what the organisation is willing to sacrifice.

Prioritisation is the act of protecting a choice under limited capacity. A useful process does more than sort work. It connects a desired outcome to an explicit set of bets and makes the rejected alternatives visible.

That is why the hard part is rarely choosing a framework. It is deciding what matters enough to displace something else.

Begin with the decision boundary

Before comparing initiatives, define the decision you are actually making.

• Which outcome are we trying to influence?
• Which users, market, or product area are in scope?
• What is the planning horizon?
• What capacity, capability, or budget is genuinely available?
• Which commitments and constraints are fixed?
• Who makes the final decision?

Without these boundaries, teams compare unlike options. A reliability fix competes with a new market bet. A small experiment competes with a multi-quarter platform change. An urgent support issue competes with strategy.

The comparison may produce scores, but it cannot produce a coherent portfolio.

Business, Strategic, and Product Goals can help define the outcome and strategic choice before work enters the prioritisation conversation.

Remove work that does not deserve comparison

Scoring every request gives weak ideas more attention than they deserve.

Use a first filter. An item should enter detailed comparison only if it has a credible connection to the current outcome, a relevant user or business need, and a realistic path to action within the decision horizon.

Other work can be:

• rejected because it conflicts with strategy;
• parked because evidence is missing;
• routed to a different operating process;
• treated as an obligation rather than a discretionary bet;
• decomposed because it is too broad to compare.

Mandatory security, regulatory, or reliability work still needs planning. It may not need to pretend to compete on the same value score as a growth initiative.

Separate obligations from choices, then make capacity for both explicit.

Compare the dimensions that matter

No fixed set of criteria works in every product decision. Most useful comparisons, however, examine some version of five dimensions.

Expected value

What meaningful customer or business outcome could change? For whom, by how much, and over what period?

Value can include revenue, retained use, reduced risk, operational efficiency, learning, strategic position, or future options. Name the type rather than collapsing every benefit into “impact.”

Confidence

What evidence supports the expected value? Direct observation, product data, a prototype test, comparable behaviour, or informed judgement do not deserve the same confidence.

Confidence should expose an evidence gap, not punish every new idea. A high-value, low-confidence opportunity may deserve discovery rather than dismissal.

Cost

Cost includes more than initial engineering effort. Consider design, data, migration, go-to-market, support, maintenance, operational load, and the complexity added to the product.

Estimates can remain coarse. Their job is to distinguish materially different commitments, not simulate certainty.

Risk

What could go wrong beyond simply failing to create value? Privacy, safety, trust, reliability, legal exposure, organisational dependency, or difficult reversibility may change the order of work.

Some risk should lower a priority. Other risk creates an urgent obligation. Be explicit about which kind you are discussing.

Strategic fit

Does the work strengthen the direction the organisation chose? Does it build a capability, advantage, or learning path that matters beyond the immediate result?

“Aligned with strategy” should not become a ceremonial checkbox. State the mechanism: how would this initiative advance the choice?

Use frameworks for questions, not answers

Frameworks are useful when they expose assumptions consistently. They become dangerous when the score gains more authority than the evidence behind it.

RICE

RICE compares reach, impact, confidence, and effort.

Sean McBride’s original explanation presents it as a way to compare estimates and counter familiar biases.

The score is not a hard rule.

Use it when several initiatives pursue a comparable outcome and you can define reach and impact consistently. Do not compare incomparable units merely because a spreadsheet accepts them.

MoSCoW

Must, Should, Could, and Won’t can clarify commitments within a fixed release or scope. It works best when “Must” has a strict definition and “Won’t” is taken seriously.

It is weaker for choosing a strategy. If everything is a Must, the method has only documented the conflict.

Kano

The Kano model helps discuss how different product attributes may affect satisfaction. It can broaden a portfolio conversation beyond “more features equals more value.”

Use research to understand expectations. Do not label an idea a “delighter” because the team finds it exciting.

Cost of Delay

Cost of Delay makes timing part of the decision. It is useful when the value of work changes materially with delay, such as a regulatory deadline, a seasonal window, or compounding operational loss.

Its weakness is the temptation to invent precise financial values for uncertain effects. A transparent range or relative comparison may be more honest.

The best framework is the lightest one that makes the important trade-off harder to avoid.

Make the sacrifice visible

Every chosen item consumes capacity that could support another result. A prioritisation review should therefore pair each recommendation with the alternative it displaces.

Instead of:

Initiative A scored 78 and should be first.

Say:

We recommend Initiative A because it addresses the current activation outcome with stronger evidence. Choosing it means Initiative B will not receive delivery capacity this cycle.

This changes the quality of the conversation. Stakeholders can challenge the outcome, evidence, or sacrifice instead of debating a mysterious number.

Keep a visible “not now” list with reasons and review conditions. “Not now” should mean the team knows what would cause reconsideration, not that the request has entered an infinite waiting room.

Balance a portfolio, not a single score

A team rarely needs one kind of work. A healthy product portfolio may include outcome bets, discovery, quality, risk reduction, maintenance, and capability building.

The mix should reflect the product’s situation. A fragile service may need reliability investment. A new problem space may need more discovery. A mature product may need deliberate simplification.

Do not use fixed capacity percentages as a universal recipe. Capacity buckets can protect neglected work, but the allocation should follow current evidence and constraints.

Review the portfolio for concentration:

• Are all bets dependent on the same assumption?
• Is short-term delivery crowding out necessary discovery?
• Is maintenance consuming capacity without a plan to change the system?
• Are several teams unknowingly pursuing the same outcome?
• Does the portfolio preserve a coherent sequence?

From Strategy to Action: Portfolio Optimization explores these choices at a wider portfolio level.

Handle urgency without turning it into strategy

Urgent work is real. A production incident, legal deadline, or severe customer harm may deserve immediate attention.

The problem begins when every commercial request arrives as an emergency.

Create a separate path for urgent work with explicit entry conditions:

1. What happens if we do not act now?
2. Who is affected, and how severely?
3. Is the deadline external or self-created?
4. Can we reduce the immediate harm without making a full product commitment?
5. Which planned work will move, and who accepts that consequence?

Urgency may change the order. It should not erase the trade-off.

When a request does not meet the urgent-work conditions, return it to the normal decision process. A senior sponsor can supply context, but seniority alone is not a severity measure.

A hypothetical prioritisation review

Imagine a subscription product trying to improve successful first-week use. The example is invented; the options and evidence do not describe a real company.

The team has capacity for one substantial initiative. It considers:

• a guided setup based on observed onboarding failures;
• an integration requested by several prospective customers;
• a visual dashboard redesign;
• an engineering change that reduces intermittent data delays.

The dashboard has broad reach but no evidence that visual presentation causes the first-week problem. The integration may support acquisition, but it does not serve the chosen activation outcome.

The guided setup has direct research support, but the data delay could undermine any onboarding improvement. The team discovers that the two items are not independent.

Instead of selecting the highest score, it funds a narrow engineering fix and a lightweight setup prototype. It defers production delivery until both uncertainties are better understood.

That is a priority even though it is not a single feature. The choice protects the outcome and sequences learning before a larger commitment.

Record the decision and inspect the result

A prioritisation process improves only when the team can compare its expectations with what happened.

For each significant choice, record:

• the outcome and decision horizon;
• options considered;
• evidence and important assumptions;
• expected value, cost, risk, and confidence;
• the selected option and rejected alternatives;
• review date and signals;
• who made the decision.

After enough time has passed, inspect the outcome. Was the expected behaviour observed? Did the effort or operating cost differ materially? Did an assumption fail? Would the team make the same choice now?

Do not retroactively claim the decision was obvious. Calibration requires preserving what was believed at the time.

Working artefact: the Priority Decision Record

Use one record for a consequential choice. Keep the language close to what was known on the decision date, then review it without rewriting the original belief.

Field	What to record
Decision	The exact commitment, horizon, and owner
Outcome	The behaviour or condition the choice should change
Options	Credible alternatives, including defer or stop
Evidence state	Known, observed, inferred, or assumed for each decisive input
Full cost	Delivery, opportunity, operating, adoption, and reversal cost
Sacrifice	Work, customer, or outcome that will not be served now
Selected bet	The option chosen and the reasoning that displaced the others
Review trigger	A date or signal that requires the choice to be inspected
Result	What happened, which assumption failed, and what should be recalibrated

The sacrifice row prevents a ranked backlog from masquerading as a decision. The review trigger prevents a score calculated under old assumptions from becoming permanent truth.

A lightweight prioritisation checklist

Before committing, ask:

• Is the desired outcome clear?
• Are scope, horizon, capacity, and decision owner explicit?
• Have obligations been separated from discretionary bets?
• Did weak candidates leave before detailed scoring?
• Are value, confidence, full cost, risk, and strategic fit visible?
• Are estimates comparable and traceable to evidence?
• Does the recommendation name what will not happen?
• Is urgent work using an explicit exception path?
• Does the choice make sense as part of the wider portfolio?
• Is there a review date and a decision record?

Prioritisation should not make disagreement disappear. It should make the disagreement useful.

When people can see the outcome, evidence, constraints, and sacrifice, they can debate the real decision. A neat ranking is optional. A protected choice is not.

Sources

• RICE: Simple prioritization for product managers — Intercom
• The first rule of prioritization: No snacking — Intercom
• Measuring the benefits of your service — GOV.UK Service Manual

Read next

From Strategy to Action: Portfolio Optimization shows how to balance several product bets and capabilities without losing the strategic thread.