RICE Prioritization: How to Score Your Roadmap

7 min read · 2026-10-08

RICE prioritization scores each roadmap candidate with the formula Reach × Impact × Confidence ÷ Effort. Reach is how many people the work affects in a set period, Impact is how much it affects each of them, Confidence is how sure you are about those estimates, and Effort is the team time required. Higher scores mean more value per unit of work.

This guide covers each factor's scale, a fully worked scoring example, how to run a scoring session with your team, where RICE breaks down, and a phased plan to score and rank your next quarter's roadmap in about two weeks.

The roadmap at a glance

Goal: Score and rank next quarter's roadmap candidates with RICE and turn the ranking into a defensible plan. Duration: 2 weeks of scoring, then a 13-week quarter

  1. Prepare the Candidate List (Days 1-2)

    Build a clean list of comparable initiatives to score.

    • Collect candidate initiatives from the backlog, discovery work, and stakeholder requests.
    • Rewrite each candidate as a clear initiative with a one-sentence problem statement.
    • Merge duplicates and split anything too large to estimate as a single unit.
    • Remove items that are mandatory, like compliance work, and schedule them separately.

    Milestone: A deduplicated list of comparable initiatives with problem statements.

  2. Agree on Scales (Days 3-4)

    Define how each RICE factor will be measured before anyone scores.

    • Choose a reach period, such as users or accounts affected per quarter.
    • Adopt a fixed impact scale like 3, 2, 1, 0.5, and 0.25.
    • Set confidence levels at 100, 80, and 50 percent with clear criteria for each.
    • Define effort in person-months or person-weeks across product, design, and engineering.
    • Document the scales in the scoring spreadsheet so everyone uses the same definitions.

    Milestone: A scoring sheet with written definitions for every factor and scale.

  3. Gather Evidence (Days 5-7)

    Ground reach and confidence estimates in real data.

    • Pull reach numbers from product analytics, such as monthly users of a related flow.
    • Review customer interviews, support tickets, and sales notes for impact signals.
    • Ask engineering and design leads for rough effort estimates per initiative.
    • Note the evidence source next to each estimate in the spreadsheet.

    Milestone: Every initiative has reach, impact, and effort estimates with a cited evidence source.

  4. Score and Calibrate (Days 8-10)

    Calculate RICE scores and sanity-check the resulting ranking as a team.

    • Calculate scores with a spreadsheet formula and sort from highest to lowest.
    • Review the top and bottom five for results that feel wrong.
    • Investigate surprises by checking assumptions rather than adjusting scores to match intuition.
    • Lower confidence where estimates lack evidence instead of debating impact endlessly.
    • Record any deliberate overrides with a written reason.

    Milestone: A calibrated ranked list with documented overrides agreed by product, design, and engineering.

  5. Build and Revisit Roadmap (Weeks 1-13 of the quarter)

    Turn the ranking into a roadmap and rescore as new evidence arrives.

    • Fill the Now column from the top of the ranking until capacity is used.
    • Share scores and assumptions alongside the roadmap with stakeholders.
    • Rescore initiatives monthly when analytics or discovery change an estimate.
    • Compare actual reach and effort against estimates after each initiative ships.

    Milestone: A roadmap built from RICE scores plus a post-launch comparison of estimates against actuals.

The Four Factors in Detail

Reach counts how many people or accounts the initiative affects in a defined time period, such as per quarter. Use real numbers from analytics wherever possible: if a feature touches the checkout flow and a certain number of customers check out each quarter, that is your reach. Keep the period consistent across all items.

Impact estimates how much the initiative moves the goal for each person reached. Because this is hard to measure precisely, RICE uses a fixed scale: 3 for massive, 2 for high, 1 for medium, 0.5 for low, and 0.25 for minimal. Confidence discounts estimates you are unsure about: 100 percent with strong data, 80 percent with some evidence, 50 percent for a hunch. Effort is the total team time, usually in person-months, across all disciplines.

The formula rewards broad, high-impact, well-evidenced, cheap work, and penalizes speculative, narrow, or expensive work. It does not tell you what to build, but it forces every assumption into the open.

  • Reach: people or accounts per period, from real data.
  • Impact: 3, 2, 1, 0.5, or 0.25 per person reached.
  • Confidence: 100, 80, or 50 percent.
  • Effort: person-months across product, design, and engineering.

A Worked Scoring Example

Imagine a team comparing three ideas, using illustrative inputs. Idea A, a smarter search, reaches 4,000 users per quarter, has medium impact of 1, confidence of 80 percent, and takes 2 person-months: 4,000 × 1 × 0.8 ÷ 2 gives 1,600. Idea B, a bulk edit tool, reaches 800 users, has high impact of 2, confidence of 100 percent, and takes 1 person-month: 800 × 2 × 1 ÷ 1 gives 1,600.

