RICE Scoring Framework: The Exact Formula Product Teams Use in 2026

The RICE framework is a prioritization model that ranks product ideas by a single score: (Reach x Impact x Confidence) divided by Effort. Product teams use RICE scoring to compare features on the same scale when gut-feel ranking breaks down.

Intercom introduced RICE in 2017. Sean McBride published the internal method the team used to sort roadmap candidates. The idea spread fast because it fixed a specific problem. Most scoring systems either required too much data or gave you four axes to argue about. RICE gives you one number per idea.

That number is imperfect. But it forces the conversation onto the same terms. Two engineers can disagree about a feature, agree the Impact rating is 2, and move on. That is the point.

The RICE Formula

The formula is:

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

Each component has a defined scale. You pick values, multiply and divide, and rank the results. Higher is better.

Here is what each variable means.

Reach

Reach is the number of people affected by the feature in a fixed time window. Most teams use one quarter or one month. Pick one and stick to it across the whole prioritization session.

Examples for a monthly window:

• New onboarding flow: 4,000 signups per month = Reach of 4,000
• Advanced filter on a settings page: 200 users touch that page per month = Reach of 200
• Bug fix on a critical checkout step: 50,000 checkout attempts per month = Reach of 50,000

Use real numbers from your product analytics. If you have no data, estimate, but flag the estimate in Confidence.

Impact

Impact measures how much the feature moves the outcome you care about per user. It uses a fixed five-point scale:

• 3 = massive impact
• 2 = high impact
• 1 = medium impact
• 0.5 = low impact
• 0.25 = minimal impact

The outcome can be retention, conversion, revenue, or anything else. What matters is that you apply the same outcome across every score. Mixing outcomes breaks the math.

Impact is the component people dispute the most. The trick is to anchor to past features. If the last feature you shipped moved conversion by 3%, that is your 2. Work outward from there.

Confidence

Confidence is how certain you are about your Reach and Impact estimates. It is expressed as a percentage.

• 100% = solid data, tested, experiment run
• 80% = strong evidence, some data, previous experiments support it
• 50% = moderate evidence, logical argument, one data point
• Below 50% = do not score this, do more research first

Confidence is the framework's honesty test. If you are inventing a Reach number and guessing at Impact, your Confidence should be 50% and your final score should reflect that.

Effort

Effort is the total person-months to build and ship the feature. Include design, engineering, testing, and rollout. Be pessimistic. Most teams underestimate by 30 to 50%.

A feature that takes one designer two weeks, two engineers four weeks, and one QA one week is roughly 2 person-months of effort, not 1.

A Worked Example

Consider a real scoring question: should we build a notifications preferences page?

• Reach: 6,000 active users touch notifications per month. Reach = 6,000.
• Impact: Reduces notification opt-outs by an estimated 10%. Medium impact per user. Impact = 1.
• Confidence: We have support tickets and two user interviews pointing to this. No experiment. Confidence = 80%.
• Effort: Frontend work, backend flags, settings API. 3 person-months. Effort = 3.

RICE score = (6,000 x 1 x 0.8) / 3 = 1,600

Compare that to a request to add Slack notifications for billing events:

• Reach: 400 users on paid plans. Reach = 400.
• Impact: Prevents churn on a small group. Medium impact. Impact = 1.
• Confidence: One customer complained loudly. Confidence = 50%.
• Effort: Slack webhook integration is 1 person-month. Effort = 1.

RICE score = (400 x 1 x 0.5) / 1 = 200

The preferences page wins by 8x. The math matches intuition here, but that is not always the case. The value of RICE is when the math contradicts the loudest voice in the room.

What the Numbers Mean: Score Interpretation

RICE scores do not have absolute meaning. A 200 is good or bad relative to your other candidates. That said, here is a rough calibration most teams converge on.

• Under 50: Low priority. Small reach, low impact, or too much effort. Park unless something changes.
• 50 to 200: Backlog candidate. Worth doing eventually. Not urgent.
• 200 to 1,000: Strong candidate. These are the features that make quarterly roadmaps.
• 1,000+: Clear priority. These are the bets that move the outcome significantly.
• 5,000+: Something may be off. Recheck Reach and Confidence. A score this high is often driven by an inflated Reach estimate.

Rank your candidates. Draw a line at the capacity you can actually deliver. Ship above the line.

RICE vs MoSCoW: When Each Wins

MoSCoW and RICE answer different questions.

