增长黑客之“道”——增长如何成为组织能力

引言#

前面一直在讨论增长本身：用户为什么行动，增长怎样持续，什么东西值得被放大，以及面对一个增长问题时应该怎样做判断。但真实工作里，即使这些事情都想清楚了，一个人也很难独立完成增长。原因并不复杂，用户经历的是一条完整的价值链路，公司内部却天然按照产品、运营、市场、技术、数据、商品、供应链等不同职能组织起来。用户不会在意一个问题属于哪个部门，他只会感受到这一次体验到底好不好；组织内部却需要把同一条链路拆成不同职责，再通过协作把它重新连接起来。

所以增长做到最后，一定会从个人能力走向组织能力。一个很强的增长负责人可以推动几个项目，也可能连续找到几个增长点，但如果所有问题都必须经过他本人，所有判断都依赖少数人的经验，这种能力就没留在组织里。成熟的状态不是公司里有几个特别会“做增长”的人，而是业务遇到问题时，更多人用相似的方式理解问题、做出判断，并对最终结果负责。

6.1 跨职能#

增长天然跨职能，根本原因不是增长工作特别复杂，而是增长结果发生在用户链路上，不在公司的组织架构里。市场可以把用户带进来，但用户进来以后能不能理解产品价值，还取决于产品和内容；产品可以优化购买路径，用户愿不愿意持续复购，还可能受商品、价格、履约和服务影响。每个团队都只能直接控制其中一部分，最终呈现出来的却是一个完整的业务结果。

组织里很容易出现一种情况：每个团队都完成了自己的任务，增长目标却没有完成。市场完成了新增，产品按时上线功能，运营执行了活动，技术这边也完成了开发，各自的过程指标看起来都没有问题。一个月以后回头看，新用户留存很差，订单没有持续，业务结果并没有改善。按照传统职责划分，每个团队甚至都可以证明自己已经把事情做完了：市场会说用户已经带来了，产品会说页面转化达到了目标，运营也可以证明活动执行没有问题。但“为什么这批用户没有留下”这个问题，可能刚好落在几个部门的边界之间，没有人负责到底。

很多增长问题恰恰发生在这些连接处。广告带来的用户与产品价值之间有没有对上，第一次体验与后续留存之间有没有接起来，前端订单增长与后端履约能力之间是不是匹配，这些问题很难被某一个职能单独解决。

所以跨职能的重点，不是让产品、运营、市场和技术多开几个会，也不是把不同岗位的人塞进一个叫“增长团队”的组织里，而是让原本分散的角色围绕同一个问题和同一个业务结果工作。专业分工仍然有必要，市场依然擅长渠道，产品依然要做好体验；运营理解用户和内容，技术对系统能力负责——这些都没有变。增长不要求所有人做同样的事，它要求统一的只有一件事：判断一件事情是否成功时，能不能超越自己的局部交付，回到用户和业务最终发生了什么。

6.2 增长负责人#

增长既然天然跨职能，增长负责人就很容易被误解成一个“什么都要懂、什么都要管”的超级岗位。沿着能力清单不断往上加，这个人最好懂产品、懂运营、懂市场，还得懂数据、实验方法和商业模式，最好连技术和供应链也能理解。最后似乎只有一个全能的人，才有资格对增长负责。真实工作里，我并不认同这种理解。增长负责人的价值不是替所有岗位把事情做掉，而是让不同岗位围绕同一个增长问题工作起来。

问题负责人意味着，即使参与的人不断变化，问题本身不能失去主人。新增下降，到底是渠道问题、用户质量问题，还是产品价值没有被理解；复购变差，是商品、服务还是用户结构发生了变化。增长负责人不一定亲自解决这些问题，但需要推动团队把表面的指标变化追到值得解决的地方。

连接者处理的是信息分散。市场知道哪些渠道成本低，却未必知道哪些用户长期价值高；产品能够看到用户在哪一步流失，却可能不了解这些用户此前被什么内容和承诺吸引进来；运营长期接触用户反馈，但这些反馈又未必能够及时进入产品和商品决策。很多时候，组织并不缺信息，缺的是把信息放在一起理解问题的人。

