How to Use the RICE Scoring Model for Prioritization

Every product manager has been in that meeting. Ten features on the table. Everyone’s got an opinion. The engineering lead wants to pay down tech debt. Sales wants the enterprise dashboard. The CEO just came back from a conference and wants to build an AI feature. And you’re sitting there trying to figure out which one actually matters most.

The RICE scoring model exists precisely for this moment. It gives you a structured, repeatable way to evaluate competing priorities based on data — not politics, gut feeling, or whoever speaks loudest in the room. Teams that are skeptical going in tend to find that the value isn’t really the final number — it’s that nobody can argue with a score without first arguing with the assumption behind it, which is a much more useful fight to have. That shift alone — from arguing about opinions to arguing about a specific number in a specific cell — changes the tone of planning meetings more than most facilitation techniques manage.

What Is the RICE Scoring Model?

The RICE scoring model is a prioritization framework built by Sean McBride on Intercom’s growth team, who published the original methodology after struggling to find a scoring system that let the team compare wildly different feature ideas in a consistent way. It scores each feature or initiative across four dimensions: Reach, Impact, Confidence, and Effort. The resulting score ranks your backlog objectively so you can focus on what delivers the most value per unit of effort.

RICE stands for:

• Reach — How many users will this affect within a given time period?
• Impact — How much will this move the needle for each user?
• Confidence — How certain are you about your estimates?
• Effort — How much work will this take from your team?

What makes it powerful isn’t the number itself. It’s that scoring forces you to think explicitly about each dimension before you commit to a decision, and that process alone surfaces assumptions you didn’t know you were making. The most useful RICE conversations tend to happen when two people score the same feature very differently — that gap is where the real disagreement was hiding the whole time, dressed up as a debate about the feature itself.

The RICE Formula Explained

The RICE scoring model uses this formula:

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

Reach

Measured as the number of users (or transactions, accounts, etc.) affected per time period — typically per quarter. Use real data where possible. If you’re estimating, be conservative. If your feature will touch 2,000 users per quarter, Reach = 2,000.

Impact

Scored on a multiple-choice scale rather than a raw number, which keeps teams honest about what they actually know. Intercom’s original scale uses:

• 3 = Massive impact
• 2 = High impact
• 1 = Medium impact
• 0.5 = Low impact
• 0.25 = Minimal impact

Confidence

Expressed as a percentage. If you have solid user research, data from similar features, or strong market evidence, you might rate confidence at 100%. If it’s mostly a hunch, be honest — 50% or even 30% is appropriate. Low confidence doesn’t disqualify a feature. It just adjusts its score appropriately.

Effort

Measured in person-months. One engineer working for one month = 1. A feature requiring two engineers for three months = 6. Include design, engineering, QA, and PM time. Effort is in the denominator, so higher effort means a lower RICE score, which reflects the real cost of building something.

How to Calculate Your RICE Score, Step by Step

1. Define your time period. Pick a consistent window — quarterly is standard. All Reach estimates should use the same time horizon so your scores are comparable.
2. Estimate Reach. Pull data from your analytics, support tickets, or user research. How many users will interact with this feature in the next quarter? Use numbers from existing data rather than aspirational projections.
3. Score Impact. Look at your north star metric and product goals. If this feature ships and works as intended, what happens to engagement, conversion, retention, or revenue? Be honest about the magnitude — it’s tempting to call everything “massive.” Resist that.
4. Assign Confidence. What evidence do you have? If you’ve tested a prototype and seen positive signals, confidence is high. If this is based on a stakeholder assumption, confidence is low. Calibrate accordingly.
5. Estimate Effort. Work with your engineering and design leads. Get a rough estimate in person-months. You don’t need sprint-level precision — just a realistic sense of scale.
6. Calculate the score. Plug the numbers into the formula: (Reach × Impact × Confidence) ÷ Effort.
7. Rank and compare. Run every item in your backlog through this process and sort by RICE score descending. The items at the top are your highest-value, lowest-cost priorities.

RICE Scoring Model: A Real-World Example

Here’s how this plays out for a 25-person B2B SaaS company at Series A, evaluating three features for next quarter with a two-person engineering team stretched thin.

Feature A: Bulk CSV Export

• Reach: 800 users/quarter (power users who manage large datasets)
• Impact: 2 (high — this is a frequent pain point)
• Confidence: 90% (based on support ticket volume and user interviews)
• Effort: 1 person-month
• RICE Score = (800 × 2 × 0.9) ÷ 1 = 1,440

Feature B: AI-Powered Onboarding Flow

• Reach: 3,000 users/quarter (all new signups)
• Impact: 1 (medium — might improve activation but uncertain)
• Confidence: 50% (no prototype tested yet)
• Effort: 6 person-months
• RICE Score = (3,000 × 1 × 0.5) ÷ 6 = 250

Feature C: Custom Dashboard Widgets

• Reach: 1,200 users/quarter
• Impact: 1 (medium)
• Confidence: 80%
• Effort: 2 person-months
• RICE Score = (1,200 × 1 × 0.8) ÷ 2 = 480

The ranking: Feature A (1,440) → Feature C (480) → Feature B (250). The CEO had been pushing hardest for the AI onboarding flow, and the numbers putting it last tends to draw less pushback than expected — once the six-person-month cost sits next to a 50% confidence score in black and white, the argument mostly makes itself. Even though Feature B touches the most users, its low confidence and high effort drag its score down significantly. The CSV export, which looked like a “small” feature going in, turned out to be the highest-priority item by a wide margin.

