RICE Framework
A scoring model for product prioritization using four variables: Reach, Impact, Confidence, and Effort.
Origins
In 2015, the product team at Intercom published a blog post describing a scoring system they had developed internally to reduce the subjectivity in their prioritization decisions. Like most product teams, they had been holding planning meetings where the loudest voice or the most senior person often determined what got built next — a process that felt collaborative but was neither rigorous nor defensible.
Their solution was to score every candidate project on four factors — Reach, Impact, Confidence, and Effort — combine them into a single number, and sort the backlog by score. The approach gave the team a shared vocabulary and a method that could be applied consistently across different types of work. The post was widely shared, and the RICE framework became one of the most commonly used product prioritization tools in the industry.
The Core Idea
Prioritization is one of the hardest problems in product management, because it requires making explicit trade-offs between competing goods: a feature that helps many users a little versus one that helps a few users enormously; a quick win versus a long-term investment; a high-confidence improvement versus a speculative bet.
RICE provides a formula for converting those trade-offs into a number, making comparison possible across very different kinds of work. It does not eliminate judgment — it structures and documents it.
The RICE formula:
RICE Score = (Reach × Impact × Confidence) / EffortA higher RICE score means higher priority.
The Four Components
Reach
Definition: How many people will this project affect, within a given time period?
Unit: Number of users (or transactions, or events) per quarter.
How to estimate it: Use existing data where possible — active users who would encounter the feature, number of accounts in the relevant segment, monthly transaction volume in the affected flow. Reach is a count, not a percentage.
Example: A new onboarding flow affects every new user. If you acquire 500 new users per month, Reach = 1,500 (per quarter). A feature for enterprise admins might affect only 40 accounts. Reach = 40.
Impact
Definition: How much will this project move the needle for each individual it reaches?
Scale: A fixed multiplier chosen from: 3 (massive), 2 (high), 1 (medium), 0.5 (low), 0.25 (minimal).
How to estimate it: Impact is deliberately difficult to measure precisely, which is why RICE uses a coarse scale rather than a continuous one. The question is: for each person this touches, how significantly does it change the metric you care about — activation, retention, revenue, support load?
Note: Impact and Reach together approximate the total effect. A project with high Reach and low Impact can outscore a project with low Reach and high Impact, or vice versa. Both dimensions matter.
Confidence
Definition: How confident are you in your estimates of Reach, Impact, and whether this is the right thing to build?
Scale: 100% (high confidence — data and evidence back this up), 80% (medium confidence — some data, some assumption), 50% (low confidence — mostly a hunch). Scores below 50% are a signal to run a discovery or research spike before adding the item to a roadmap.
Why it matters: Confidence acts as a penalty for optimism. Without it, every team scores their favorite project at maximum Reach and Impact. Confidence forces the scorer to be honest about which estimates are backed by research and which are aspirational.
Effort
Definition: How much total work does this project require, in person-months?
Unit: Person-months across all roles (product, engineering, design, data). One person working for one month = 1. Two engineers plus one designer for two months = 6.
How to estimate it: Use your team’s standard estimation process — T-shirt sizing, story points converted to time, or rough engineering hours. The key is consistency: Effort estimates must be comparable across all items being scored.
Effort is the denominator. A project with a score of 120 that takes 2 person-months (score per person-month: 60) is better than one with a score of 180 that takes 6 person-months (score per person-month: 30).
Worked Example: Comparing Three Features
| Feature | Reach | Impact | Confidence | Effort | RICE Score |
|---|---|---|---|---|---|
| Redesigned onboarding flow | 1,500 | 2 | 80% | 3 | 800 |
| In-app CSV export | 200 | 1 | 100% | 1 | 200 |
| AI-powered search | 800 | 3 | 50% | 8 | 150 |
Calculation for the onboarding flow: (1,500 × 2 × 0.80) / 3 = 2,400 / 3 = 800
The AI search feature has the highest potential impact per user, but the low confidence and high effort drag its score well below the simpler onboarding improvement. This is the kind of insight RICE is designed to surface — the high-glamour project is outranked by the high-probability one.
Running a RICE Exercise with Your Team
- Define the time horizon first. All Reach estimates must use the same period (usually a quarter). Mixing quarterly and annual estimates destroys comparability.
- Score independently before discussing. Have each person score the same set of items privately. Then compare. Where scores differ significantly, the disagreement itself is the value — it surfaces different assumptions about customers or strategy.
- Document the reasoning, not just the number. A RICE score without the underlying reasoning is difficult to challenge or revisit. Note the data source for Reach, the rationale for Impact, and what would raise your Confidence score.
- Rescore when new information arrives. A RICE score is a snapshot based on current knowledge. When you get research data, retention numbers, or engineering estimates, update the score.
RICE vs. ICE
ICE (Impact, Confidence, Ease) is a simpler variant: no Reach factor, and Ease replaces Effort (higher Ease = easier = better). ICE is faster to apply and works well for teams that need a quick triage tool with less data. RICE is more precise and better suited for product teams that have user data and can make defensible Reach estimates.
| ICE | RICE | |
|---|---|---|
| Formula | Impact × Confidence × Ease | (Reach × Impact × Confidence) / Effort |
| Complexity | Low | Medium |
| Best for | Quick triage, early teams | Data-informed product teams |
| Missing | Volume of users affected | — |
Other Prioritization Frameworks
- MoSCoW (Must have / Should have / Could have / Won’t have): a categorical system for scoping a release. Good for stakeholder alignment, less good for comparing items within the same category.
- Kano Model: classifies features by the relationship between implementation and customer satisfaction — Basic needs, Performance needs, Delighters. Useful for early product strategy; not a scoring system.
- Opportunity Scoring: from Anthony Ulwick’s Outcome-Driven Innovation — rates jobs by importance and current satisfaction. High importance + low satisfaction = prioritize. More research-intensive than RICE.
Limitations
- False precision. A RICE score of 320 is not meaningfully more accurate than a score of 300. The framework produces numbers that look precise but are built on estimates. Treat scores as rough rankings, not exact measurements.
- Gaming the system. Teams that know their project will be evaluated by RICE will unconsciously (or consciously) inflate Reach and Impact estimates. Consistent calibration — reviewing past scores against actual outcomes — is the antidote.
- Does not capture strategic value. A project that opens an entirely new market, satisfies a strategic partnership commitment, or reduces a compliance risk may score low on RICE but be the right thing to do. RICE should inform strategic decisions, not replace them.
- Effort estimates are notoriously unreliable. Since Effort is the denominator, underestimating effort inflates the score significantly. Teams that consistently underestimate should apply a correction factor.
Key Takeaway
RICE is a tool for making prioritization decisions more explicit, consistent, and data-grounded — not for making them automatic. Its real value is not the score itself but the discipline of forcing a team to agree on what Reach, Impact, Confidence, and Effort actually mean for each candidate project before a single line of code is written. When teams disagree sharply on a score, they have found the real conversation: not about the formula, but about what they believe is true about their users and their strategy.