Academy · 2026-07-27 · 7 min read
Feature request prioritization: RICE vs ICE
By Feedlark Team
Key takeaways
- • RICE (Reach, Impact, Confidence, Effort) and ICE (Impact, Confidence, Ease) are the two most common lightweight scoring frameworks for feature backlogs.
- • The single biggest source of bad prioritization is a made-up Reach score. Vote counts on a public feedback board are a real, defensible number instead of a guess.
- • ICE is faster to run but easier to game with optimism bias; RICE takes longer but forces a Reach estimate that's harder to fudge.
- • Neither framework replaces judgment. Use the score to rank candidates, then sanity-check the top of the list against strategy before committing engineering time.
Every product team eventually hits the same wall: more feature requests than engineering hours, and no shared language for deciding what goes first. Two scoring frameworks, RICE and ICE, exist to turn that argument into a spreadsheet instead of a shouting match. Neither is complicated, and neither works well without decent input data, which is exactly where most teams quietly go wrong.
RICE: Reach, Impact, Confidence, Effort
RICE scores each request on four factors and divides to get a single number: (Reach x Impact x Confidence) / Effort. Reach is how many users a change touches in a given period. Impact is a rough multiplier (0.25 for minimal, up to 3 for massive). Confidence is a percentage reflecting how sure you are about the other three numbers. Effort is person-months of work. The framework was popularized by Intercom specifically because Reach forces you to separate 'a loud customer wants this' from 'a lot of customers want this.'
ICE: Impact, Confidence, Ease
ICE drops Reach and multiplies three 1-10 scores: Impact, Confidence, Ease. It's faster to fill in during a triage meeting because there's no separate reach estimate to research, but that speed is also its weakness. Without a Reach number, Impact scores tend to reflect whoever argued most persuasively in the room rather than actual demand.
| Factor | RICE | ICE |
|---|---|---|
| Formula | (Reach x Impact x Confidence) / Effort | Impact x Confidence x Ease |
| Time to score one item | 5-10 minutes with real data | 1-2 minutes |
| Needs a reach estimate | Yes, explicitly | No, folded into Impact |
| Easiest to game | Confidence and Effort | Impact |
| Best fit | Backlogs with usage/vote data available | Fast early-stage triage |
Where the Reach number should actually come from
Most teams estimate Reach from memory or a quick guess: 'probably a lot of people want this.' That's the weak point in the entire exercise. If requests live on a public feature request board with voting, Reach stops being a guess: it's the vote count, filtered to your actual customer base rather than anonymous internet traffic. A request with 40 votes from paying accounts is a materially different Reach number than one with 3 votes from trial users, and that distinction is invisible if requests arrive as scattered Slack messages and support tickets instead of a single board.
“The teams who prioritize well aren't the ones with the fanciest scoring spreadsheet. They're the ones who made it cheap to collect real demand signal in one place, so the spreadsheet has something honest to work with.”
— Feedlark Team
A simple decision rule for picking between them
- Backlog under 20 items and you triage weekly? Use ICE, it's fast enough to redo every sprint.
- Backlog is large, cross-functional, or reviewed quarterly? Use RICE, the extra rigor pays off at that scale.
- Either framework, without real Reach or vote data, is closer to a priority-flavored guess than a real score. Fix data collection before optimizing the formula.
- Re-score on a cadence, not once. A request that scored low six months ago can jump the queue once votes accumulate.
Common mistakes that quietly break both frameworks
The most common failure is scoring Confidence generously to justify a decision you'd already made. Be stricter than feels comfortable: if you're relying on a single customer conversation, that's 50% confidence, not 90%. The second common mistake is treating the final score as a ranking to follow blindly rather than a starting point. A request that scores lower but ships a strategic bet (a new integration that unlocks a whole segment) can still be worth pulling forward. The framework should inform the conversation, not replace it.
Frequently asked questions
- Is RICE or ICE better for feature prioritization?
- RICE is more rigorous because it forces an explicit Reach estimate, which is usually the number teams are most tempted to fudge. ICE is faster and works well for small, frequently-reviewed backlogs where speed matters more than precision.
- Where should the Reach number in RICE come from?
- The strongest source is real vote or usage data, for example vote counts on a public feedback board, rather than a guess. This turns Reach from an opinion into a number you can defend to stakeholders.
- How often should a feature backlog be re-scored?
- Whenever new demand signal arrives, such as a batch of new votes on a request, or at a minimum every planning cycle. A static score from months ago stops reflecting current reality.
- Can prioritization frameworks replace product judgment?
- No. RICE and ICE rank candidates using the inputs you give them, but strategic bets, technical debt, and platform investments often don't score well on demand alone and still need a human call.
Feedlark Team. The Feedlark team builds and maintains the feedback, roadmap and changelog platform referenced in this guide.