Framework Deep Dive

ICE 评分模型

对每个增长实验或功能想法,用三个维度打分后相乘:影响力(Impact)× 信心度(Confidence)× 易实现性(Ease)。30 分钟内把 15 个想法排出优先级,终结「我感觉这个更重要」的内耗。

增长团队为什么总在讨论「感觉」?

增长团队每周都能产生大量实验想法。问题不是想法不够多,而是如何在有限的执行资源下,快速决定从哪里开始。

没有结构化框架时,优先级讨论会退化为政治博弈:声音最大的人赢,或者资历最深的人赢。高影响力但执行成本低的快速验证机会被忽略,而「重量级」功能(因为听起来更有价值)挤占了实验资源。

Sean Ellis 在构建 GrowthHackers 时需要一个工具,让增长团队在每周例会上快速排出下周要跑的 Top 3 实验。ICE 的核心洞察:只需要三个维度,相乘得出分数,讨论分歧而非讨论感受。数字不是最终答案,但它让对话变得具体。

三个维度相乘,最高 1000 分

I
Impact
×
C
Confidence
×
E
Ease
=
ICE
Score
1–1000
I
影响力
Impact
如果这个实验成功,对核心指标(DAU、转化率、收入)的影响有多大?10 = 改变游戏规则,1 = 可以忽略。
1
10
C
信心度
Confidence
你有多大把握这个实验会成功?基于数据、过往实验、类比案例。10 = 有大量证据支持,1 = 纯粹的直觉猜测。
1
10
E
易实现性
Ease
执行这个实验有多容易?考虑时间、工程资源、跨团队依赖。10 = 几天内可以完成,1 = 需要数月和多个团队。
1
10
示例评分表(按 ICE 分数排序)
实验想法
I 影响力
C 信心度
E 易实现
ICE 分数
优化注册流程第 3 步(移除可选字段)
8
9
9
648 #1
推荐计划(邀请好友得 30 天免费)
9
7
6
378 #2
首页 Hero Banner A/B 测试(新文案)
6
8
8
384 #2
邮件激活序列(7 天 onboarding drip)
7
6
7
294 #4
完整的 AI 智能推荐引擎重构
10
4
2
80 #6
社交登录(添加 Google/Apple 登录)
5
5
5
125 #5

注意第 5 行:「AI 推荐引擎重构」听起来影响力最大(10 分),但因为信心度低(4 分)、实现难度高(2 分),ICE 分数仅 80,排在最后。这正是 ICE 的价值——「听起来很重要」不等于「现在应该优先做」。

什么时候该用它?

ICE 是快速决策工具,专为实验性思维设计。当你面对一个想法清单,需要在有限资源下快速排出执行顺序时,它最有效。

🧪
增长实验周期排序
每周增长会议上,用 ICE 给所有提议的实验打分,只跑本周 ICE 最高的 2–3 个。快速、低政治、可量化。
🚀
早期产品快速迭代
产品初期资源极度有限,RICE 所需的 Reach 数据根本不存在。ICE 三个维度靠团队经验就可以打分,够用而不过度。
📊
功能 Backlog 快速梳理
Backlog 里有 50 个功能请求,季度规划前需要筛出 Top 10。ICE 评分会议 1 小时内完成筛选,比逐一讨论高效 10 倍。
🎯
OKR 关键结果执行排序
OKR 确定后,面对多个可能的执行路径,用 ICE 排出哪些打法先跑,哪些等第一批数据回来再决定。
💡
创意工作坊后的想法筛选
头脑风暴产出了 20 个想法,用 ICE 快速从创意发散过渡到行动选择,避免工作坊结束后什么都没有产出。
🔬
A/B 测试计划优先级
测试资源有限,哪个假设先测?ICE 帮你在「我感觉这个更重要」之外,建立一个所有人都能参与的评估过程。

GrowthHackers 用 ICE
从 0 到 9 万用户

ICE 不是一个书桌上的理论框架,它是 Sean Ellis 为了解决 GrowthHackers 自身增长问题而创造的工具。从 2012 年创立到 2015 年,这个框架驱动了平台从 0 到 90,000+ 注册用户的全过程。

每周,增长团队会产生 10–15 个实验想法(任何人都可以提),所有人对每个想法打 ICE 分,取平均值排序,只执行本周 ICE 最高的 Top 3。这个机制的关键不是分数本身,而是分歧触发对话:当有人给某个想法的 Confidence 打 3,另一个人打 8,这个分歧就值得深入讨论——为什么信心度差这么多?谁掌握了对方不知道的信息?

