By Tom Dewhurst, Co-founder, Growth Division · Updated October 2026
The ICE framework is a way to prioritise growth experiments by scoring each idea from 1 to 10 on Impact, Confidence and Ease, then averaging the three into a single ICE score. The highest-scoring ideas get tested first. It was popularised by Sean Ellis, who also coined the term "growth hacking", and it remains the quickest prioritisation method a small growth team can run.
We use ICE on every engagement at Growth Division. Below is how it works, a scored example backlog, how it compares with RICE and PIE, and the ways it goes wrong.
What does ICE stand for?
ICE stands for Impact, Confidence and Ease. Each is scored from 1 (low) to 10 (high).
- Impact: if this works, how much will it move the metric that matters? For us that is the North Star Metric, not a channel vanity number.
- Confidence: how sure are you that it will work? This should reflect evidence, not enthusiasm.
- Ease: how cheap and quick is it to test properly? "Properly" means with enough time and the right specialist to avoid a false negative.
ICE does one job: it ranks a backlog that is longer than your capacity. Startups rarely lack ideas. They lack a fair way to decide which three run this sprint.
How do you calculate an ICE score?
- Write each idea as a hypothesis. "We believe [change] for [segment] will move [metric] by [amount] because [evidence]." Without the evidence line you have nothing to base Confidence on.
- Score Impact, Confidence and Ease from 1 to 10. Use written anchors (see the calibration section below) so a 7 means the same thing to everyone.
- Average the three. ICE score = (I + C + E) ÷ 3.
- Rank the backlog by ICE score, highest first.
- Pull the top ideas into the next sprint up to your team's capacity, then rescore the rest when results come in.
Some teams multiply instead (I × C × E, giving a score out of 1,000). Multiplying punishes a single low score much harder. That can be useful if you want to filter out anything hard to build, but it also buries high-impact ideas that need engineering time. We average, and treat Ease as a tie-breaker rather than a veto.
What does a scored ICE backlog look like?
Here is an illustrative backlog for a B2B SaaS company whose North Star is weekly active accounts. The ideas are typical of what we see in a first sprint.
| # | Experiment idea | Impact | Confidence | Ease | ICE score (average) |
|---|---|---|---|---|---|
| 1 | Rewrite the pricing-page headline using phrases from 20 sales calls | 6 | 7 | 9 | 7.3 |
| 2 | LinkedIn retargeting to visitors who viewed the demo page | 7 | 6 | 7 | 6.7 |
| 3 | Add a setup checklist to onboarding to lift activation | 9 | 6 | 3 | 6.0 |
| 4 | Outbound sequence to companies hiring for the buyer's role | 6 | 5 | 6 | 5.7 |
| 5 | Co-hosted webinar with an adjacent tool | 7 | 4 | 5 | 5.3 |
The sprint takes ideas 1 to 3. Notice what multiplication would do: idea 3 scores 162 (9 × 6 × 3) and drops below idea 4 at 180 (6 × 5 × 6). The onboarding checklist has the biggest potential impact on the list, and multiplying would push it out of the sprint because it is harder to build. That is the trade-off to be aware of when you choose a formula.
How does ICE compare with RICE and PIE?
ICE is not the only scoring model. The two you will meet most often are RICE and PIE.
| ICE | RICE | PIE | |
|---|---|---|---|
| Stands for | Impact, Confidence, Ease | Reach, Impact, Confidence, Effort | Potential, Importance, Ease |
| Associated with | Sean Ellis | Intercom | Chris Goward / WiderFunnel |
| Formula | (I + C + E) ÷ 3, or I × C × E | (Reach × Impact × Confidence) ÷ Effort | (P + I + E) ÷ 3 |
| Best for | Growth experiment backlogs, fast weekly or fortnightly prioritisation | Product roadmaps where reach differs a lot between ideas | Conversion optimisation: choosing which pages to test |
| Time to score 20 ideas | About 30 minutes | 1 to 2 hours (needs reach data) | About 30 minutes |
| Main weakness | Subjective; scores drift without anchors | Slower; reach estimates can be false precision | Scores pages, not ideas; less useful across channels |
Our rule of thumb: use ICE for growth experiments, RICE when a product team is weighing features that touch very different numbers of users, and PIE when the question is "which page should we test next?"
How do you calibrate ICE scores so they don't drift?
The biggest complaint about ICE is that it is subjective. It is, but you can make it consistent. Scores drift when "8" means "exciting" in March and "proven" in June. Fix that with written anchors.
Impact anchors (expected lift in the North Star if the test wins):
- 1–2: under 1%
- 3–4: 1–3%
- 5–6: 3–7%
- 7–8: 7–15%
- 9–10: over 15%
Confidence anchors (the evidence ladder):
- 1–2: a hunch
- 3–4: a competitor does it, or one customer asked for it
- 5–6: a pattern across customer interviews, sales calls or reviews
- 7–8: a related test already won in our own data
- 9–10: a repeat of a proven test in a new segment or channel
Ease anchors (time to launch a properly run test):
- 9–10: under a day
- 7–8: up to three days
- 5–6: up to a week
- 3–4: a full sprint
- 1–2: more than a sprint, or needs engineering
Three habits keep the anchors honest:
- Score independently, then compare. Each person scores alone, then the group discusses gaps of 3 or more. A big Confidence gap usually means someone knows something the others don't.
- Check predictions against results. Log the Impact you predicted next to the lift you got. After ten tests you will see whether your team over- or under-scores.
- Rescore monthly. A win or a loss should change the Confidence score of related ideas. A backlog scored once in January is stale by March.
When does ICE break down?
ICE is a ranking tool, not a decision engine. It struggles in three situations.
Low-traffic startups. If you get 2,000 visitors a month, a test that might lift conversion by 3% will never reach a readable result inside a sprint. ICE will happily rank it highly anyway. At low volume, score Impact on what you can detect, not just what you hope for, and favour bigger swings: a new channel, offer or segment rather than a button colour. Our growth experimentation framework guide covers how to size tests to your traffic.
The HiPPO effect. HiPPO is the "highest paid person's opinion". When the founder scores first, or scores out loud, everyone else's Confidence quietly moves towards theirs. Independent scoring is the fix. So is a rule that the founder's favourite idea runs only if it earns its place.
Strategic bets. Some work matters but will never win a two-week ICE contest: a pricing overhaul, a rebuilt checkout, a new market. Don't force these through ICE. Keep a separate, small list of strategic projects and use ICE for the experiment backlog only. The original version of this post made the same point, and it still holds.
How we use ICE at Growth Division
ICE sits in the middle of our process, not at the start.
- Bullseye first. We use the Bullseye Framework to narrow roughly 19 traction channels to 3–6 worth testing. ICE then ranks experiment ideas within those channels.
- Two-week sprints. The top-scoring ideas go into a two-week sprint, each with a hypothesis, a success metric and a scale, iterate or kill rule agreed before launch.
- GREX AI does the first pass. Our AI growth operating system, GREX, structures each experiment and scores it with ICE against the client's North Star. A named senior strategist reviews every score before it goes into a sprint, because AI is good at consistency and poor at knowing what the founder heard on last week's sales call.
- Weekly review. Each week we check results against the North Star and rescore the backlog.
What are the common mistakes with ICE scoring?
- Scoring tasks, not hypotheses. "Post on TikTok" can't be scored. "Short demo clips will lift trial sign-ups among ops managers by 10% because they ask for walkthroughs on calls" can.
- Scoring Impact against the wrong metric. If Impact means clicks for one idea and revenue for another, the ranking is meaningless. Score everything against the North Star.
- Inflating Confidence. Enthusiasm is not evidence. Use the ladder.
- Never rescoring. Results should change scores. If they don't, you aren't learning.
- Treating the score as the decision. ICE ranks. People still decide, especially on strategic bets.
FAQs
What is a good ICE score?
There is no universal threshold, because scores are relative to your own backlog. On a 1–10 average, anything above 7 is usually a clear priority and anything below 4 rarely makes a sprint. What matters is the ranking and whether your anchors are consistent.
Should you average or multiply ICE scores?
Both are used. Averaging (I + C + E ÷ 3) is more forgiving of one low score; multiplying (I × C × E) punishes it heavily. We average so that high-impact but harder ideas aren't buried, and we use Ease as a tie-breaker.
Who created the ICE framework?
ICE was popularised by Sean Ellis, who also coined the term "growth hacking". It became a standard way for growth teams to rank experiment backlogs.
What is the difference between ICE and RICE?
RICE adds Reach (how many users an idea affects) and divides by Effort. It suits product roadmaps where reach varies a lot. ICE is quicker and suits growth experiment backlogs that are rescored every sprint.
How often should you rescore an ICE backlog?
At least monthly, and after any test that teaches you something about related ideas. We review weekly and rescore as results come in.
Not sure which experiments to run first? Book a free 1-hour Bullseye Strategy Session → /contact-us. We'll help you shortlist channels and leave you with a scored backlog.
Related reading: what is the AARRR framework? · building a growth marketing framework that scales your startup
.png)
.png)
