framework · prioritization
RICE prioritization framework
Best for: Stacking features against each other when reach varies significantly across candidates and you need a scored, defensible rank order to bring to stakeholders or an interview.
RICE is the prioritization scoring method that turns opinion into a defensible number: RICE Score = (Reach × Impact × Confidence) / Effort. Sean McBride invented it at Intercom to give PMs a common language for comparing features that affect very different audience sizes. That origin is load-bearing. It was built for a growth-stage product with established reach data, clear impact proxies, and real engineering cost. When any of those inputs are missing or distorted, the score is misleading. Most interview candidates recite the formula and miss the three calibration moves that tell an interviewer whether the candidate actually uses it.
The formula: what each input means precisely
Reach is the number of users who will encounter this feature in a defined period, typically a quarter. Not registrations. Not the total user base. The subset who will actually hit the changed surface. A feature on the checkout confirmation page might reach 100% of weekly purchasers; a feature buried in settings might reach 3%.
Impact uses a fixed scale from Intercom’s original spec: 3 = massive, 2 = high, 1 = medium, 0.5 = low, 0.25 = minimal. These are ordinal tiers, not a continuous variable. Resist assigning a 1.7. The coarseness is intentional: it forces you to commit to a tier rather than hiding behind false precision.
Confidence is the quality of evidence behind your Reach and Impact estimates, expressed as a percentage:
- 100%: hard data from a comparable prior change or controlled experiment
- 80%: directional data, strong qualitative signal, solid analogue from adjacent feature
- 50%: informed gut, no comparable data
- Below 50%: stop and do discovery before prioritizing
If Confidence is below 50%, RICE is not the right next step. A discovery sprint is.
Effort is total person-months across all functions: engineering, design, QA, and PM time. Not story points in isolation. Not just engineering. A feature that requires two engineers for a month and half a designer for two weeks is roughly 2.5 person-months.
The output is “total impact per unit of work,” which is why higher scores win.
A worked example
Goal: increase monthly active paying users for a B2B data tool (current base: 50,000 MAU, 8,000 paying).
| Feature | Reach | Impact | Confidence | Effort | RICE Score |
|---|---|---|---|---|---|
| Inline CSV export | 12,000 | 1 | 80% | 0.5 | 19,200 |
| AI-generated summary card | 8,000 | 2 | 50% | 1.5 | 5,333 |
| SSO/SAML integration | 2,000 | 3 | 100% | 3.0 | 2,000 |
| Dark mode | 40,000 | 0.25 | 100% | 1.0 | 10,000 |
CSV export wins despite medium Impact because Reach and low Effort compound. SSO has massive Impact but low Reach and high Effort. Dark mode has huge Reach but minimal per-user Impact. The AI summary card scores lowest partly because of low Confidence: 50% means you should run a discovery sprint before betting 1.5 person-months on it.
The interviewer wants to hear you read the table critically, not just declare a winner. Say why SSO might still be the right strategic bet even though RICE scores it last: it opens an enterprise segment with higher contract value and a different willingness to pay. The score starts the conversation; it does not end it.
The 2026 reframe: what happens when Effort approaches zero
RICE was designed when Effort was the binding constraint. In 2026, shipping an LLM wrapper or AI feature prototype takes days. LLM API costs dropped roughly 80% between early 2025 and early 2026. A 36x gap now exists between premium and budget model providers. When Effort approaches zero, the RICE score approaches infinity, and every AI feature looks like a priority one.
This is a distortion, not a win. Candidates who notice it and say so out loud clear a bar that most candidates miss.
Two adjustments worth naming in an interview:
First, split Effort into build cost and operate cost. An AI feature that takes two weeks to build might cost $40,000 per year in inference, monitoring, and retraining. The operate cost is often larger than the build cost, and it is not in the original formula. That ongoing cost belongs in the denominator alongside the initial build.
Second, when Effort is no longer discriminating, the signal shifts entirely to Reach × Impact. Reach is the Viable question: is this a problem enough users have, in a market large enough to cover costs and generate margin? Impact is the Lovable question: do users care enough to change behavior, pay, and return? Fewer than 20% of AI pilots scale to production within 18 months (McKinsey). Gartner estimates 60% of AI projects will be abandoned by end of 2026 for lack of AI-ready data. The failure mode is almost never “we could not build it.” It is “we built it and no one used it” or “the model behaved well in demo and badly in production.”
Teams at Cursor, Perplexity, and Klarna have each shipped 50+ AI features in months. Their constraint is not “can we build this” but “which of these things will users actually love and pay for.” In 2026, RICE is functionally a Reach × Impact question with Effort as a tiebreaker.
Strong vs weak answers in a live interview
strong
"RICE is (Reach × Impact × Confidence) / Effort, where Reach is users touched in a period, Impact uses Intercom's 0.25 to 3 ordinal scale, Confidence is evidence quality as a percentage, and Effort is total person-months across all functions. Before I score anything, I'll note the goal: we're optimizing for paid conversion this quarter. A few calibration points I always apply: if Confidence is below 50%, I stop and do discovery rather than prioritize, because a low-confidence score is laundered wishful thinking. On Effort: I separate build cost from operate cost. An AI feature might be two weeks to build but $60K/year to run at scale. And when Effort is close to zero across the board, which is increasingly true for API-wrapped features, I treat Reach and Impact as the real discriminators. That's the Viable and Lovable question: is this a problem enough people have, and will they love it enough to pay and return? Here are the numbers for these three features..." [works through table, names top pick, flags lowest-Confidence item as needing a discovery sprint before commitment].
weak
"RICE is Reach times Impact times Confidence divided by Effort. Feature A has a Reach of 1,000, Impact of 3, Confidence of 80%, Effort of 2 months, so RICE is 1,200. Feature B scores 900. Build Feature A." This recites the formula, assigns numbers with no stated basis, treats Effort as purely engineering sprints, ignores whether 80% Confidence is justified, and says nothing about what happens to the Effort denominator when an AI feature takes a weekend. Interviewers at AI-native companies flag this pattern immediately.
RICE vs ICE vs MoSCoW
ICE (Impact × Confidence × Ease) omits Reach and multiplies by Ease rather than dividing by Effort. Use ICE when reach is roughly comparable across candidates, you are pre-PMF running fast experiments, or you need a score before you have reach data. Use RICE when reach varies meaningfully and you have at least proxy data to anchor it.
MoSCoW is a categorization tool, not a ranking tool. It tells you which bucket a feature belongs in, not which order to build within that bucket. Use MoSCoW for stakeholder alignment conversations; use RICE when you need an actual ranked list.
Value vs. Effort is a 2x2 for quick visual triage. Useful for spotting obvious quick wins in a workshop; not a substitute for scored prioritization when the team needs a committed sequence.
When not to use RICE
Skip the scoring when the answer is obvious enough that quantifying it wastes time. If a P0 bug is blocking 15% of users at checkout, you do not need a formula. If a regulatory change makes a feature mandatory, RICE does not help you decide. Reaching for a framework when the prioritization is self-evident is a junior tell. Naming that clearly in an interview is a senior one.
Also skip RICE when you are pre-PMF. At that stage you have almost no real Reach or Confidence data, so any scores you produce are noise. Run experiments and use ICE to rank them by how fast you can learn.
Use it, do not recite it
Name the goal before touching the formula. Defend each Confidence score with a specific evidence type. Call out the Effort split between build and operate. Flag the 2026 distortion when Effort is near zero. Close by naming your pick and what you would do to raise Confidence on the runner-up before committing. That arc, run in under three minutes, is what the interviewer at an AI-native company is listening for.
See also: ICE scoring, feasibility is free, proving viability, and how to prioritize your backlog.
Related
- ICE scoring framework prioritization
- MoSCoW prioritization: the right way to run it prioritization
- Value vs effort 2x2 prioritization (how to use it without just drawing a box) prioritization