ICE Scoring: Prioritize Features and Experiments Without Hand-Waving

Why “we have ten high-priority features” means nothing

Most founder feature lists rank by gut. The features the founder gets excited about float to the top. The features the team agrees are important sit in the middle. The features nobody loves slide off the bottom.

That’s not prioritization. That’s preference dressed as strategy.

ICE Scoring (Sean Ellis, popularized via GrowthHackers around 2014) is the simplest framework that forces explicit, numeric scoring of three dimensions. The math doesn’t matter as much as the discipline of having to score honestly. Specifically: having to defend your Confidence score with evidence.

The three multipliers

Impact (1-10): how much does this item move the metric that matters?

Impact requires a defined target metric. “Impact on what, exactly?” If the metric isn’t named, the score is meaningless. Common metrics:

• Conversion rate (impressions → signups)
• Activation rate (signups → first meaningful action)
• Retention (cohort retention at week 4, 12, 24)
• Revenue per cohort
• CAC reduction

Pick the metric that matters most for your current stage. For pre-PMF, that’s usually conversion or activation. For early growth, it’s retention. For scaling, it’s CAC and revenue per cohort.

Confidence (1-10): how sure are you about the Impact score?

Confidence is where ICE earns or loses its value. Without honest Confidence scoring, the framework becomes a justification engine: high Confidence for pet projects, low Confidence for things you don’t like.

The discipline: force yourself (or a co-founder, or an advisor) to name three pieces of evidence supporting any Confidence score above 7. Evidence types:

• Prior experiment results from your own product
• User research data (interviews, surveys, behavior analytics)
• Industry benchmark data (cohort data from similar products)
• Validated patterns from comparable startups

If you can’t name three pieces of evidence, Confidence drops to 5 or below. This is the framework’s main analytical bite.

Ease (1-10): how easy is this to build or execute?

10 = trivial (an hour of work). 1 = massive (months). For features, Ease incorporates:

• Engineering time
• Design time
• Testing time
• External dependencies (APIs, integrations, contracts)
• Risk-adjusted time (multiply by 1.5 if there’s unknown complexity)

Founders without engineering instincts systematically overscore Ease. Verify with whoever will actually build it.

The math

ICE Score = Impact × Confidence × Ease

Multiply, not add. Multiplication means a weakness in any dimension drags the total down. A 10-10-1 (100) ranks below a 6-6-6 (216) because the high-effort item needs exceptional impact AND confidence to clear a moderate-everything alternative.

A worked example

You’re prioritizing 6 features for V1.1 of a customer feedback tool. Target metric: 30-day retention.

Ranking by ICE: Slack (360), roadmap voting (336, tied), email digest (336, tied), browser extension (160), AI clustering (108), iOS app (84).

Now check Confidence. Why is Slack 9? Because you have data from 4 prior B2B SaaS products you’ve built showing Slack integration is a top-3 retention driver. That’s 3+ pieces of evidence; 9 holds.

Why is browser extension 5? Because the Impact (8) is from your own intuition that “inline feedback would be huge.” No evidence yet. 5 is the right Confidence; if you score it 9, you’re inflating.

Why is AI clustering 4? Because you’re not sure whether this actually moves retention. It might just be a feature users notice but don’t change behavior on. 4 is honest.

The rankings suggest: build Slack first, then roadmap voting and email digest (tied), then browser extension. Skip AI clustering and iOS app for V1.1. They go in the V2 file.

Confidence is the audit

The biggest mistake in ICE: scoring Confidence by feeling rather than evidence.

The audit:

For each item with Confidence ≥ 7, write down the evidence in one sentence. Examples:

• “Prior experiment in our last product showed inline feedback increased 30-day retention by 22%.”
• “User interview with 12 buyers had 9 explicitly mention email digest as a feature they’d pay for.”
• “Benchmark data from Public.com’s 2024 case study shows Slack integration moves retention 15-20% in similar tools.”

If you can’t write that sentence, the Confidence is inflated. Drop it.

The audit catches most pet-project bias. It also catches over-cautious scoring on items where you actually have evidence but defaulted to a middle score.

When NOT to use ICE

ICE is a quantitative ranking tool. It assumes:

• You have a list of candidate items (not generating ideas, just ranking them)
• The items are comparable on the same metric (not “should we build feature X or rebrand?”)
• You can estimate effort honestly (not “we’ll figure it out later”)

When these don’t hold, ICE produces garbage rankings. For idea generation, use lateral techniques (mind mapping, customer interview synthesis) first. For comparing items with different metric impacts, decide the meta-priority first (“revenue this quarter vs retention this year”) before running ICE within each meta-priority.

ICE vs MoSCoW

MoSCoW and ICE complement each other:

• MoSCoW is qualitative and discrete (4 buckets). Used first to sort what’s even in scope for the version.
• ICE is quantitative and continuous (numerical scores). Used second to rank within the Must list.

Workflow: apply MoSCoW to get the Must items for V1. Then apply ICE to the Must list to sequence development order. Build highest-ICE first.

Common mistakes

1. Confidence inflation. Pet projects get 9. Demand evidence for any 8+.

2. No defined metric. Score against a specific metric or scores are meaningless.

3. Ease overscored. Founders without dev backgrounds systematically overestimate Ease. Verify with builders.

4. Static scores. Re-score every 4-8 weeks as evidence accumulates.

5. Treating ICE as the final decision. ICE ranks. You still decide based on the ranking PLUS qualitative coherence (do the top items make a sensible product or campaign?).

ShipFit and ICE

The most visible ICE-style scoring in the ShipFit product is Stage 5 (What’s V1?). Every candidate feature gets a 0-10 score (rolling Impact + Confidence into one number) plus an S / M / L effort tag (the Ease dimension, kept categorical so it can’t be over-engineered). Features are then sorted into three buckets that determine cut order:

• Differentiator: the 3-5 features that make the buyer pick you over the incumbent. Keep all, regardless of effort.
• Delight: features users will love but can’t afford yet. Cut first, the explicit instruction in the UI. Most go to V2.
• Operational: the plumbing that makes the Differentiators work (auth, billing, basic admin). Keep the minimum.

The cut decisions are visible (each feature shows its score + tag side by side) instead of hidden in a spreadsheet. ShipFit’s Confidence audit forces evidence for any score ≥ 7. If you can’t name evidence, the system drops the score to 5 and recomputes the ranking. The audit removes the pet-project bias that breaks most founder-run ICE exercises.

ICE shows up again at:

Stage 6 (How to Charge?). Each competitor gets a 0-100 Feature Score plotted against price; the resulting Pricing Position drops you into a Value / Premium / Budget / Overpriced zone with a Recommended price.

Stage 8 (How to Launch?). ICE ranks candidate launch channels (Twitter, Product Hunt, outreach, etc.) so you pick the top 2 by total score. See launch-plan spoke for the full channel-ICE workflow.

Further reading

• Sean Ellis’s GrowthHackers post (2014) introducing ICE for growth experiments. Search “ICE Score GrowthHackers.”
• Itamar Gilad’s “Confidence Meter” (2018). A deeper take on the Confidence dimension specifically, including the role of evidence types in scoring.
• MoSCoW prioritization. Pairs with ICE for full prioritization workflow.
• Lean Startup validation. Provides the experiment-design framework that gives ICE its Confidence inputs.