Prioritisation frameworks do not tell you what to build. They make your reasoning visible so a group can argue about the right thing. Any framework treated as an oracle will produce confident nonsense, because every one of them buries at least one guess inside a number that then looks like evidence.
Here are the ones worth knowing, and the specific lie each tells.
RICE
Reach × Impact × Confidence ÷ Effort.
The most widely used, and the best default for a team with more requests than capacity. Reach is people affected per period, Impact is a scored guess, Confidence is a percentage, Effort is person-weeks.
Where it lies: Reach is measurable and Impact is invented, but they carry equal weight in the multiplication. A feature touching everyone slightly outranks a feature transforming the workflow of your highest-value segment, every single time. RICE has a systematic bias toward broad and shallow.
Counter: segment Reach by value, not headcount. "Reaches 200 enterprise accounts" and "reaches 200 free users" should not produce the same number.
ICE
Impact × Confidence × Ease.
RICE with the honest bit removed. Fast, good for a first pass over a long list, fine for growth experiments where reach is roughly constant.
Where it lies: all three inputs are opinions, so the score inherits whatever the loudest person in the room believes. ICE mostly formalises existing consensus.
Value versus effort
Two axes, four quadrants, sticky notes. Genuinely useful because it is fast and everyone understands it immediately.
Where it lies: "value" is undefined, so each participant silently substitutes their own — revenue, strategic fit, whatever will stop their biggest customer complaining. The grid then produces a shared picture built on unshared definitions.
Counter: define value out loud before anyone places a note. Ten seconds of "value here means impact on activation rate" saves the whole exercise.
WSJF
Cost of Delay ÷ Job Size.
From SAFe, and better than its origin suggests. The strength is Cost of Delay — asking what it costs to not do something reframes conversations productively, especially for work with deadlines or compounding effects.
Where it lies: Cost of Delay is a composite of three more guesses (business value, time criticality, risk reduction). By the time you divide by another estimate, you have stacked four judgements and produced a number to two decimal places. The precision is theatre.
Kano
Different in kind: it classifies rather than ranks. Features fall into basics (absent, people are angry; present, nobody notices), performance (more is better, linearly), and delighters (unexpected, disproportionate goodwill).
Where it lies: categories decay. Today's delighter is next year's basic — this happened to autosave, to search, and is currently happening to AI assistance. A Kano analysis has a shelf life, and teams keep citing one from two years ago.
Best use: arguing against over-investing in performance features when a basic is missing. No amount of excellent reporting compensates for an app that logs people out.
MoSCoW
Must, Should, Could, Won't. Works for scoping a fixed release, badly suited to an ongoing backlog.
Where it lies: everything becomes a Must. Without a hard constraint forcing trade-offs, the categories collapse within two sessions.
Counter: cap Must at a fixed share of capacity — say 60% — and hold the line. The useful category is "Won't, this time", which is a scheduling decision rather than a rejection and defuses most of the argument.
Side by side
| Framework | Best for | Its blind spot |
|---|---|---|
| RICE | Large backlogs, mixed request types | Favours broad and shallow over deep |
| ICE | Fast triage, growth experiments | All inputs are opinion |
| Value / effort | Workshops, quick alignment | "Value" means something different to everyone |
| WSJF | Deadline-driven or compounding work | False precision from stacked estimates |
| Kano | Balancing basics against delighters | Categories go stale |
| MoSCoW | Scoping one fixed release | Everything inflates to Must |
Scoring a list of solutions nobody validated. A perfectly executed RICE over ten features customers do not need produces a well-ordered list of waste. Prioritisation operates on opportunities you have evidence for — it cannot rescue a backlog built from guesses.
What to actually do
- Pick one and stay with it. Comparability across quarters matters more than the model being optimal.
- Score together, out loud. The disagreements during scoring are the entire value; the number is a by-product.
- Treat the output as a draft. If the ranking feels wrong, interrogate it — usually an input was wrong, occasionally the model is missing something real like strategic sequencing.
- Re-score rarely. Monthly at most. Weekly re-ranking is churn dressed as rigour.
Override the score when you have a reason you can say out loud. "This unblocks three later things" is a good reason. "The CEO asked" is at least an honest one. What corrodes trust is overriding silently and continuing to display the scores.
Once the order is settled, the harder job is communicating it — see roadmaps that survive contact with stakeholders.