Every backlog is longer than every team. So the real product question is never "what should we build?", there are always more good ideas than hands. It's "what do we build first, and what are we willing to let wait?" Prioritisation frameworks exist to drag that decision into the open, so it's made by a method the team can see and challenge, rather than by whoever is most senior, most insistent, or most recently in the room.

The quick version

  • RICE scores each idea as (Reach × Impact × Confidence) ÷ Effort, turning four rough guesses into one comparable number. Sean McBride built it at Intercom (2018) to settle growth-team debates with estimates instead of opinions.
  • MoSCoW sorts work into Must, Should, Could and Won't-have-this-time. Dai Clegg created it at Oracle in 1994; it's the prioritisation core of DSDM. Its discipline is the cap: keep "Must" to no more than ~60% of effort so you have room to flex.
  • Cost of delay asks a different question, not "how big is this?" but "what does waiting cost us per week?" Don Reinertsen's rule: if you quantify only one thing, quantify the cost of delay. Order work by value-over-time, not size.
  • None of these decides for you. The score is an input, not a verdict. The honest move is to use the framework to surface the argument, then make, and own, the call.

The idea in depth

RICE: turn four arguments into one number

RICE was born from a specific frustration. Sean McBride, a product manager on Intercom's growth team, kept watching prioritisation meetings stall on gut feel, every idea's champion certain theirs mattered most. In a 2018 post on Intercom's blog he laid out the fix: score each project on four factors and combine them into a single number. Reach, how many people this affects in a set period (say, customers per quarter). Impact, how much it moves the goal, picked from a fixed scale (3 for "massive", 2 "high", 1 "medium", 0.5 "low", 0.25 "minimal"). Confidence, how much you trust your own estimates, as a percentage (100% high, 80% medium, 50% low). Effort, total work in person-months across product, design and engineering. The score is (Reach × Impact × Confidence) ÷ Effort: total impact per unit of work.

The value isn't really the number, it's what producing the number forces. To give an idea a RICE score you have to state, in public, how many people it reaches and how confident you actually are. That confidence multiplier is the quiet genius of it: a flashy idea resting on a hunch gets discounted to half its swagger, while a smaller, well-evidenced bet holds its ground. In practice, this means RICE-scoring your top eight contested items before the next planning meeting and walking in with the table, not a manifesto. The conversation shifts from "I feel strongly about X" to "your reach estimate looks high, why?" That's a far more productive fight.

The limitation is precision theatre. A RICE score looks objective, it has decimals, but it's built from four estimates, and multiplying guesses doesn't launder them into facts. McBride himself frames it as a tool to inform debate, not replace judgement. Effort sits on the bottom of the fraction, so anything cheap scores well, which can quietly starve the big, slow, strategic bets a roadmap also needs. Treat the ranking as a prompt to inspect the close calls, not a league table to obey.

MoSCoW: the power is in the cap, not the labels

MoSCoW is the one most teams think they already know: sort work into Must have, Should have, Could have and Won't have (the lowercase o's just make it sayable). Dai Clegg devised it at Oracle in 1994, and it became a foundational technique of DSDM, the agile delivery framework now stewarded by the Agile Business Consortium. The categories are deceptively simple, and that simplicity is also the trap, used loosely, everything drifts into "Must" and the method achieves nothing.

What rescues it is a rule most people skip. DSDM is explicit that the labels are an effort budget, not a wish list: keep Must-have work to no more than about 60% of the team's effort, with a "sensible pool of Could-haves, usually around 20% effort" acting as deliberate contingency. The reasoning is plain, if 90% of your release is "Must", you have no slack, so the first surprise blows the deadline. And the fourth category does real work: "Won't have" means "not this time", which makes saying no a recorded decision rather than a silent omission you have to re-litigate every week. So add up the effort behind your Musts. If it crosses 60% of capacity, the conversation isn't finished, something on that list is really a Should, and you need to find it now, not in week six.

"Won't have this time", not no forever, just no on the record, so you stop re-deciding it.

Where MoSCoW breaks down is comparison. It tells you which bucket each item is in, but not how to rank items within a bucket, and "Must" is notoriously gameable, every stakeholder believes their feature is non-negotiable. It's strong for scoping a fixed-deadline release ("what must ship by launch?") and weak as a standing tool for ordering an open-ended backlog, where a scoring method like RICE or cost of delay does more.

Cost of delay: the question the other two skip

RICE and MoSCoW both size work. Neither asks what time itself is worth, and that omission is expensive. Cost of delay is the economic lens, made central by Don Reinertsen in The Principles of Product Development Flow (2009). His blunt instruction: "If you only quantify one thing, quantify the cost of delay." The idea is concrete, if a feature would earn (or save) an estimated $50,000 a month and you ship it three months late, that delay cost you an estimated $150,000, whether or not it appears on any invoice.

Cost of delay reframes prioritisation as a queue you're paying to hold. Reinertsen's practical ordering rule is Weighted Shortest Job First (WSJF), cost of delay divided by duration. Two features may carry the same delay cost, but the one you can finish in a fortnight should jump the one that takes a quarter, because you stop the bleeding sooner and free the team for the next item. Run the question across your top backlog items, "what does each cost us per week of waiting?", and the answers reorder the list fast. The urgent-but-small thing that's been losing every effort comparison suddenly leaps up, because its weekly cost is high and its duration is tiny.