MoSCoW asks: what absolutely has to ship this cycle, and what can wait? It is fast, qualitative, and works with mixed stakeholder groups. You can run a MoSCoW session in an hour with no analytics data.

RICE asks: if I had to rank fifty features by expected return, what is the order? It is slower, quantitative, and requires real numbers for Reach and Effort.

MoSCoW tells you what feels critical. RICE tells you whether the math agrees. Run MoSCoW first to filter the universe down to twenty candidates. Run RICE on those twenty to pick the top five. The combination is stronger than either framework alone.

Use MoSCoW when:

• You are planning a sprint or release with a fixed scope
• Stakeholders from multiple functions need to agree
• You have little data and need alignment fast
• The question is "what ships this cycle"

Use RICE when:

• You are building a roadmap from a large backlog
• You need to justify prioritization decisions with numbers
• You have analytics data to support Reach and Impact
• The question is "which feature has the highest expected return"

Teams that try to use one framework for both jobs end up frustrated. MoSCoW cannot rank fifty features. RICE cannot facilitate a cross-functional planning session in under an hour.

When RICE Fails

RICE looks objective. It is not. The math is clean, but the inputs are judgment calls. Here are the failure modes.

Confidence Inflation

The most common problem. Everyone rates their feature at 90% Confidence because they believe in it. When Confidence is uniformly high, it stops being a useful variable. The formula collapses into (Reach x Impact) / Effort.

Fix: enforce a rule that Confidence above 80% requires an experiment, A/B test, or strong quantitative data. Anything else caps at 50%.

Reach Guesswork

Teams often guess Reach when the data is inconvenient to pull. A feature gets a Reach of "10,000 users" because it feels like a big feature. The actual number of affected users might be 500.

Fix: require a specific source for every Reach number. "Mixpanel event X in the last 30 days" is acceptable. "Feels big" is not.

Effort Collapse

Engineering estimates compress under pressure. A 4 person-month feature becomes 1 person-month in the RICE sheet because someone wanted it to score higher. This corrupts the entire ranking.

Fix: engineering writes Effort, not product. Product can negotiate, but the number that goes in the sheet comes from the team that will build it.

Wrong Outcome Mix

If one feature's Impact is scored on conversion and another's on retention, the scores are not comparable. You cannot divide apples by oranges and expect a clean ranking.

Fix: pick one primary outcome per scoring session. If you need to weigh different outcomes, run separate RICE passes and combine qualitatively.

Small-Reach Trap

RICE rewards high-Reach features. This can starve small but important work: a compliance feature for a key customer, a bug that only affects power users. Fix: run RICE on scoped groups, not the whole backlog.

How to Run a RICE Session

Here is the format that works.

Step 1: Agree on the Outcome

Before anyone scores anything, decide what Impact measures. Retention? Conversion? Revenue? Write it at the top of the sheet. Everyone scores against this one outcome.

Step 2: Gather the Candidates

Pull the features you want to compare. Aim for 15 to 30. More than 30 and the session drags. Fewer than 10 and RICE is overkill.

Do not use the full backlog. Pre-filter with MoSCoW or a rough value-versus-effort pass first.

Step 3: Score Reach First

Reach uses data. Pull the numbers together. One person drives the spreadsheet. Anyone can challenge a number by naming the source they would use instead.

This step is the longest. Rush the other steps, not this one.

Step 4: Score Impact, Then Confidence

Do Impact and Confidence in the same pass. Ask "what impact per user" and immediately "how confident are we in that."

If Confidence is below 50%, flag the row. Low-confidence rows do not belong in a final ranking. They belong in a research backlog.

Step 5: Engineering Writes Effort

Product steps back. Engineering fills in Effort in person-months. If a row is ambiguous, split it into smaller rows.

Step 6: Calculate and Sort

Formula goes in the sheet. Sort descending. Read the top of the list aloud.

Step 7: Sanity Check and Draw the Capacity Line

For every row in the top five, ask: does this ranking match your instinct? If not, which input is wrong? Usually it is Reach or Confidence. Adjust inputs if the data supports it. Do not adjust the score directly.

Mark the point where team capacity runs out. Everything above the line is in. Everything below is parked. Share the sheet with stakeholders. The below-the-line list matters as much as the above-the-line list.

Common RICE Mistakes

Using it for everything. RICE is for roadmap ranking. Not sprint planning, not bug triage, not research work. Teams that RICE-score every decision end up with a bloated spreadsheet and no prioritization.

Scoring alone. A RICE score from one person is just that person's opinion dressed in math. The value is in the disagreements. Score as a team.

