What are some real RICE scoring model examples for prioritizing product features?

The RICE scoring model is a prioritization framework that turns feature debates into arithmetic. Developed at Intercom around 2014 by product manager Sean McBride, it assigns each initiative a score of (Reach × Impact × Confidence) ÷ Effort, producing a single number you can rank against every other item in your backlog. Because the formula forces teams to state their assumptions in numbers, it exposes wishful thinking quickly: a pet project with 20% confidence and three months of engineering effort cannot hide behind enthusiasm once the math is on the whiteboard.

The Formula, Defined Precisely

Also worth reading: What are churn prediction workflow examples for B2B SaaS product and support teams? · How to prioritize product features for a B2B SaaS product backlog? · What is the most effective feedback prioritization scoring framework for B2B product teams?

Each letter in RICE maps to one input. Reach is the number of people or events affected per time period — typically users touched per quarter. If 8,000 of your 40,000 monthly active users will encounter a new onboarding checklist each quarter, your Reach is 24,000 (8,000 × 3 months). Impact measures how strongly each reached person is affected, usually on a five-point scale: 3 for massive, 2 for high, 1 for medium, 0.5 for low, and 0.25 for minimal. Confidence is expressed as a percentage — 100% means you have hard data or a shipped experiment behind the estimate, 80% reflects solid but incomplete evidence, and 50% signals an educated guess. Anything below 50% confidence generally should not be scored; it should be researched first. Effort is measured in person-months, where one person-month equals the work one team member completes in four weeks or roughly 160 hours.

A worked example makes this concrete. Suppose you are evaluating a new notification digest email. You estimate 30,000 customers per quarter will receive it (Reach = 30,000), it will have a medium effect on retention (Impact = 1), you have A/B test data from a similar send so Confidence is 100%, and it takes two engineers six weeks, or about 0.75 person-months (Effort = 0.75). The score is (30,000 × 1 × 1) ÷ 0.75 = 40,000. Compare that against a dashboard redesign scoring (10,000 × 2 × 0.8) ÷ 6 = 2,667 and the ranking decision becomes obvious rather than political.

Example 1: SaaS Onboarding Improvements

Consider a B2B customer-signal inbox used by product and support teams, where the backlog contains three competing items: an in-app guided tour, a Slack integration, and a dark mode toggle. For the guided tour, suppose 12,000 new accounts per quarter hit the empty inbox screen (Reach = 12,000), activation data suggests the tour would move them from low to high impact (Impact = 2), leadership has only anecdotal evidence so Confidence sits at 80%, and two engineers need eight weeks (Effort = 1). Score: (12,000 × 2 × 0.8) ÷ 1 = 19,200.

The Slack integration reaches fewer people — say 5,000 accounts per quarter — because only a subset use Slack, but those who do would adopt heavily (Impact = 2). Confidence is 50% since no comparable integration exists yet, and Effort is 2 person-months. Score: (5,000 × 2 × 0.5) ÷ 2 = 2,500. Dark mode scores lowest despite loud user requests: Reach might be 9,000, Impact 0.25 (it delights but changes nothing measurable), Confidence 100%, Effort 0.5, yielding (9,000 × 0.25) ÷ 0.5 = 4,500. Notice what happened: the loudest request ranked below the quietest strategic bet's cousin, and the framework made that trade-off explicit instead of letting vocal customers dictate the roadmap.

Example 2: Support Team Workflow Changes

RICE works beyond engineering backlogs. A support organization evaluating process changes can apply the same math. Reducing first-response time from 8 hours to 2 hours might reach all 15,000 quarterly tickets (Reach = 15,000), carry high impact on CSAT (Impact = 2), rest on industry benchmark data (Confidence = 80%), and require hiring plus training worth 3 person-months (Effort = 3). Score: (15,000 × 2 × 0.8) ÷ 3 = 8,000.

A macro-based reply system reaching 60% of tickets (Reach = 9,000) with medium impact (Impact = 1), strong internal pilot data (Confidence = 100%), and modest effort of 0.5 person-months scores (9,000 × 1 × 1) ÷ 0.5 = 18,000 — beating the staffing change despite being less glamorous. This is the model's real value: it routinely surfaces cheap, unsexy wins that outrank expensive strategic bets, which is exactly why some leaders distrust it and why it should never be the sole decision criterion.

Comparison Table: Worked Examples Side by Side

Reading the table, the digest email dominates on raw score because its Reach is enormous relative to its Effort. But a raw ranking would be misleading if the email depends on infrastructure the dashboard redesign also needs, or if the Slack integration unlocks a market segment worth more than its score implies. Scores are inputs to judgment, not replacements for it.

How to Run a Scoring Session in Practice

