ICE and RICE — Prioritization Frameworks That Actually Work
Prioritization is hard. These frameworks help — if you don't overthink them.
Prioritization is hard. These frameworks help — if you don't overthink them.

Every product has more ideas than capacity. The backlog grows. Stakeholders push their pet features. Engineers want to refactor everything. Marketing wants splash features. Support wants bug fixes.
How do you decide what to build?
You need a system. Not to remove judgment, but to make the judgment explicit and debatable. ICE and RICE are two frameworks that actually help.
Without a framework, prioritization becomes political. Whoever argues loudest wins. Or whoever has the most seniority. Or whatever got mentioned last in a meeting.
Frameworks force you to articulate why something should be prioritized. They make the reasoning visible and debatable.
ICE scores each idea on three dimensions:
Impact: How much will this move the needle? (1-10) Confidence: How sure are we about the impact? (1-10) Ease: How easy is this to implement? (1-10)
Score = Impact × Confidence × Ease
Higher score = higher priority.
Example:
Feature A: Add dark mode
Feature B: Improve search algorithm
Dark mode wins despite lower impact, because it's easier and we're more confident.
RICE adds one more dimension:
Reach: How many users will this affect? (number of users/month) Impact: How much will it affect those users? (0.25-3 scale) Confidence: How confident are we? (percentage) Effort: How much work? (person-weeks)
Score = (Reach × Impact × Confidence) / Effort
Example:
Feature A: Onboarding improvement
Feature B: Admin dashboard redesign
Onboarding wins big because it affects far more people.
Use ICE when:
Use RICE when:
I use ICE for weekly planning, RICE for quarterly roadmapping.
Over-precision: Don't agonize over whether something is a 6 or a 7. These are rough estimates. Directionally correct is good enough.
Gaming the scores: People inflate impact scores for features they want. Combat this by making the team score together, or having one person score everything for consistency.
Ignoring qualitative factors: Some things don't score well but need to happen anyway. Security fixes. Legal compliance. Technical debt that's causing incidents. Frameworks inform decisions, they don't make them.
Only looking at the score: A feature with score 500 isn't automatically better than one with score 450. The scores get you in the ballpark. Human judgment picks the final order.
Talking to users.
If users are screaming about a problem, that probably beats whatever your framework says. If you build something that scores well but nobody wants, the framework was wrong.
Frameworks are tools, not answers. They help organize thinking. They don't replace understanding your users and market.
The best prioritization system is one your team actually uses. ICE and RICE are good starting points. Adapt them to fit how your team thinks. The goal is clarity and alignment, not bureaucratic precision.