Dropbox
推荐计划 vs 首页重设计的 ICE 对决 · 2010
2009–2012
⚖️
两个增长想法的 ICE 对决
胜出方案
「给空间,得空间」推荐计划
邀请好友双方都获得额外存储空间,利用病毒式传播机制。
I: 9 C: 7 E: 6 = 378
落败方案
首页重新设计(新视觉 + 文案)
更新首页英雄区域,优化价值主张表达,提升访问转化率。
I: 6 C: 5 E: 8 = 240
推荐计划的评分逻辑
Impact=9:病毒式传播机制,每个新用户带来新用户,复利效应巨大
Confidence=7:Hotmail 的「PS: Get your free email」验证过类似机制的有效性
Ease=6:需要工程实现双向奖励逻辑,有一定复杂度但可在几周内完成
📈
推荐计划的实际结果
推荐计划推出后,Dropbox 在 15 个月内从 10 万用户增长至 400 万用户
直接注册量提升 60%,成为 Dropbox 增长史上最重要的单一实验
这个案例后来成为 ICE 框架最广被引用的验证——高 ICE 分数确实对应了高回报
40倍
用户增长(10 万 → 400 万,15 个月)
378 vs 240
ICE 分数准确预测了哪个实验更值得先跑
3年
GrowthHackers 用 ICE 驱动增长至 9 万+ 用户

ICE 失效的六个常见方式

ICE 的力量在于简单,但简单也带来了被误用的风险。以下是最常见的失效模式。

01
不要一个人单独打分——必须是团队共同评分。单独打分丧失了 ICE 最大的价值:分歧本身。当团队成员对同一个想法的 Confidence 分数差距超过 3 分,这个分歧一定值得 5 分钟的讨论。你不知道的信息,别人可能知道。
02
警惕锚定效应——先评分第一个想法会影响所有后续打分。让所有人同时提交分数(可以用便签或匿名投票工具),而不是逐一讨论。看到别人的分数前先给出自己的判断,然后再讨论分歧。
03
ICE 分数是讨论工具,不是最终判决。如果一个想法 ICE 分数是最高的,但整个团队都感到强烈不安,这种感受本身就是信息。分数不能替代判断,它只是让判断更有结构、更可讨论。
04
Confidence 必须基于证据,不是愿望。「我相信这个会成功」不是 Confidence 的来源。Confidence 的来源是:过往类似实验的结果、行业数据、用户研究发现、竞品案例。如果你找不到任何证据,Confidence 应该低于 5。
05
跑完实验后要回顾打分,更新你的评分能力。如果一个 ICE=400 的实验失败了,或者一个 ICE=120 的实验意外成功,都要复盘:哪个维度的判断出了偏差?这种校准让团队的打分越来越准确。
06
ICE 适合战术决策,不适合战略决策。「是否进入东南亚市场」「是否转向企业客户」这类 6 个月级别的战略押注,ICE 的「易实现性」维度失去意义,RICE、OKR 或 NOW-NEXT-LATER 更合适。ICE 是增长实验的工具,不是公司战略的工具。

增长黑客运动中诞生的极简优先级模型

ICE评分模型由增长黑客先驱Sean Ellis于2010年代初提出,最初用于解决增长团队面临的实验优先级难题。模型以Impact(影响力)、Confidence(信心度)、Ease(易执行性)三个维度的均值为依据,将复杂的优先级判断转化为可量化的数字,极大提升了高速迭代团队的决策效率。

2007
Sean Ellis提出"增长黑客"概念
Sean Ellis在Dropbox等硅谷公司担任增长顾问期间,开始系统化思考如何以低成本、高速度推动用户增长。他于2007年首次使用"Growth Hacker"一词,并着手构建一套可复制的增长实验体系。这一概念的提出为ICE模型的诞生提供了方法论土壤。
2012
ICE模型在GrowthHackers社区正式推广
Sean Ellis创立GrowthHackers社区后,将ICE评分作为增长实验优先级排序的核心工具进行推广。社区成员在实践中不断验证和完善这一模型,使其成为增长团队的标准流程之一。
2014
增长黑客方法论走向主流
随着《增长黑客》等著作的出版以及Facebook、Twitter等公司增长团队成功案例的曝光,ICE模型随增长黑客方法论一起被科技行业广泛接受。许多初创公司开始将ICE评分纳入日常产品迭代流程。
2015至今
衍生变体与工具集成
基于ICE模型,业界出现了多种变体,如加入Reach(触达范围)维度的RICE模型(Intercom团队提出)。各类产品管理工具如Aha!、Productboard也将ICE/RICE评分内置为优先级模块,进一步固化了这套简洁评分框架在产品管理领域的地位。

与这些工具搭配效果更好