Idea C, an AI assistant, reaches 5,000 users, has massive impact of 3, but confidence of only 50 percent and takes 6 person-months: 5,000 × 3 × 0.5 ÷ 6 gives 1,250. Despite the most exciting pitch, C ranks last. A and B tie, which is a useful outcome: it triggers a conversation about strategic fit, and the cheaper, more certain B might go first. A sensible next step for C is a small discovery spike to raise confidence before rescoring.

Running a Good Scoring Session

Score in a small group with product, design, and engineering represented. Have the product manager pre-fill reach from analytics and engineering pre-fill effort, then use the session to debate impact and confidence, which are the most subjective factors. Keep the session focused on assumptions, not on whose idea it was.

Score each factor across all initiatives before moving to the next factor. Comparing reach for every item side by side produces more consistent estimates than scoring each initiative fully in isolation. When the group disagrees sharply on impact, that disagreement is itself a reason to lower confidence.

  • Pre-fill reach and effort before the meeting.
  • Score one factor at a time across all items.
  • Treat strong disagreement as low confidence.
  • Write the evidence source next to every estimate.

Where RICE Falls Short

RICE favors initiatives with measurable reach, which can undervalue foundational work like platform upgrades, accessibility, or security hardening. It also struggles with strategic bets that open new markets, where reach is near zero today by definition. Handle these outside the formula with explicit capacity reserved for platform and strategic work.

The scores are also easy to game. Someone attached to an idea can nudge impact up a notch and change the ranking. Counter this by requiring evidence for every estimate, keeping scales fixed, and reviewing actual outcomes against estimates after launch. Teams that check their past estimates get noticeably better calibrated over time.

RICE Compared With Other Frameworks

ICE drops reach and scores Impact, Confidence, and Ease, which is faster but less rigorous; it suits growth experiments where speed matters more than precision. MoSCoW sorts items into Must, Should, Could, and Won't, which is better for fixed-scope releases than for ranking a long backlog. Weighted scoring lets you define custom criteria like strategic fit, useful when RICE's factors do not capture what your business values.

Many teams combine approaches: RICE to rank a large backlog, then a judgment pass for strategy and dependencies, then MoSCoW to define the scope of a specific release. The framework is a thinking aid, not a decision machine.

Common mistakes to avoid

  • Using different reach periods for different items makes scores incomparable; fix one period such as per quarter for everything.
  • Inventing impact numbers outside the fixed scale inflates favorites; stick to 3, 2, 1, 0.5, and 0.25.
  • Leaving confidence at 100 percent by default hides risk; require evidence before awarding high confidence.
  • Counting only engineering time understates effort; include product, design, and QA time in person-months.
  • Treating the sorted list as the final roadmap ignores dependencies and strategy; apply a documented judgment pass afterward.
  • Never comparing estimates with actual results keeps scoring uncalibrated; review reach and effort after each launch.

Frequently asked questions

What is the RICE formula?

The RICE score equals Reach times Impact times Confidence, divided by Effort. Reach is people affected per period, Impact uses a fixed scale from 0.25 to 3, Confidence is a percentage like 50, 80, or 100, and Effort is measured in person-months. The result estimates value delivered per unit of team time, so higher scores rank higher.

Who created the RICE prioritization framework?

RICE was developed and popularized by the product team at Intercom, which published it as a way to compare very different product ideas on a consistent scale. It has since become one of the most widely used prioritization methods among product managers, alongside ICE, MoSCoW, and the Kano model.

What is a good RICE score?

There is no universal good score, because the numbers depend on your user base, reach period, and effort units. RICE scores are only meaningful relative to other items scored with the same scales by the same team. Focus on the ranking and on the assumptions behind the top items rather than on absolute values.

How do I estimate impact in RICE?

Use the fixed scale: 3 for massive, 2 for high, 1 for medium, 0.5 for low, and 0.25 for minimal impact on each person reached. Tie the rating to your current goal, such as activation or retention, and base it on evidence from interviews, usage data, or past experiments. When evidence is thin, lower confidence instead of guessing a higher impact.

Should bugs and technical debt be scored with RICE?

Small bugs usually should not; triage them separately. Larger technical debt or platform work can be scored, but RICE tends to undervalue it because reach and impact are indirect. Many teams reserve a fixed share of capacity for platform and maintenance work and use RICE only to rank customer-facing initiatives within the remaining capacity.

Generate this roadmap with AI