ICE Prioritization Framework: How to Score Ideas by Impact, Confidence, and Ease

Bottom line: ICE is a lightweight prioritization framework that scores every idea on three factors — Impact, Confidence, and Ease — each rated on a 1–10 scale, then multiplies them into one number: ICE Score = Impact × Confidence × Ease. The highest scores get built first. ICE is faster and simpler than RICE, which makes it the default for early-stage startups and growth teams running rapid experiments — but its accuracy lives or dies on the Confidence score, the one variable that customer research turns from a guess into evidence.

Most teams don't fail because they run out of ideas. They fail because they bet engineering time on the wrong ones. Pendo's Feature Adoption Report found that 80% of features in the average software product are rarely or never used — a direct symptom of prioritizing by opinion and politics instead of by a consistent, evidence-based score. The ICE framework exists to replace "the loudest person in the room wins" with a number every stakeholder can see and challenge.

Who created ICE?

ICE was popularized by Sean Ellis, the growth marketer who coined the term "growth hacking" and led early growth at Dropbox and LogMeIn before founding GrowthHackers. Ellis needed a way to rank a long backlog of growth experiments quickly, without spending a full planning meeting debating each one. ICE became the default scoring model of the growth-hacking movement and remains one of the most widely used prioritization frameworks on growth and product teams today. RICE — the better-known cousin created at Intercom in 2016 — is explicitly an extension of ICE that adds a fourth variable, Reach.

What ICE stands for

ICE scores each idea on three dimensions:

• Impact — How much will this move the metric you care about if it works? A pricing-page redesign has higher potential impact than relabeling a footer link.
• Confidence — How sure are you it will actually work? This is your evidence score. A change backed by customer interviews, analytics, or a prior A/B test earns a high number; a hunch earns a low one.
• Ease — How quickly and cheaply can you ship it? Ease is the inverse of effort: a one-day copy change is a 9 or 10; a multi-quarter rebuild is a 1 or 2.

The ICE formula

ICE Score = Impact × Confidence × Ease

Each variable is rated 1–10. Because the three are multiplied, the maximum score is 1,000 (10 × 10 × 10) and the practical range for most backlogs lands between 50 and 500. Multiplication — rather than addition — is deliberate: it punishes ideas that are weak on any single dimension. A high-impact feature you have no confidence in, or that takes a year to build, gets dragged down hard. That is the framework doing its job.

In this backlog the social-proof change wins — not because it's the most ambitious, but because it's high-impact, well-evidenced, and cheap. The onboarding rebuild may be the "bigger" idea, but a Confidence of 4 (nobody has validated it) and an Ease of 2 (a quarter of work) correctly push it down until the team gathers evidence.

How to score each variable consistently

The biggest threat to ICE is inconsistent scoring — one PM's "8" being another's "5." Anchor every variable to a written rubric before you start:

Impact (1–10): Tie the scale to your North Star metric. 1–3 = negligible or cosmetic; 4–6 = a measurable lift to a secondary metric; 7–8 = a meaningful move on a primary metric; 9–10 = a step-change to revenue, activation, or retention.

Confidence (1–10): This is the evidence rubric and the heart of the framework. 1–3 = a guess or single opinion; 4–6 = some indirect signal (a support-ticket trend, a competitor doing it); 7–8 = direct evidence from analytics or a handful of customer interviews; 9–10 = strong, triangulated evidence — multiple interviews, a prior experiment, and quantitative data all pointing the same way.

Ease (1–10): Estimate with engineering in the room. 1–2 = multiple sprints; 3–5 = one sprint; 6–8 = a few days; 9–10 = hours. Always confirm Ease with the people who will build it, not the people who want it built.

The Confidence problem — where ICE quietly breaks

Here is the uncomfortable truth about ICE: Impact and Ease are educated estimates, but Confidence is supposed to be evidence — and most teams fake it. They assign a 7 or 8 to a feature they personally like, with nothing behind it. When Confidence is a disguised opinion, the entire score is theater, and ICE just launders gut feel into a number that looks objective.

The fix is not a better spreadsheet. It's better evidence — gathered fast enough to keep up with your backlog. Traditionally, raising a Confidence score meant scheduling a week of user interviews, transcribing them, and manually tagging themes — far too slow to run before every prioritization meeting, so teams skip it and guess. That bottleneck is exactly what AI-native research removes.

