Key takeaways
  • RICE scores features on Reach, Impact, Confidence and Effort (Intercom).
  • It's useful structure but dangerous false-precision: the number is a prompt, not a decision.
  • Know when RICE fails, and which alternative frameworks fit better.

RICE is the prioritisation framework most product teams reach for first, and it's a defensible choice. The formula is short enough to remember, the four factors cover most of what matters, and the output is a single number you can rank by. It's the closest thing the product world has to a default. Sean McBride at Intercom published the original framework in 2016 as the system they used internally to choose between competing feature ideas, and it spread because, unlike most prioritisation frameworks, it's actually usable on a Tuesday afternoon.

It also has a specific failure mode that nobody warns you about, which is that the output looks like a calculation but is mostly judgement. The number at the bottom of the spreadsheet is precise to two decimal places and confident in a way the inputs aren't. Teams that treat the score as the decision, rather than as a structured way to surface the disagreement underneath, end up shipping the wrong things, on schedule, and feeling rigorous about it.

The Intercom framework.

Sean McBride wrote up RICE while at Intercom, where the team needed a way to compare wildly different feature ideas (a small UX tweak against a major platform feature against an internal tool) without burning a whole leadership meeting on each one. The four factors were chosen to be cheap to estimate, hard to game, and easy to explain to a stakeholder asking why their pet feature isn't shipping next quarter. The framework has spread well beyond Intercom; it's now most teams' default if they're using any framework at all.

The four factors.

Diagram · The RICE formula — four factors, one score
The RICE formula visualised — Reach times Impact times Confidence divided by Effort produces a score A horizontal row of four equally sized boxes representing the four RICE factors. From left to right: Reach with example value two thousand users per quarter; Impact with example value zero point five; Confidence with example value eighty per cent; Effort with example value two person months. Between the boxes are mono operators showing multiplication and division: times between Reach and Impact, times between Impact and Confidence, divided by between Confidence and Effort. Below the row a vertical arrow flows down to a large marigold pill labelled RICE Score equals four hundred, the result of the formula. FORMULA — R × I × C / E R Reach e.g. 2,000 users / qtr × I Impact e.g. 0.5 per user × C Confidence e.g. 80% how sure ÷ E Effort e.g. 2 person-months RICE SCORE = 400 (2,000 × 0.5 × 0.8) ÷ 2 = 400 score The score is the conversation starter — not the answer. Compare scores within a tier of similar work. Don't compare strategic against tactical.
The formula is simple. The danger is the precision. A score of 400 looks more certain than the underlying inputs — Confidence is, by definition, the team admitting they're guessing.

Reach. How many users will this affect in a defined time window? A quarter is the typical horizon. Important: Reach is the count of real users who will encounter the feature in that window, not the size of the addressable market. A feature that 200 users will use this quarter has Reach = 200, even if a million users could theoretically use it.

Impact. How much does the feature move the metric per user who experiences it? Intercom's original framework uses a five-point scale: 3 = massive, 2 = high, 1 = medium, 0.5 = low, 0.25 = minimal. This is where most of the false precision lives. The difference between "high" and "medium" for an unbuilt feature is almost always a guess.

Confidence. How sure are you about the Reach and Impact numbers? 100% if you've A/B tested. 80% for strong qualitative evidence. 50% for an educated guess. The Confidence factor is the framework's clever move — it bakes the team's uncertainty into the score directly, so high-conviction features automatically outrank low-conviction ones with equal upside.

Effort. Estimated person-months of work, including design, engineering, QA. The unit doesn't matter as long as you use it consistently across the backlog. Effort is the only factor an engineer will give you a reliable number for, and even that is famously bad. Every engineer has heard the joke about "two weeks" estimates.

The formula.

The formula is R × I × C / E. The output is a single number, the "RICE score", that you use to rank features. Higher is better. The maths is straightforward; the meaning is not. A feature with Reach 2,000, Impact 0.5, Confidence 80% and Effort 2 person-months scores (2,000 × 0.5 × 0.8) ÷ 2 = 400. A different feature scoring 350 is, on the framework's own terms, less valuable. The honest test of whether your team is using RICE well is whether they'd actually swap the 400 for the 350 if you proved the underlying numbers were uncertain. Mostly, they wouldn't.