取舍者意味着接受资源始终有限。增长问题通常比团队能够解决的问题多，什么都做，最后什么都做不深。增长负责人需要不断回到当前限制业务的变量，判断什么应该先解决，什么可以暂时放下。

学习推动者要做的，是推动验证和学习。一个负责人如果只是不断给出答案，团队会越来越依赖他的经验；更成熟的方式，是把判断变成可以被事实检验的假设，让有效的东西留下，让无效的东西尽早停止。

所以优秀的增长负责人最终应该让自己没那么不可替代。所有增长问题都要由他分析，所有实验都等他设计，所有决策都经过他拍板，那增长依然只是一个人的能力。成果应该长成这样：产品开始主动追问业务结果，运营开始主动提出和验证假设。数据团队也不再只是提供报表，而是参与问题判断。到了这个阶段，增长才从“一个人会做”变成“组织逐渐会做”。

6.3 增长文化#

这种能力能不能留下来，最后会落在组织文化上。流程可以规定什么时候做实验评审，数据平台可以让团队看到更完整的信息，组织架构也可以把产品、运营、技术和数据放进同一个团队。但这些都无法完全回答一个更基础的问题：当事实和我们原来的判断不一致时，组织会怎么反应？

我现在判断一个团队有没有比较好的增长文化，反而不会先看它一年做了多少实验、有多少张数据看板，而会看三件更简单的事情：团队能不能承认自己不知道，能不能允许事实推翻原来的判断，以及一次工作结束以后，有没有留下下一次可以继续使用的东西。

第一件事听起来简单，做起来不容易。增长天然发生在不确定性里，如果一个团队习惯在项目一开始就要求负责人给出确定答案，很多假设最后就会被包装成结论。能够持续学习的团队，需要允许一句很普通的话出现：“我们现在还不知道，但可以先验证。”

第二件事更难。大家都愿意说自己尊重数据，但如果数据否定的是自己坚持了很久的方案，或者实验结果和管理者最初的判断相反，团队是否真的愿意改变决定，才更能说明问题。增长文化里那句“允许失败，不允许不验证”，重点不在鼓励失败，在允许事实比经验、职级和面子更重要。

第三件事决定了组织有没有复利。一项工作结束以后，留下来的不应该只有一个项目结果。一次成功可以留下可复用的方法，一次失败可以排除错误假设；用户反馈能改变下一次产品判断，数据建设也可以让后面的分析更快。半年做了很多项目，最后团队仍然说不清什么有效、什么无效、为什么，那么工作量再大，也很难形成组织能力。

实验文化、数据文化、用户文化和迭代文化，最终都可以回到这三件事上。它们不是几套彼此独立的制度，而是在帮助组织形成一种习惯：面对不确定的问题，不急着证明谁是对的，而是尽量更快接近事实，并让每一次行动都增加一点下一次解决问题的能力。

6.4 职责边界#

增长需要跨职能，但跨职能不等于所有事情都是增长的事，这是增长团队很容易走到的另一个极端。一开始成立增长团队，是希望有一群人能够跨过部门边界解决问题；时间久了以后，却可能变成哪里数据不好就找增长，哪个项目遇到困难就让增长团队救火。增长团队慢慢成为一个“特殊问题处理小组”，每天处理紧急需求，却挤不出时间理解增长问题。

有些问题本来就应该由正常的业务职责解决。商品竞争力下降，首先是商品问题；系统频繁故障导致用户流失，首先应该解决产品和技术稳定性。履约能力跟不上订单增长，那就是后端能力没跟上，优先级排在前面。如果因为这些问题最终都会影响增长，就把它们全部交给增长团队，只会让正常的组织责任变得模糊。

商业战略也是一样。增长可以帮助验证战略假设，却不能代替管理层回答企业到底服务谁、依靠什么建立长期优势，以及市场发生变化以后应该往哪里走。增长擅长的是在相对明确的方向里寻找问题、验证变量和提高效率，并不是替组织解决所有尚未定义清楚的问题。因此，增长团队需要跨过职责边界看问题，却不应该把所有职责都接到自己身上。成熟的增长组织，不是拥有一个特别强的救火队，而是业务团队本身也具备基本的增长意识和判断能力，很多问题能够在原来的职责范围内被发现和解决，确实需要跨职能协同的问题再由增长机制把大家连接起来。