A workable process takes one to two weeks end to end. Day one, inventory the backlog and cap it at roughly 20–30 candidates; scoring 200 items produces analysis paralysis and stale numbers. Days two through five, assign each item a single owner who drafts Reach, Impact, Confidence, and Effort estimates using analytics data, support ticket counts, sales feedback, and engineering sizing sessions. Week two, hold a 90-minute calibration meeting where the team reviews outliers — any score more than 3× above or below the median deserves scrutiny, because outliers usually reflect estimation errors rather than genuine opportunity. Finally, sort descending, draw a cutoff line based on team capacity for the next quarter, and document every assumption in the row itself so future-you can audit why the number was what it was.

Two operational rules keep the exercise honest. First, re-score every quarter: Reach estimates decay as markets shift, and a score computed in January is fiction by July. Second, track prediction accuracy — after shipping, compare projected impact against actuals. Teams that do this typically find their Confidence scores were inflated by 20–30 percentage points, and correcting that bias is worth more than the framework itself.

RICE Versus ICE, WSJF, and Kano

RICE has siblings, and choosing among them matters more than most articles admit. ICE (Impact × Confidence × Ease), popularized by former Google growth lead Sean Ellis, drops Reach entirely, making it faster but blind to audience size — a niche feature affecting ten power users can tie a platform-wide improvement. Weighted Shortest Job First (WSJF), from SAFe, divides cost of delay by job size and suits enterprises already running scaled agile. Kano modeling classifies features into basic, performance, and delight categories through customer surveys, capturing emotional value that RICE's linear Impact scale flattens.

A pragmatic hybrid many product organizations land on: use ICE for weekly triage of small items, RICE for quarterly roadmap planning, and Kano surveys once or twice a year to check whether your Impact scale matches what customers actually value.

Common Mistakes That Corrupt the Math

The most frequent error is inflating Reach by counting everyone who could theoretically touch a feature rather than those who plausibly will. If only 15% of users open settings, a settings redesign's Reach is 15% of your base, not 100%. The second error is treating Confidence as a gut feeling rather than an evidence grade: 100% should mean shipped experiments or production data exist, 80% means triangulated research, and 50% means hypothesis. Teams that award 90% confidence to unvalidated ideas convert RICE into a random number generator with extra steps.

Effort underestimation is nearly universal — software projects historically run 30–50% over initial estimates, so multiplying engineering's raw figure by 1.25 as a buffer is defensible. A subtler mistake is ignoring dependencies and strategic weight: RICE cannot see that two mid-scored items share infrastructure, or that a low-scored compliance feature is legally mandatory. Compliance, security, and technical debt items often need a separate mandatory lane exempted from scoring entirely, otherwise they lose every cycle to flashier bets and eventually cause outages or fines. Finally, avoid averaging scores across stakeholders to manufacture consensus; disagreement about inputs usually signals genuine uncertainty that deserves a spike or experiment, not a compromise number.

When to Use RICE and When Not To

RICE earns its keep when you face more candidate work than capacity — the normal condition for any growing product or support organization — and when stakeholders demand justification beyond seniority. It performs best on incremental improvements to existing products where Reach and Impact are estimable from usage data. It performs poorly on genuinely novel bets: estimating Reach for a brand-new product line is speculation dressed as arithmetic, and forcing such bets through RICE systematically starves innovation. Many successful companies therefore reserve 10–20% of capacity for unscored exploratory work.

Timing matters too. Score at quarterly planning cadence, not continuously — rescoring after every new idea creates churn without information. And act on the output within the same quarter; a ranked list older than 90 days is a historical document. If your team ships faster than it re-scores, switch to lighter-weight ICE triage between formal cycles.

Costs, Tooling, and Realistic Expectations

The framework itself costs nothing but time: expect 10–20 person-hours per quarter across the whole team for a 25-item backlog, which at typical loaded rates runs a few hundred dollars per cycle — trivial against the misallocated sprints it prevents. Tooling ranges from free spreadsheets with the formula pre-built, to product platforms like Productboard, Airfocus, or Jira Product Discovery ($10–$59 per editor per month depending on tier) that embed weighted scoring natively. Support-adjacent teams using signal-inbox tools can pipe real ticket volumes directly into Reach estimates, replacing guesswork with live counts — arguably the highest-leverage upgrade available, since Reach accuracy drives everything downstream.

Set expectations honestly: RICE improves decision quality at the margin. It will not rescue a strategy problem, and it will occasionally rank a transformative idea below a safe incremental one. Treat it as a structured conversation starter whose greatest benefit is forcing written, auditable assumptions — the score is almost secondary to the discipline of writing down why you believe what you believe.