When to Use the RICE Scoring Model

RICE is most useful when you’re comparing multiple unrelated features that are hard to evaluate on a single dimension. It works especially well for:

• Quarterly planning cycles — When you’re deciding what makes it into the next sprint or quarter
• Backlog grooming sessions — To trim and rank a backlog that’s grown out of control
• Cross-functional alignment — When multiple stakeholders are advocating for competing priorities
• Resource-constrained environments — When you have a small team and every person-month counts

It’s less useful for incremental improvements within a single feature area, or for decisions primarily driven by strategic direction from leadership. If you’re running a broader session with several stakeholders in the room rather than scoring solo, RICE works well as the scoring method inside a structured prioritization workshop — the workshop format handles the alignment problem; RICE handles the math.

RICE vs Other Prioritization Frameworks

RICE isn’t the only option, and it shouldn’t be treated as the default for every team the way it’s sometimes presented. Here’s how it actually stacks up.

RICE vs MoSCoW

MoSCoW (Must Have, Should Have, Could Have, Won’t Have) is faster and easier to run, but more subjective. It lacks the quantified output that makes RICE useful for cross-functional alignment.

RICE vs ICE

ICE is a simplified version of RICE that drops the Reach variable. It’s faster to run, but misses an important dimension — a high-impact feature that only touches 10 users is very different from one that touches 10,000. ICE tends to make more sense when scoring ideas that already share roughly the same audience size, which is more often than people assume for early-stage teams working one product surface at a time.

RICE vs Kano Model

Kano classifies features by how they affect customer satisfaction (basic, performance, delighters). It’s excellent for understanding user psychology, but doesn’t produce a ranked priority list the way RICE does.

RICE vs Weighted Scoring

Custom weighted scoring lets you define your own criteria and weights. It’s more flexible but requires more setup. RICE works well as a default framework because it covers the most important variables out of the box, as ProductPlan’s breakdown of the model notes in comparing it against other roadmap prioritization approaches.

When aligning features with OKRs, combining RICE with your OKR framework is a natural fit — RICE tells you what to prioritize, OKRs tell you why. You can also layer in the jobs-to-be-done framework to make sure your Reach and Impact estimates are grounded in real user needs rather than assumptions.

RICE Scoring Template

Use this template to score your backlog items. Copy it into a spreadsheet, Notion, or Linear.

Feature	Reach (users/qtr)	Impact (0.25–3)	Confidence (%)	Effort (person-months)	RICE Score
Feature 1					=R×I×C÷E
Feature 2
Feature 3

Scoring guide:

• Impact: 3 = Massive, 2 = High, 1 = Medium, 0.5 = Low, 0.25 = Minimal
• Confidence: 100% = High certainty, 80% = Mostly confident, 50% = Mixed signals, 20–30% = Mostly a guess
• Effort: Count in person-months across all functions (design + eng + QA + PM)

Sort the completed table by RICE Score descending. Your top items are your priorities.

Where RICE Scoring Breaks Down

Inflating Impact scores. This is the most common error. Every PM thinks their features are high-impact. If everything is a 3, nothing is. Treating the Impact scale like a budget — only one or two 3s allowed per planning cycle, stated upfront before scoring starts — cuts the inflation almost immediately.

Ignoring Confidence. It’s tempting to skip this step or default to 100% for everything. Don’t. Confidence is what separates honest prioritization from wishful thinking. If you haven’t validated something, your confidence should reflect that.

Inconsistent time horizons. If one feature’s Reach is measured per week and another’s is per year, your scores are meaningless. Always use the same time period across the board.

Treating the score as final. The RICE score is a starting point, not a verdict. A feature that scores lower might still be strategically important for reasons the model doesn’t capture — competitive pressure, regulatory requirements, or a major customer commitment. A RICE ranking is sometimes worth overriding — a compliance requirement with a hard external deadline is a common example — and documenting why in the same doc as the scores keeps anyone from mistaking the override for the model failing.

Running it alone. RICE works best as a team exercise. When you score features collaboratively with engineering, design, and data, you surface disagreements about estimates early — before they become problems during execution. When you’re building your product roadmap, running RICE with your team creates shared ownership of the priorities, not just the plan.

Using RICE for decisions it wasn’t built for. RICE compares independent initiatives competing for the same resources. It doesn’t handle sequencing well — if Feature B is a hard technical prerequisite for the higher-scoring Feature A, RICE won’t tell you that on its own, and teams that skip a dependency check before sorting by score end up building the wrong thing first often enough that it’s worth the extra pass. Fix: run a quick dependency pass across your top five to ten items before you commit to the ranked order, not after.

Run It Before Your Next Planning Cycle

The RICE scoring model isn’t magic. But it’s one of the most practical tools in a PM’s toolkit — especially when you need to make a defensible case for why you’re building what you’re building. Pull your current backlog into the template above before your next planning meeting, score the top ten items with your team instead of alone, and see which of your assumptions survive contact with someone else’s honest Confidence score.

References

1. McBride, S. — “RICE: Simple prioritization for product managers” — intercom.com/blog/rice-simple-prioritization-for-product-managers
2. ProductPlan — “RICE Scoring Model” — productplan.com/glossary/rice-scoring-model
3. Mind the Product — “Prioritization frameworks for product managers” — mindtheproduct.com