增长需要跨职能，但不能成为正常组织责任的替代品。

6.5 增长伦理#

还有一条比职责边界更重要的线：即使一个方法能够让数据上涨，也不意味着它就值得做。增长会大量涉及用户心理和行为，这天然带来一种诱惑：只要一个设计能够让用户更容易完成我们期待的动作，它似乎就可以被实验结果证明是“有效的”。默认勾选可能提高转化率，复杂的取消流程可能降低短期流失。虚假的库存紧张、永远不会结束的倒计时，也会推动一部分用户更快下单。但数据只能证明行为发生了变化，不能替我们判断这种变化是不是合理。一个用户点击得更多、退出得更少，并不自动意味着他获得了更多价值；有时候，增长的短期收益恰恰来自用户没有充分理解规则，或者退出成本被人为提高。

之前讨论用户行为时，我们已经留下了一条基本原则：心理机制应该帮助用户更容易理解真实价值，而不是帮助企业更有效地操纵用户。到了组织层面，这条边界还需要再往前一步，因为危险的往往不是某个人故意想欺骗用户，而是整个指标体系逐渐把团队推向了只看转化、不看代价。如果团队只奖励注册率、支付率和续费率，却不看投诉、主动取消、长期留存和用户信任，很多短期有效的设计自然会不断出现。局部数据更漂亮，用户和产品之间的关系却可能在一点点被消耗。

我自己会用两个问题帮助判断这条边界：如果用户完全知道我们正在做什么，他还会认为这个设计是合理的吗？我们是在帮助用户更容易获得真实价值，还是只是在让用户更容易做出对企业有利、对自己未必有利的行为？

这两个问题未必能解决所有伦理争议，却足以帮助团队识别很多明显的问题。真实的优惠到期，经得起这样的判断；一个永远不会结束的“最后十分钟”，很难。根据用户需求做推荐，是帮助降低搜索成本；故意隐藏退出入口，则是在利用信息差增加离开的难度。用户信任是一种很慢才能建立、却很容易被消耗的资产。更麻烦的是，增长收益通常马上出现在报表里，信任损失却可能几个月以后才通过投诉、流失、口碑和品牌认知体现出来。如果组织只看很短的时间窗口，就很容易做出账面正确、长期却昂贵的选择。增长能力越强，这条边界反而越重要。工具越有效、执行越快，错误增长被放大的速度也越快。

6.6 解决问题的方式#

写到这里，再回头看“增长”这个词，我反而觉得它没有刚开始那么重要了。我们最初容易被增长外面的那些东西吸引：投放、裂变、转化、留存、A/B 测试、增长模型和各种增长技巧。但把这些东西放回业务以后，会发现增长最终还是一些很朴素的判断：产品有没有真实价值，用户为什么行动，什么东西值得被放大，业务现在卡在哪里，我们又应该怎样验证自己的判断。

当这些问题需要跨越不同职能才能解决时，增长才进一步变成组织问题。一个成熟的增长组织，并不是每个人都成为增长专家，也不是所有团队都开始追同一套增长指标。产品仍然有产品的专业，运营仍然有运营的职责，市场、技术、商品和供应链也不会因此失去自己的边界。发生变化的是，大家开始更习惯从最终用户和业务结果出发理解自己的工作，也更愿意把判断变成可以验证的假设，并接受事实可能推翻原来的答案。

如果这种工作方式只能存在于一个增长负责人身上，它只是个人经验；当更多人开始用类似的方法解决问题，它才成为组织能力。增长不是你要做的事情，而是你做事情的方式。它不是某个季度突然启动的一场运动，也不只是某一个岗位才需要掌握的专业技能。对产品、运营、市场，以及任何正在对业务结果负责的人来说，所谓增长，最终无非是从问题出发，理解真实用户价值，看清系统里的连接和约束，用有限资源找到最值得改变的地方，再让事实不断修正自己的判断。这些事情做得足够久以后，增长就不再属于某一个团队，而会慢慢变成一个组织解决问题的习惯。