RICE Prioritization: The Framework, Formula, and Examples Every PM Needs
RICE is a scoring model that helps product teams prioritize features objectively. Here's the formula, real examples, and how to stop doing the math manually.
Every product team has more ideas than capacity. The backlog is long. Stakeholders are loud. Engineering time is limited. RICE is a framework that helps you decide what to build next - without letting the loudest voice in the room win.
RICE stands for Reach, Impact, Confidence, and Effort. It assigns a numerical score to each feature or project so teams can compare them objectively and prioritize the highest-value work first.
The RICE Formula
The RICE score is calculated with one formula:
RICE Score = (Reach × Impact × Confidence) / Effort
Each factor is defined as:
- Reach - How many users will this affect per time period (usually per quarter)? Use a real number, not a percentage. “500 users per quarter” is Reach = 500.
- Impact - How much will this affect each user who reaches it? Use a 1–3 scale: 0.25 = minimal, 0.5 = low, 1 = medium, 2 = high, 3 = massive.
- Confidence - How confident are you in your estimates? 100% = high confidence, 80% = medium, 50% = low. If you’re guessing, use 50%.
- Effort - How many person-months will this take? If it takes two engineers one month, Effort = 2. If it takes one engineer two weeks, Effort = 0.5.
A higher RICE score means more expected value for the effort invested.
RICE Prioritization Example
Here’s a worked example for a SaaS product team deciding between three features:
Feature A: In-app onboarding checklist
- Reach: 400 new users per quarter see the onboarding flow
- Impact: 2 (high - improves activation significantly)
- Confidence: 80% (you’ve seen this work at similar products)
- Effort: 1 person-month
RICE Score = (400 × 2 × 0.8) / 1 = 640
Feature B: Advanced export options
- Reach: 150 users per quarter use exports
- Impact: 1 (medium - nice to have for power users)
- Confidence: 100% (you’ve validated demand)
- Effort: 2 person-months
RICE Score = (150 × 1 × 1.0) / 2 = 75
Feature C: Mobile app
- Reach: 900 users per quarter (all users would benefit)
- Impact: 2 (high - addresses a top complaint)
- Confidence: 50% (you’re not sure users would actually switch)
- Effort: 6 person-months
RICE Score = (900 × 2 × 0.5) / 6 = 150
Result: Build the onboarding checklist first (RICE 640), then mobile app (RICE 150), then export options (RICE 75).
Why RICE Works
Before RICE, prioritization debates usually came down to whoever argued loudest or had the most seniority. That’s not a prioritization method - it’s just politics.
RICE forces teams to make their assumptions explicit. When you ask “what’s the Reach on this?” you’re forcing someone to think about real numbers instead of vibes. When you ask “what’s your Confidence?” you’re surfacing how much validation has actually happened.
The formula also naturally penalizes two common traps:
- Big bets with weak evidence - A high Impact score doesn’t help you if Confidence is 30%.
- Low-effort features that nobody uses - Fast to build doesn’t mean worth building. Low Effort looks great until you divide by it and see the small Reach.
How to Set RICE Values
Reach
Use actual data where you can. Look at:
- Analytics: how many users touch the relevant flow per quarter?
- Customer interviews: how many customers mentioned this?
- Support tickets: how many requests are in this category?
If you have no data, estimate conservatively and lower your Confidence score to compensate.
Impact
This is the hardest factor to measure. Most teams use a consistent scale:
| Impact Level | Score | Description |
|---|---|---|
| Massive | 3 | Game-changer - drives major activation/retention |
| High | 2 | Noticeably improves the core user experience |
| Medium | 1 | Users would appreciate it, not essential |
| Low | 0.5 | Small improvement for a subset of users |
| Minimal | 0.25 | Nice to have, rarely noticed |
Calibrate your scale with your team and apply it consistently. The exact numbers matter less than using the same scale every time.
Confidence
Be honest. If you’re pulling numbers from a single customer conversation, that’s 50%. If you’ve run a survey with 200 responses and A/B tested a prototype, that’s 100%. Inflating Confidence defeats the purpose of the framework.
| Confidence Level | Score | Description |
|---|---|---|
| High | 100% | Validated with data or strong past evidence |
| Medium | 80% | Reasonable evidence, some assumptions |
| Low | 50% | Mostly gut feel, limited validation |
Effort
Use person-months. One engineer working for two weeks = 0.5. Include design, engineering, and QA time. Don’t forget ongoing maintenance if it’s significant.
When RICE Falls Short
RICE is a good starting point, not a final answer. Watch for these failure modes:
It doesn’t account for strategic value. A feature that locks in an enterprise customer might score low on RICE but be essential for revenue. RICE should inform the conversation, not replace judgment.
Effort is hard to estimate. Teams routinely underestimate. Apply a buffer, or use ranges and calculate best/worst case RICE scores.
It can bias toward volume over quality. High Reach scores favor features that touch every user, even if the impact is shallow. Sometimes the right call is a deep improvement for a high-value segment.
It’s only as good as your inputs. Garbage in, garbage out. If everyone is guessing on Reach and inflating Impact, RICE becomes a feel-good exercise.
Use RICE to structure the conversation, not to end it.
RICE vs Other Prioritization Frameworks
| Framework | Best For | Tradeoff |
|---|---|---|
| RICE | Comparing many features objectively | Requires estimation work |
| MoSCoW | Quick must-have / nice-to-have sorting | No effort weighting |
| ICE | Faster scoring (Impact × Confidence × Ease) | Less rigorous |
| Kano | Categorizing feature types (basic vs delight) | Doesn’t rank within categories |
| Weighted Scoring | Custom criteria matter | Requires more setup |
RICE is the most widely used because it hits a good balance: more rigorous than ICE, less complex than weighted scoring, and directly tied to output (score per effort invested).
Using RICE for Backlog Prioritization
In practice, you run RICE in a spreadsheet or backlog tool before each sprint planning or quarterly planning cycle. The steps:
- List all candidate features for the upcoming cycle
- Fill in Reach, Impact, Confidence, Effort for each
- Calculate RICE scores
- Sort by RICE score descending
- Review the sorted list with the team - does it match intuition? If not, find the disagreement and surface the assumption behind it
- Commit to the top items for the sprint or quarter
The goal isn’t a perfect algorithm - it’s a shared language for trade-offs.
Automating Backlog Prioritization
The tedious part of RICE is not the formula - it’s keeping the inputs current. Reach changes as the product grows. New customer feedback shifts your Impact estimates. Features ship and priorities change.
Telos keeps backlog priorities updated automatically. It pulls from meeting discussions, Slack conversations, and customer feedback to surface what’s risen in importance and what’s gone stale. Instead of manually re-running a RICE spreadsheet each quarter, your backlog reflects current reality.
If you’re using RICE to prioritize features, you’re also running sprint planning with that prioritized backlog. See our guide to sprint planning and how to structure the sprint planning meeting agenda. For the backlog management work that happens between sprints, read about backlog grooming.
Telos is built for teams that want their backlog to reflect current priorities without manually re-scoring or re-sorting after every planning session.