top of page

The RICE Prioritization Framework Explained

  • Contributor
  • Apr 8
  • 5 min read

RICE is a prioritization framework from Intercom. It scores ideas on four dimensions — Reach, Impact, Confidence, Effort — and produces a comparable number. Used well, it forces explicit thinking about what matters. Used badly, it's false precision: assigning fake numbers to gut feelings and pretending the result is objective.

This guide is how to use RICE well.

The Formula

RICE Score = (Reach × Impact × Confidence) / Effort

Four inputs:

  • Reach: how many people are affected

  • Impact: how much per person

  • Confidence: how sure you are

  • Effort: how much it costs to build

Higher scores indicate higher priority.

Reach

How many people does this affect, in a defined time period?

Examples:

  • "1,000 users per month who view this page"

  • "All active customers — 50,000"

  • "New signups in Q3 — estimated 5,000"

Pick a time period and stick with it (e.g., per quarter or per month). Consistency matters more than the specific period.

Use actual numbers where you have them. Use estimates where you don't, but mark them as estimates.

Impact

How much does this affect each person? Common scale:

  • 3 = massive impact

  • 2 = high impact

  • 1 = medium impact

  • 0.5 = low impact

  • 0.25 = minimal impact

The scale isn't precise. The numbers are heuristic anchors for discussion.

Impact often means "movement on a key metric" — conversion, retention, satisfaction. Be specific about which metric for the impact assessment.

Confidence

How confident are you in the Reach and Impact estimates?

  • 100% = high confidence (data-backed, similar to past work)

  • 80% = medium confidence (some evidence)

  • 50% = low confidence (mostly intuition)

Confidence is the discount you apply for uncertainty. A high-Reach, high-Impact idea with low Confidence still might not be worth doing, because the actual outcome is uncertain.

The discipline of estimating Confidence honestly forces "we don't really know" to be visible.

Effort

How much work is this? Typically measured in person-months (or weeks, or sprints — pick one).

This is the engineering estimate. Get it from the team, not the PM's hopes.

Effort matters because two ideas with the same Reach × Impact × Confidence aren't equivalent — the smaller-effort one delivers value faster.

A Worked Example

Two ideas:

Idea A: Add bulk export to admin panel

  • Reach: 50 admins per month

  • Impact: 2 (high; saves significant time)

  • Confidence: 80% (we know admins want this)

  • Effort: 1 person-month

Score = (50 × 2 × 0.8) / 1 = 80

Idea B: Improve mobile signup flow

  • Reach: 5,000 mobile signups per month

  • Impact: 0.5 (modest improvement)

  • Confidence: 70%

  • Effort: 2 person-months

Score = (5000 × 0.5 × 0.7) / 2 = 875

Idea B scores much higher. The reach is much larger; the per-person impact is smaller but it's multiplied by more people.

What RICE Reveals

Comparing scores often surfaces patterns:

  • High-effort, low-reach ideas score poorly even if exciting

  • Low-effort improvements with broad reach often win

  • High-confidence small wins beat high-confidence big risks

  • The "obvious" priority sometimes isn't obvious

The conversation around the scoring is more valuable than the scores. Why did one idea score higher? Was the input fair? Is the team aligned on the framing?

Where RICE Goes Wrong

False precision. Treating the number as objective. RICE inputs are estimates; the output is too.

Inflated estimates. Sponsors of an idea inflate Reach or Impact to win the comparison.

Unconsidered effort. Engineers not consulted; effort estimates are PM wishes.

Stale scores. Scoring done once at quarterly planning; never updated when context changes.

Comparing apples and oranges. Comparing very different kinds of work (a feature vs. tech debt vs. a bug fix) where the dimensions don't translate.

The fix: treat the numbers as inputs to discussion, not as decisions.

Where RICE Doesn't Fit

Not every decision benefits from RICE:

  • Strategic decisions. "Should we enter this market?" RICE can't capture this.

  • Compliance/legal work. Must-do regardless of score.

  • Bug fixes. Different framework (severity, customer impact).

  • Refactoring/tech debt. Hard to measure Reach and Impact directly.

  • Exploratory work. Confidence is fundamentally low; that's the point.

For these, use other frameworks (or no framework). Don't force RICE.

Combining With Other Frameworks

RICE complements:

  • MoSCoW: RICE produces scores; MoSCoW puts them into Must/Should/Could/Won't.

  • Kano model: distinguishes basic, performance, and delighter features.

  • WSJF (Weighted Shortest Job First): alternative formula, similar spirit.

You don't need to commit to one framework. Use the lens that fits the decision.

RICE for Quarterly Planning

A common pattern:

  1. Team collects ideas

  2. Score each with RICE

  3. Sort by score

  4. Pick top N that fit the quarter's capacity

  5. Discuss any low-scoring items that nonetheless made the cut

The discussion in step 5 is important. Sometimes a low-scoring item is critical for other reasons (compliance, strategy). RICE doesn't kill it; it just makes the trade-off visible.

The "Confidence" Discipline

Many teams skip Confidence or set it to 100% by default. This defeats the purpose.

Real Confidence assessment:

  • "We have data" → 80-100%

  • "We've heard from users" → 60-80%

  • "We think users want this" → 40-60%

  • "We're guessing" → 20-40%

When the Confidence drops below 50%, the right question is often "should we run an experiment first?" rather than "should we build this?"

Effort Estimation Realism

Effort is the input most often wrong. Engineers estimate optimistically; reality is worse.

Mitigations:

  • Use historical data — actual time for similar work

  • Add a multiplier for uncertainty (1.5x or 2x for novel work)

  • Get effort estimates from the engineers who'd do the work, not just the lead

Wrong effort estimates cascade into wrong RICE scores.

A Quick RICE Audit

For each idea on your scoring sheet:

  • Is the Reach number defensible?

  • Is the Impact level grounded in something?

  • Is the Confidence honest?

  • Has Effort been estimated by engineering?

If any answer is no, the score is suspect. Fix the input before trusting the output.

Documenting RICE Decisions

After RICE-based prioritization, capture:

  • The ideas considered

  • Their scores

  • The decisions made

  • Any ideas that scored high but were rejected (with reasons)

  • Any ideas that scored low but were chosen (with reasons)

The documentation helps future planning by surfacing past trade-offs.

Anti-Patterns

RICE-as-decision. Scoring decides; no discussion. Misses context.

Inflating to win. Sponsors gaming the inputs. Defeats the framework.

Skip Confidence. Treating all ideas as equally certain. Hides risk.

One-time scoring. Scoring done at planning; never updated as the team learns more.

RICE for everything. Forcing it onto decisions that don't fit.

Key Takeaway

RICE scores ideas on Reach, Impact, Confidence, Effort, producing a comparable number. The score is an input to discussion, not a decision. Estimate honestly — especially Confidence, often skipped. Get Effort from engineers. Combine with other frameworks where useful. Use RICE for feature prioritization within a team or product; don't force it onto strategic, compliance, or exploratory decisions. The framework's value is in the conversation it forces, not in the numerical output.

Related reading

Keep learning. This article is part of the Requirements & Business Process Improvement path in the ShiftQuality Learning Center. Elicit, prioritize, and trace requirements that survive reality.

bottom of page