ICE Scoring for Product Teams

What is ICE scoring?

ICE is a prioritization framework that scores each item in your backlog across three dimensions:

• Impact — How much value will this create if it works? Consider business outcomes, customer satisfaction, and revenue potential.
• Confidence — How sure are you that it will have that impact, and that your effort estimate is accurate? Lower confidence should temper a high impact score.
• Ease — How straightforward is this to deliver? A high ease score means low complexity, few dependencies, and a small team footprint.

The formula is simple:

ICE Score = Impact × Confidence × Ease

Each dimension is typically scored on a 1–10 scale. The score is meaningful only in comparison to other issues scored with the same assumptions — not as an absolute measure of value.

A worked example

Imagine you're evaluating three items in a SaaS product backlog:

• In-app onboarding checklist — Impact 8, Confidence 7, Ease 6. ICE Score: 336. High impact on activation, reasonably confident, moderate effort.
• Export to CSV — Impact 5, Confidence 9, Ease 8. ICE Score: 360. Frequently requested, easy to build, but limited strategic upside.
• Slack integration — Impact 9, Confidence 4, Ease 3. ICE Score: 108. Potentially transformative, but confidence is low and delivery is complex.

The CSV export scores highest despite being the least strategically exciting — because it's easy to deliver and confidence is high. The Slack integration, despite its potential, ranks last because uncertainty and complexity pull its score down sharply.

This is a feature of ICE, not a bug. It surfaces quick, reliable wins and pushes speculative, complex work down the list until confidence improves.

Where ICE works well

ICE is particularly effective when:

• You're prioritizing growth experiments or A/B tests where speed of iteration matters.
• You're at an early stage and don't have reliable usage data to estimate reach.
• Your backlog is dominated by independent items rather than large interdependent initiatives.
• Your team is new to structured prioritization and needs a simple framework to build the habit.
• You're prioritizing content, marketing, or operational improvements rather than product features.

Where ICE falls short

ICE's simplicity is also its main limitation. Three dimensions can't capture everything that makes an item worth prioritizing.

What ICE doesn't account for:

• Strategic alignment — An easy, high-impact feature might not support your current company direction at all.
• Customer signal — ICE doesn't distinguish between items your customers are urgently requesting and items the product team thinks are important.
• Delivery readiness — An item can be easy to build in theory but not yet ready to start — because requirements aren't defined, a dependency isn't resolved, or the right person isn't available.
• Reach — Two items with the same ICE score might affect 10 users or 10,000 users. ICE treats them identically.

For teams where these distinctions matter — typically B2B SaaS companies with defined roadmap goals, multiple stakeholders, and a mix of customer-facing and infrastructure work — a more structured framework tends to produce better decisions.

ICE vs RICE: what's the difference?

RICE, developed by Intercom, addresses one of ICE's gaps by adding a Reach dimension and replacing Ease with Effort (inverted, so higher effort means a lower score).

The RICE formula: (Reach × Impact × Confidence) ÷ Effort

RICE works well for teams with reliable customer data who need to compare work affecting very different numbers of users. If you can accurately estimate that a feature will reach 2,000 customers versus 200, RICE reflects that distinction directly in the score.

ICE is better when reach data isn't available or reliable — early-stage products, internal tools, growth experiments, or any context where estimating how many users a change affects is more guesswork than measurement.

Neither framework explicitly handles strategic alignment or delivery readiness. Both share the same core limitation: the score is only as good as the inputs, and inputs tend to vary across team members.

Going beyond ICE and RICE

The most common challenge product teams encounter isn't choosing between ICE and RICE — it's that a single person's score doesn't reflect the full picture.

A product manager, engineer, customer success manager, and executive will often score the same issue very differently. Those differences aren't noise — they're signal. They reveal assumptions, missing context, and competing perspectives that should inform the final decision.

CoJii extends this kind of structured scoring with six dimensions organized across three groups:

• Value — Impact and Customer Signal
• Feasibility — Effort and Readiness
• Strategy — Strategic Alignment and Confidence

Unlike ICE or RICE — which are typically filled in by one person — CoJii is designed for teams to score collaboratively, surface disagreements, and reach informed consensus before syncing priorities back to Linear.