CategoryResourceRepost/极客时间专栏/邱岳的产品实战/模块一：增长你的产品：一款产品的诞生与增长/14 | 实战增长，我们要知道哪些事儿？.md

<audio id="audio" title="14 | 实战增长，我们要知道哪些事儿？" controls="" preload="none"><source id="mp3" src="https://static001.geekbang.org/resource/audio/dd/49/dd5564302df0460237b5028dce780049.mp3"></audio>

极客时间的专栏读者你好，我是邱岳。

上周的分享我们聊到了增长的过程，也就是分析数据并收集洞察、形成试验想法、排定试验优先级、运行试验，再回到分析阶段审视试验结果并进行下一步行动。

如此往复，不断循环，就可以推动产品和运营策略上的动态迭代，揪出问题，从而找到有效的解决方案。

寻找成功的增长策略是一个以量取胜的过程，虽然我们都羡慕那些投入产出比惊人的巧思妙想，但真正操作的时候还是要回归现实，脚踏实地。如果我们多读一点相关资料，会发现那些鼎鼎有名的增长策略背后通常都有大量的试验和失败。

这次内容，我不打算说很多方法或套路的东西，而是想分享在增长实践中做事情的心态和原则。

## 1.每次开五枪，每五枪命中一枪

首先我想说的就是：要对策略的失败有预期。这一点不仅仅与增长相关，所有的产品功能迭代都有可能无法达成预期。即便是顶级的产品经理，也很难保证自己的每个设计都例无虚发。

我经常跟团队的同事说，不论是产品功能还是运营策略，我们努力的目标是**每开五枪可以命中一枪，然后想办法加快我们开火的频率。**

所谓开五枪命中一枪的意思是，我们会针对同一个目标，通过不断的观察和思考，试验一系列策略。比如某个产品规划的阶段性目标是提高用户留存数据，那我们可能会尝试做推送，做内容预告，做订阅或预约等等。

这些策略都是通过上次分享提到的增长过程提出的，在设计和推演中，虽然我们会对投入开发的方案有一定的信心，但绝不会希望每个策略都能产生显著的效果，而是每尝试五个策略能有一个特别有效。

我跟不少人交流过这个比例，客观地来看，如果真的能够保持长期稳定的“打五中一”，已经算是一个非常出色的水平了。

但是有趣的是，虽然我们知道产品规划设计是有成功率的，可是每当尝试失败的时候还是会沮丧，也会承担压力，影响信心。尤其是在每次策略尝试之前，有不少产品经理会习惯性拍胸脯表达一下信心（通常是为了争取资源），久而久之，反倒影响了团队内的信任。

所以我觉得需要在团队中提前有类似的沟通，让大家意识到试验过程中的失败是产品增长和迭代中的常态。我们还是保持健康的期望管理。况且失败的尝试并非一无是处，它能够帮助我们验证判断和假设，修正方向。

## 2.提高尝试的成功率、准确率与效率

**我们不能过分纠结于错误，而是要想办法提高尝试的成功率。** 我们可以提高对产品和用户的理解，除了最基本的通过各种用户研究、用户干预来了解他们之外，在不断地策略尝试中积累用户感觉也很重要，一个产品经理负责某条产品线久了之后，会有产生一些没来由的直觉，当遇到一些复杂而难以权衡的选择困境时，依赖这些直觉可能也是一种没有选择的选择。

心理学家 Gerd Gigerenzer 提出过一个有趣的关闭理性，诉诸直觉的方法：就是扔个硬币，当硬币脱手抛向空中时，你很可能会本能地期待某一面向上，这就是你的直觉给出的答案。

另外，我们也要想办法不断提高自己的专业判断和经验，我们在招聘和组建团队时经常会对人员经验有要求，背后的诉求就是**希望利用个人经验避开错误提高效率。**

我有一次有机会跟一位非常优秀的测试工程师聊天，我问他好的测试工程师和一般的有什么差别，他告诉我其实执行测试的时候其实没什么差别，好的测试工程师之所以能又快又稳，是因为他们更擅长找出可能出问题的用例和流程。

他给我举例子，同样一个产品流程，让一个好 QA 和一般的 QA 各选三个用例做测试，好 QA 挑的三个用例可能都能测出 Bug，而那个一般的 QA 选出来的用例测完可能都是好的。所以你看好 QA 测一天测完了，上线也没什么问题，一般的 QA 得全覆盖测三天，测完上线还可能出问题。

其实产品经理也一样，**作为一个专业人士，他的过人之处很可能并不在于快，而在于准。**

除此之外，还有一点就是要提高尝试的速度，刚才说尝试五次命中一次，之所以选择五这个数字，是因为假设迭代效率足够高，每天都能有发布，那就意味着整个团队每周能够交付一个有效策略。

比如我们从外面看阿里，觉得好像经常能把事情做对。除了阿里内部有很多经验丰富能力过人的专家之外，还有一个重要原因就是单位时间里，他们能比别人做出更多的尝试。

这其中的原因除了迭代效率高以外，就是被拉长的工作时长。我看到在阿里工作的老同事们，即便已经位高权重，依然加班很厉害。他们跟我开玩笑说要取得成就，总是需要犯一定数量的错误，他们多加加班，就是为了尽快把犯错的指标完成。

有句鸡汤是这么说的：如果你想走得快，就一人独行；如果你想走得远，必须结伴而行；如果你想走得又快又远，欢迎来阿里，会有一群人跟你结伴 996 前行。

## 3.在设计方案的时候，要带着下线的准备

最后，说到试错，还有一个需要解决的问题，就是一旦我们发现错了，如何处理“后事”。如果你是通过完整的 AB 测试或灰度发布框架做的试验，通常只需要简单地下掉不灵的试验方案即可。

可是如果是一个已经介入流程内的功能，应当怎么处理呢？假如频繁地更改流程，用户可能会感到强烈的不稳定，但如果不及时下掉无效的试验方案，又会让产品变得越来越臃肿。

这里没有什么放之四海皆准的方法，但却可以提醒大家一件事情，就是在设计方案的时候，要带着下线的准备。

我们团队的产品经理和设计是在做设计的时候，大家经常会互相提醒一句，“这么设计，以后好不好关”，为尝试失败做好准备。比如我们做红包抽奖的功能，上线之前就先要考虑万一需要关停，如何跟用户做余额的结算，有没有办法主动给用户退掉余额，还没有完成开奖的红包抽奖能不能正常处理掉等等。

试验中的功能最好不要插入主流程中间，可以先放在分支流程里，比如浮出一个气泡，或摆一个扩展按钮，而不是变成一个必经的步骤。如果这样的方式用户依然有转化，数据也比较好看，再考虑做成流程的一部分。

总之，我们在做新东西之前，先在脑子里想好它如果不成功，怎么妥善安置，听起来有点缺乏信心，不大吉利，但其实放到足够长的产品周期去看，这是最好的方式——**向最好的结果努力，往最坏的情况打算。**

## 总结

这次分享的内容到这里就要结束了，我们从增长过程中的试错出发，说到我们要对策略的成功率有正确的预期，同时要通过加强用户理解以及自身的经验和专业素养提高策略试验的成功率，或者通过更快的迭代频率来缩短试验周期，最后有提到在产品设计和策略试验的过程中，应当提前安排好“后事”。

下一次分享，我想跟你聊一下我认为在增长迭代的过程中一个非常重要的能力，然后会根据 AARRR 的各个阶段来分享一些经验和方法，希望对你有所帮助。

欢迎你就试错和迭代的话题留言讨论，我们今天的内容就到这里，感谢你的收听，我们下次再见。