1704198904
1704198905
信心：这个标准衡量的是想法提出者对于想法产生预期影响的信心。对于这个标准的评分不应基于主观臆测，而是要根据某种实证经验，不管是数据分析、行业基准、可查阅的案例研究，还是之前的试验经验。
1704198906
1704198907
1704198908
1704198909
1704198910
1704198911
1704198912
1704198913
1704198914
1704198915
如果试验是之前的一次成功试验的迭代，那么信心评分应当更高。这是一个不错的做法，增长黑客界通常称之为“双倍下注”（doubling down）。比如一项试验的内容是通过脸谱网上提供免费样品的广告吸引用户跳转到着陆页填写邮箱资料，这个做法为公司提供了很多新的潜在客户的邮箱地址。下一次你可能会尝试通过谷歌等其他渠道推广同一个着陆页。第一次试验时，因为你以为填写注册表可能会使很多人放弃申领样品，所以对于试验的信心值比较低，只打了4分。但是做下一次试验时，由于第一次试验的成功，你可能将信心值提高到8分。信心值很高也可能是因为了解到公司内或公司外的其他团队做过类似的成功试验。
1704198916
1704198917
1704198918
1704198919
1704198920
1704198921
1704198922
1704198923
1704198924
1704198925
简易性：简易性衡量的是进行一项试验所需投入的时间和资源。重新进行界面设计或是改进结账环节购物车的样式都是具有潜在高影响力的想法，但是这样的想法往往不容易落实，可能需要几周甚至几个月的准备时间。简易性得分不仅可以帮助增长团队认清一些不太现实的想法，也可以帮助他们在每一轮增长循环中发现一些“唾手可得”的试验。
1704198926
1704198927
1704198928
1704198929
1704198930
1704198931
1704198932
1704198933
1704198934
1704198935
在召开团队会议之前，增长负责人应查看各个想法的初始得分，他可能会发现想法提交者没有想到的一些问题。增长负责人可以基于他的过往经验以及其他团队成员的意见给出分数调整建议。但是，团队不应过分纠结分数调整。这个分数只是用来进行优先级的比较，不需要尽善尽美。如果团队成员浪费太多时间争论一项试验的影响力得分，那么增长会议很快就会陷入僵局。团队应把这一分数作为一个重要参考，而不是当作优先级排定的唯一依据。如果团队对于某个分数存疑，增长负责人应依据自己的最佳判断果断做出决定，以引导团队推进工作。
1704198936
1704198937
这一评分体系并非万无一失，测试结果也经常与预期不符。有些评分最低的试验结果反而产生了最好的效果。在GrowthHackers，我们曾做过一个简单试验，调整了网页上每周“最佳帖子”简报邮箱登记表的位置。这个登记表原本是在网站主页的底部，因为我们原以为需要给用户时间先浏览我们在首页上主推的最受欢迎的帖子，然后再决定是否登记邮箱地址以接收我们的每周简报。后来摩根提出了一个建议，即把登记邀请改到页面顶端，把它放在一个更显眼的位置。事实上，他本来并不认为这个调整能带来多大的变化，所以只打了4分。但是我们还是决定测试一下这个想法，这是因为基于工程师团队的反馈，这个试验比较容易开展，我们在简易性一栏给它打了9分。同时摩根有比较大的把握这个调整将能够使用户更容易看到登记邀请从而会在一定程度上增加登记量，于是在信心一栏打了8分。结果非常令人惊讶——登记量增加了7倍，远远超出了我们原本的预期。
1704198938
1704198939
讲述这个例子并不是要说明摩根能提出这个点子有多厉害，其实他也提过不少以失败而告终的点子。提出这个案例是为了说明我们对于自己想法的预期并不总是很准确，同时也说明不要轻易抛弃分数较低的想法。
1704198940
1704198941
虽然我们倾向于使用ICE评分，但是其他增长黑客也提出了其他评分体系。比如被誉为“转化率优化之父”的布莱恩·埃森伯格就提出了“TIR体系”，即time（时间）、impact（影响力）和resources（资源）。3另外一个体系是“PIE”，即potential（潜力）、importance（重要性）和ease（简易性）。4虽然不同的体系细节上可能存在差异，但是它们的总目标是一致的，即以量化的方式评估试验想法，帮助团队筛选不同试验选择、决定下一个试验内容。
1704198942
1704198943
经过评分缩小了选择范围之后，你手里的试验可能仍然超出了接下来一周所能完成的量。有些想法需要更长时间去准备，比如那些需要大量软件开发或设计工作的试验。对于这样的试验应当在咨询试验筹备直接参与人员之后设定一个具体的测试日期。如果筹备工作涉及软件开发，工程师和产品经理就应当为增长团队估算一个时间框架，而如果要测试一个新的获客渠道，市场团队就要负责为增长团队提供一个时间表做参考。
1704198944
1704198945
在当周无法启动的试验想法都应储存在储备库中。你可以从中选择一些用于接下来一周的试验，而保留其他想法日后使用。关键是团队应以时间和资源利用的最优化为目标安排他们的工作，专注于增长负责人选定的关注领域中最紧迫的需求。
1704198946
1704198947
让我们再回到食品商店App的案例中来看一看如何开展筛选过程。App团队的目标是增加每个用户创造的收入。在收集了一些点子之后，他们决定选择“初次下单优惠”和“把免运费政策信息放在更明显的位置”这两个影响力和简易性评分较高的想法进行测试（见表4–1）。
1704198948
1704198949
初次下单优惠试验很可能会交由营销人员负责，而免运费试验则交由产品设计师负责。
1704198950
1704198951
假设团队同时决定购物清单试验也值得一试，但由于这一功能的开发比较复杂，增长负责人可能会让产品经理询问产品团队的时间安排。获得了这一信息之后，增长团队就可以考虑设定试验启动时间了。
1704198952
1704198953
我们建议团队通过协作来进行试验选择。在增长会议召开前一天，增长负责人应通知团队查看想法储备库并从中选择他们认为最有潜力的想法（不一定只是新提交的想法，可能也包括已经在库里的想法）。这些想法将作为候选在增长会议上讨论，届时团队将共同决定在什么时间启动哪些试验。团队成员可以通过邮件对想法进行提名，或者如果系统允许的话，也可以在储备库中设置突出显示。例如，在GrowthHackers的“Projects”系统中，团队成员可以给想法加星标，加星之后想法就会进入单独的列表中，增长负责人可以查看并在会议上与成员展开讨论。为保证被提名想法的数量在可管理范围内，我们通常限制每个成员每周最多提出三个想法。
[
上一页 ]
[ :1.704198904e+09 ]
[
下一页 ]