The honest limitation: most cost-of-delay numbers are estimates wearing a dollar sign, and false precision here is more dangerous than in RICE because the output looks like finance. Reinertsen's own defence is that a rough quantification beats none, even sorting items into "high / medium / low urgency" exposes assumptions that "important" hides. Use it where the economics are genuinely estimable, and where you can't, use its question ("what does waiting cost?") as a tie-breaker rather than inventing spurious figures.

flowchart TB
  Q("What kind of decision is this?")
  A("Ranking an open backlog of ideas?")
  B("Scoping a fixed-deadline release?")
  C("Is timing / urgency the crux?")
  R(["RICE, (Reach×Impact×Confidence) ÷ Effort"])
  M(["MoSCoW, Must / Should / Could / Won't, capped at ~60% Must"])
  D(["Cost of delay / WSJF, value-per-week ÷ duration"])
  Q --> A --> R
  Q --> B --> M
  Q --> C --> D
A rough guide to which tool fits which question, most teams end up using two together. Leaders Loop

A worked example

Picture a 25-person SaaS company, call it Loomwork, planning its next quarter. (Illustrative figures throughout; the shape is realistic, the numbers are invented to show the method.) Four things are fighting for the same engineers: a self-serve onboarding flow, a long-promised SSO login for enterprise deals, a reporting dashboard, and a checkout bug that intermittently drops payments.

They start with RICE to rank the discretionary work. Onboarding: reach 2,000 signups/quarter, impact 2, confidence 80%, effort 3 person-months → (2000 × 2 × 0.8) ÷ 3 ≈ 1,067. The dashboard: reach 600, impact 1, confidence 50%, effort 4 → (600 × 1 × 0.5) ÷ 4 = 75. RICE makes the gap visible, the dashboard had a loud internal champion, but its low reach and shaky confidence sink it. Onboarding wins the discretionary slot.

But two items don't belong in a RICE table at all. The checkout bug is a cost-of-delay case: it's leaking an estimated $8,000 a week in failed payments, and it's a two-day fix. Value-per-week is huge, duration tiny, WSJF rockets it to the very top, ahead of everything, including onboarding. No reach estimate was needed; the weekly cost decided it. And SSO is governed by MoSCoW: a $200k enterprise contract is contingent on it shipping by the renewal date, so for that release it's a hard Must, regardless of its RICE score. The lesson Loomwork takes away is the real one: no single framework ran the quarter. Cost of delay caught the urgent-and-small, MoSCoW caught the deadline-bound, and RICE sorted the genuinely optional middle, which is exactly how mature teams use them.

flowchart LR
  BUG(["Checkout bug, $8k/week, 2 days"])
  SSO(["SSO, contractual deadline"])
  ONB(["Onboarding, RICE ≈ 1,067"])
  DASH(["Dashboard, RICE ≈ 75"])
  BUG -->|cost of delay: do now| ORDER("This quarter's order")
  SSO -->|MoSCoW: Must by renewal| ORDER
  ONB -->|RICE: top discretionary| ORDER
  DASH -->|RICE: defer| ORDER
Loomwork's quarter, set by three lenses at once. Figures illustrative. Leaders Loop

Frequently asked questions

Which framework should I actually use?

Match the tool to the question. Ranking a big, open backlog of optional improvements → RICE. Scoping what must ship by a fixed date → MoSCoW. Deciding what's costing you most to delay, or breaking a tie between two big bets → cost of delay / WSJF. Most strong teams run two in combination, as in the example above, rather than swearing allegiance to one.

Isn't this all just spreadsheet theatre?

It can be, if you treat the score as the decision. The point isn't the number, it's the conversation the number forces. RICE makes people defend a reach estimate; MoSCoW's 60% cap forces a real "what gives?"; cost of delay makes someone put a figure on waiting. The artefact is disposable. The argument it surfaces is the value.

How is RICE different from a simple value-vs-effort matrix?

A value/effort matrix collapses everything into two axes. RICE splits "value" into three honest components, reach, impact and, crucially, confidence, so a high-value idea built on a hunch doesn't outrank a modest one backed by evidence. The confidence multiplier is the part a 2×2 grid quietly hides.

Why does MoSCoW cap "Must" at 60%?

Because a plan with no slack can't absorb surprises, and product work always brings surprises. DSDM's guidance is to keep Must-have effort to roughly 60% of capacity and hold ~20% as Could-haves, deliberate contingency you drop if things go sideways. If nearly everything is a "Must", the first delay breaks the whole release rather than just the optional edges.

Do these replace product strategy?

No, and this is the most important caveat. Prioritisation frameworks rank items against a goal; they can't tell you the goal is right. Score a backlog of the wrong features beautifully and you'll efficiently build the wrong product. Strategy decides the direction; these tools decide the order within it. Get the order of operations backwards and the maths just makes you faster at being wrong (see product strategy & vision).

Related in the Toolkit

Where to go next