How Koji strengthens every Confidence score

Koji is an AI-native customer research platform built to make evidence cheap enough to gather before you score, not after you ship. Where traditional research takes weeks, Koji turns it into minutes:

• AI-moderated interviews run 24/7 in voice or text, asking intelligent follow-up questions and probing for the "why" behind every answer — so you can interview 30 customers about a backlog item over a weekend instead of scheduling them across a month.
• Structured questions give you quantifiable evidence inside a qualitative conversation. Koji supports six structured question types — open_ended, scale, single_choice, multiple_choice, ranking, and yes_no — so you can capture a ranked feature preference or a 1–5 demand score and the reasoning behind it in the same interview. A "ranking" question across your top five backlog ideas is a direct, defensible input to the Impact and Confidence variables. See the structured questions guide.
• Automatic thematic analysis clusters dozens of interviews into themes and surfaces the share of customers who raised each issue — converting "I think users want this" into "62% of interviewed users described this pain unprompted," which is the difference between a Confidence of 4 and a Confidence of 9.
• Real-time reporting means the evidence is ready the same day, so research keeps pace with your sprint planning instead of lagging it.

The result: where a manual workflow caps Confidence at a defensible 5 or 6, an AI-assisted workflow lets you defend an 8–10 with specific numbers — and teams using AI-assisted research consistently report dramatically faster time-to-insight, often cutting weeks of synthesis down to hours. You don't need a PhD in research methods to do it; you describe who you want to talk to and what you need to learn, and Koji runs the study.

Running an ICE prioritization session (step by step)

1. Gather the backlog. Put every candidate idea in one list — features, experiments, fixes.
2. Agree the rubrics. Lock the 1–10 definitions for Impact, Confidence, and Ease before anyone scores, so the numbers mean the same thing across the team.
3. Score independently, then reconcile. Have each stakeholder score privately, then discuss the items where scores diverge most — that divergence is where the useful conversation lives.
4. Pressure-test Confidence. For the top candidates, ask "what evidence supports this?" Anything resting on opinion is a signal to run a quick Koji study before committing engineering time.
5. Rank and draw the line. Sort by ICE score and commit to roughly the top tier of the list for the next cycle.
6. Re-score regularly. Confidence rises as evidence accumulates and Ease changes as scope clarifies; re-score every cycle so stale numbers never drive live decisions.

ICE vs RICE vs other frameworks

• ICE vs RICE: RICE adds Reach (how many users are affected) and replaces Ease with Effort in person-months. RICE is more rigorous once you can estimate audience size; ICE is faster and better when cohorts are still fuzzy — typical of early-stage products.
• ICE vs MoSCoW: MoSCoW sorts items into Must/Should/Could/Won't buckets. It's great for release scoping but offers no within-bucket ranking; ICE gives you a continuous score.
• ICE vs the Kano Model: Kano classifies features by how they affect customer satisfaction (basic, performance, delight). Use Kano to understand what kind of value a feature delivers, then ICE to sequence the work.
• ICE vs the Opportunity Solution Tree: The tree keeps solutions tied to validated opportunities and outcomes; ICE prioritizes within a branch. They're complementary, not competing.

Common ICE mistakes to avoid

• Faking Confidence. The single most common failure. If you can't cite evidence, the number is a guess — go gather it.
• Letting one person score alone. ICE is a conversation tool; solo scoring just encodes one person's bias.
• Comparing scores across different rubrics. ICE scores are only meaningful relative to other ideas scored with the same rubric.
• Treating the score as the decision. ICE ranks; humans decide. Strategy, dependencies, and timing still override the spreadsheet.
• Never re-scoring. A score from last quarter reflects last quarter's evidence.

Related Resources

• Structured Questions Guide — the six question types that turn interviews into quantifiable Confidence evidence
• RICE Prioritization Framework — add Reach when you can estimate audience size
• Kano Model — classify features by their effect on satisfaction
• MoSCoW Prioritization Method — bucket scope for a release
• Opportunity Solution Tree — keep solutions tied to validated opportunities
• How to Prioritize Customer Feedback — turn raw feedback into a ranked backlog