Freezing the scores. RICE is a snapshot. Reach changes when user counts change. Confidence changes when you run experiments. Rescore at least every quarter.

Ignoring strategy. RICE is agnostic to strategic bets. A high-RICE feature in an area you are deprioritizing is still deprioritized. Overlay strategy on the ranking.

Treating 3 vs 2 as precise. The Impact scale is coarse. A 3 is not 50% more impact than a 2. They are rough buckets. Do not manipulate the scale to make a preferred feature score higher.

When RICE Works Best

RICE works best when you have a backlog of 20 to 100 candidates, real analytics data for Reach, a single outcome to score against, and a team comfortable admitting low confidence.

It works less well for fast alignment in a mixed-stakeholder room (use MoSCoW instead), discovery work where you do not yet know what you are building, candidates that vary wildly in effort, or qualitative outcomes that cannot be estimated per user.

RICE and the Signal Problem

The hardest part of RICE is not the math. It is the Reach number. Teams that cannot pull clean Reach data cannot run RICE honestly.

A RICE score is only as good as the signal behind it. If your Reach is a guess and your Impact is a hope, you are not scoring. You are guessing with a calculator.

This is where most teams get stuck. Support tickets live in Zendesk. Feature requests live in Slack and email. NPS comments live in a survey tool. No one has a clean count of how many users asked for what.

Continuous signal capture fixes this. When every request, every complaint, and every feature idea flows into one place, you know how many users asked for a thing in the last 30 days. That is your Reach. The argument is over before it starts.

Tools that capture product feedback automatically, like IdeaLift, turn raw signal into the exact numbers RICE needs. Reach stops being a guess. Confidence goes up. Scores become defensible.

Summary

The RICE framework scores product ideas on a single number: (Reach x Impact x Confidence) divided by Effort. It is best used for ranking a medium-sized backlog against one outcome.

The formula is simple. The inputs are not. Confidence inflation, Reach guesswork, and Effort collapse are the three most common failure modes.

RICE pairs well with MoSCoW. Use MoSCoW first to cut the backlog to a shortlist. Use RICE to rank the shortlist. The combination catches expensive mistakes that either framework alone would miss.

The quality of a RICE score depends entirely on the quality of your inputs. Teams that capture product signals continuously score RICE honestly. Teams that do not end up with a spreadsheet full of guesses dressed as math.

FAQ

What is the RICE framework?

The RICE framework is a product prioritization method that scores ideas on four dimensions: Reach, Impact, Confidence, and Effort. The score is calculated as (Reach x Impact x Confidence) divided by Effort. Higher scores indicate higher priority. Intercom published the method in 2017.

What is a good RICE score?

RICE scores are relative, not absolute. A good score is one that ranks above the cut-off line for your team's capacity. As rough calibration: scores under 50 are low priority, 200 to 1,000 are strong candidates, and above 1,000 are clear priorities. Anything above 5,000 usually indicates an inflated Reach estimate.

When is MoSCoW better than RICE?

MoSCoW is better when you need fast alignment across a mixed group of stakeholders, when you have little quantitative data, or when the question is "what ships this cycle" rather than "what is the expected return." RICE is better when you are ranking a larger backlog by expected return and you have analytics data. Most teams use both: MoSCoW to filter, RICE to rank. See the MoSCoW prioritization guide for the full comparison.

How do I calculate Reach in RICE?

Reach is the number of users affected by the feature in a fixed time window, usually one month or one quarter. Pull the number from your analytics tool. For a checkout improvement, Reach is the number of checkout attempts per period. For a settings page change, Reach is the number of users who touch that page per period. If you cannot find real data, lower the Confidence score to reflect the uncertainty.

What is the difference between RICE and ICE?

ICE drops the Reach component and scores only Impact, Confidence, and Ease (the inverse of Effort). It is faster but less precise. ICE works for growth experiments and smaller decisions where reach is roughly uniform. RICE works for roadmap ranking where reach varies significantly between features.

How often should I update RICE scores?

Rescore every quarter at a minimum. Reach changes as user counts grow. Confidence changes as you run experiments. Strategy shifts can move outcomes. A RICE sheet that is six months old is almost always wrong. Treat the scores as a living artifact, not a one-time exercise.

---

Ready to ground your RICE scores in real product signals instead of guesswork? Start with IdeaLift free or see how it works. If you want to pair RICE with a qualitative first pass, read the MoSCoW prioritization guide next.