Home/Product/Feature Prioritization (RICE/ICE)
Product
intermediate📖 6 min read

Feature Prioritization (RICE/ICE)

Also known as: RICE FrameworkICE ScoringFeature ScoringPrioritization MatrixWSJFMoSCoW

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

The Concept

Feature prioritization is the discipline of deciding WHAT to build and in WHAT ORDER using a repeatable, data-driven framework instead of gut feeling or whoever shouts loudest. The RICE framework scores each feature on Reach (how many users), Impact (how much it moves the needle, 0.25-3x), Confidence (how sure you are, 0-100%), and Effort (person-months). RICE Score = (Reach × Impact × Confidence) ÷ Effort. The ICE variant uses Impact, Confidence, and Ease (inverse of effort). Teams using structured prioritization ship 50% fewer 'wasted' features.

Real-World Example

Intercom uses a strict RICE variant to prioritize their product. When a massive enterprise customer demanded a niche feature, they ran it through RICE. The 'Reach' was literally 1 customer. The 'Score' was dismal. The product team used the math to defend shutting the request down, ensuring they built features that served thousands of users instead.

⚠️

The Trap

The biggest prioritization trap is the HiPPO problem — Highest Paid Person's Opinion wins. In organizations without a framework, 64% of features are prioritized by executive request rather than data. Another trap: overweighting 'Reach' and building for the majority while ignoring high-value power users. A feature used by 5% of users who generate 40% of revenue may score higher than a feature for 80% of users who are on free plans.

🎯

The Action

Score every feature request with RICE before it enters your roadmap. Create a shared spreadsheet: Feature | Reach (users/quarter) | Impact (0.25-3x) | Confidence (%) | Effort (person-weeks) | RICE Score. Stack rank by score. Review the top 5 and bottom 5 — if any bottom-5 feature 'feels' wrong, challenge your scoring inputs. Commit to building only the top 3 RICE items per sprint.

Pro Tips

1

Confidence is the most underrated input. A feature with 3x impact but 20% confidence (score: 0.6) should lose to a feature with 1x impact and 90% confidence (score: 0.9). Run a quick customer validation before committing to low-confidence features.

2

Add 'Revenue Impact' as a tiebreaker column. If two features have similar RICE scores, the one that drives measurable revenue wins. This prevents analysis paralysis.

3

Never let any single person score alone — use team-average scoring to reduce individual bias. Product, Engineering, and Sales should each contribute scores.

🚫

Common Myths

The framework will tell you exactly what to build

RICE/ICE generates a ranked list, but it's a decision SUPPORT tool, not an oracle. The framework helps you articulate WHY you chose something — when the CEO asks 'why aren't we building X?', you can point to its score.

Small features should be skipped because they have low Reach

Small features with high Confidence and low Effort can have massive RICE scores. Bug fixes and UX polish often have extremely low effort (0.5) and high confidence (100%), making their RICE score competitive with big features.

📊

Real-World Case Studies

Basecamp

Continuous

success

Basecamp famously does not have a traditional backlog of thousands of feature requests. They use 'Shape Up', heavily prioritizing features based on a strictly constrained effort (appetite) of 6 weeks. If a feature's effort is larger than 6 weeks, it's not prioritized unless it can be radically simplified. They enforce this constraint strictly to avoid multi-month death marches.

Prioritization Cycle

6 Weeks

Backlog Size

Zero (reset every cycle)

💡 Lesson: Effort constraint is a powerful prioritizing function. If you fix the effort timebox, you are forced to prioritize only the most impactful slice of a feature.

📈

Industry Benchmarks

Process Efficiency

Post-Implementation

Elite

> 90%

Average

50-90%

Lagging

< 50%

🛠️

Recommended Tools

🎓

Go Deeper: Certifications

🎮

Decision Scenario: The VIP Customer Demand

You are the PM. A client representing 15% of your total revenue threatens to cancel if you don't build a custom reporting dashboard immediately. Meanwhile, a major security flaw needs fixing.

Client Revenue

$1M

Security Risk

High (Affects 100% users)

Decision 1

Your engineering team only has bandwidth for one initiative this sprint.

Build the custom dashboard to save the $1M account.Click →
You skip the security fix. Next week, a minor breach occurs. You lose the trust of the entire market, resulting in 30% global churn. The VIP customer leaves anyway due to the breach.
Global Revenue: -30%
Reject the VIP demand. Fix the security flaw. RICE score dictates that a High Impact / 100% Reach bug fix wins.Click →
You secure the platform for everyone. The VIP is angry but respects the transparency when you explain the security stakes. They stay. The framework saved you from a fatal error.
Global Revenue: Stable
🧪

Knowledge Check

Challenge coming soon for this concept.

Related Concepts

Turn knowledge into action

Try our free calculators to apply these concepts with your own numbers.

Try the Calculators →