The false-precision trap.

The single biggest failure mode of RICE is treating the score as if it carried the precision of its decimal places. Three of the four inputs (Reach, Impact, Confidence) are guesses. The fourth, Effort, is famously unreliable. Multiply four soft numbers together and you get an output that's at best as soft as its softest input, but presented as a clean number that defeats most stakeholder arguments. The team that wins the prioritisation debate is the one with the slickest spreadsheet, not the one with the strongest evidence.

The honest fix is to round aggressively. Bucket the output into tiers (Top, Middle, Lower) and treat scores within a tier as equivalent. If two features score 350 and 400, that's noise. If two features score 100 and 800, that's signal. Treating the precise decimal as meaningful is what gets teams arguing about whether to ship the 380 ahead of the 350, when the underlying inputs are guesses inside a 50-point margin of error.

When RICE works.

  • Long backlog of comparable scope. Twenty feature ideas, all roughly tactical, all in the same product area. RICE produces a defensible ranking that surfaces the obviously high-value and obviously low-value items quickly.
  • Team needs a transparent process. Stakeholders want to know why their feature didn't ship. A RICE score gives you a reason that's harder to argue with than "we chose to focus elsewhere."
  • Quarterly planning. The horizon matches the framework. Reach over a quarter is a sensible unit. Effort over a quarter is roughly tractable.

When RICE fails.

  • Strategic vs tactical. A platform migration and a colour change can't be compared in the same RICE table. The strategic item will lose to the tactical one because Reach × Impact for "rebuild the auth system" is hard to score, and Confidence will be low. Run two tables, one for strategic, one for tactical, or use a different framework for the strategic tier.
  • Dependencies. RICE has no notion of order. A high-RICE feature that depends on a lower-RICE prerequisite will look mis-prioritised in the table. The framework doesn't model the dependency graph.
  • Capacity constraints. RICE ranks features. It doesn't tell you which features your team has the skills to ship. The highest-RICE feature is useless if it needs ML expertise your team doesn't have.
  • Reach asymmetry. Features serving a small but critical segment (your largest enterprise customer, regulators) score badly on Reach. They may still be the right thing to ship.
RICE gives you a number. A number isn't an answer.

Alternative frameworks.

  • MoSCoW: Must, Should, Could, Won't. Good for binary release scoping. Bad for ranking inside a tier.
  • Kano: basic needs, performance needs, delighters. Good for understanding which features are table stakes vs differentiating. Bad for stack-ranking.
  • Eisenhower matrix: urgent vs important. Good for personal prioritisation. Bad for cross-team feature decisions.
  • Cost of delay: what does it cost the business per unit time we don't ship this? Powerful for revenue-bearing features. Harder to use for product-market-fit work.

None of these are better than RICE in every case. Each works in a different context. The product leader's job is to pick the framework that fits the question, not to pledge allegiance to one for life.

RICE as input to judgement.

The way to use RICE well is to treat the score as the start of the conversation, not the end of it. Run the calculation. Surface the disagreements about the inputs — typically Impact and Confidence are where the team will diverge. Then make the call with the score in hand, not because of it. The leader who can say "the score puts this third, but I'm going to prioritise it first because the strategic context is X" is using the framework correctly. The leader who lets the score decide is outsourcing the judgement.

How we use this at Product Pieces.

We use RICE as a forcing function for honesty, not as a calculator. The most valuable bit is the Confidence factor: asking the team to commit to a Confidence number on each item exposes which decisions are built on solid ground and which are guesses. If 60% of the backlog is at 50% Confidence, you're not prioritising features. You're betting on opinions. The fix is upstream: more discovery, fewer items in the backlog, sharper Acceptance Criteria. See N°34 · The Backlog.

We also refuse to run RICE across tiers of work. Strategic and tactical get separate tables. Run-the-business and change-the-business get separate tables. Pretending they're comparable inside the same formula is how teams end up shipping ten small wins and zero strategic moves.

Next issue: N°25, KPIs vs Metrics. Not the same thing.