最近在看一些增长的书籍，刚好有这部分内容，所幸就摘录出来和大家一起聊聊这个事情。
根据公司战略，确定增长的阶段性目标是什么；
结合行业特性，深入思考，从目标倒推实现路径和相应的增长项目；
根据项目思考组织保障，成立闭环团队或打破部门墙的紧耦合功能团队（FT，Feature Team）;
兼顾长期增长目标，提前思考如何跨越增长曲线，避免陷入“经理人窘境”；
在假设单个增长项目大概率会失败的前提下，设计、执行具体增长项目；
01 确定增长的阶段性目标
这个其实还是比较好理解的，做任何事情之前，我们都应该先去确定做这件事情的目标是什么。
如果没有目标，一方面会让我们对整个事情的重点缺乏判断和把握，这样往往在执行的过程中，会忘记最初是为何出发的，很容易导致执行的混乱和错位；另一方面，有了目标我们才能更好的衡量我们所做事情的过程和结果，到底是好还是不好，好在哪里，不好又不好在哪。
放到用户增长这件事上，阶段性的目标其实是类似「北极星指标」这样一个概念，就是在做增长之前，我们还是要先确定产品当前的北极星指标是什么，只有确立了北极星指标，我们才能更清楚地知道应该做什么、应该不做什么，更好地把有限的资源投放到更有用的地方去。
02 确定增长项目
当确立了增长目标后，这个时候要去思考的就是从目标倒推实现路径，这里其实就涉及到对核心目标的拆解。
我以公众号阅读量的增长来举例，如果要实现公众号阅读的增长，其实大方向来拆的话，可以分为站内（公众号内）阅读量和站外（公众号外）阅读量。
站内阅读本质就是你的公众号粉丝数乘以文章打开率，而站外阅读则包含比较多的渠道，例如微信内渠道（微信好友/群、朋友圈、看一看、搜索等），还包含微信外渠道（如一些第三方平台，如今日头条、B站、简书及一些垂直媒体等）。
这样就可以得到如下图所示的公式：
当我们得到这样一个公式之后，其实就有了具体的增长项目的方向和想法了，比如说我要提高我的站内阅读，我可能要想办法去提升我的公众号粉丝数和文章打开率了。
03 增长组织保障
在我之前做增长的经验里，其实都没有一个单独的增长团队去做支撑，大部分要么是产品自发发起的，要么是运营那边发起的一些增长项目。
整个的实施过程，虽然也算不上非常地流畅、顺利，但基本的增长迭代还是能保障的。
相信也有很多人是和我有一样的想法：组织保障是最容易的，不就是组建一个用户增长团队，去协调各种资源做增长项目，然后实现增长目标嘛！这种想法暴露了一个很严重的问题——实现用户增长的组织保障常常是最容易被忽略的。
最近一段时间，我对增长组织保障也越来越有感触，原因就在于我发现有时候我们的增长项目不能实现快速的迭代测试，由于我们的开发资源有限，大部分开发资源已经排期被安排做其他功能需求，放到增长这一块的资源就相对匮乏。
增长本身是需要通过快速地迭代去试错和发现机会的，如果没办法实现快速迭代测试，那么就无法形成增长势能。
所以，有条件的话最好是能成立一个专门的用户增长团队，这样对产品增长的快速迭代测试也能起到更好的效果。
04 增长曲线跨越
做用户增长，如果只是沿着同一条增长曲线发力，那么最终一定会走到死胡同，无法实现持续增长。本质上，这是一个探索第二增长曲线的话题。
也就是在第一增长曲线还没有走到尽头的情况下，我们需要提前去探索和寻找新的业务增长点，在主营业务下滑之前，新的业务就已经崭露头角甚至能给公司带来一定盈利，只有这样才能更好地避免陷入“经理人窘境”。
关于这个话题，我的经验也不是很多在这里就不继续赘述了。
05 增长项目设计与执行
这里蛮有意思的是，作者把增长项目分为这么几个类型：漏斗型增长、功能型增长、策略型增长、整合型增长。
什么是漏斗型增长呢？本质上来说，就是通过提升产品核心漏斗的转化率，来做的相关的增长项目。
AARRR模型可能是漏斗型增长里，最基本的方法论了，从获取用户、激发活跃、提升留存、增加收入、病毒传播几个方面系统阐述了如何做用户增长。比如我们平时做的提升注册转化率、提升下单转化率等等，都属于漏斗型增长的范畴。
功能型增长，则更偏向于产品驱动一些，是希望通过新增产品功能来实现某些指标的增长，比如很多的工具产品如wifi 万能钥匙，会在自己的产品内增加内容模块，这其实就是希望通过内容来提升用户的停留时长，以达到更好的商业变现。
但功能型增长，本身并不是那么好做，一般而言耗费的开发资源也比较多，而是否能带来增长也是一个很大的未知数，所以功能型增长最好是搭配策略型增长一起来做会效果较好。
那什么是策略型增长呢？作者也打了一个很形象的比喻，比如功能型增长就像一挺重机枪，不太容易被搬到其他地方，造出来摆在某个地点后，如果这个地点没有出现敌人，那我们好不容易造出来的武器就浪费了，有点像马其诺防线；但是如果把功能型增长和策略型增长相结合，就像把重机枪装在了越野车上，它会瞬间变成用户增长的大杀器。
一个会移动的“马其诺防线”，我们可以想象一下它的强大！
比如产品的push系统，就是很典型的策略型增长结合功能型增长的案例，本身push推送的开发是一个后台功能，我们的目的是希望通过push来提升产品的活跃和留存，但是光push推送开发出来不一定能实现我们的目标。
本身产品内不同用户对内容的偏好是不一样的，以及在不同时间打开内容的机率也是不一样的，是否能通过某些策略形成一定的用户标签或画像，给内容也打上相应的标签，这样推送是否会更有针对性一些，然后根据不断地测试迭代，来达到最佳的推送策略。
整合型增长，作者重点阐述地是整合线上和线下资源，我结合自己的理解，重新对「整合型增长」的理解，我觉得就是整合一切可以整合的资源，来达到我们的增长目标。
这里说的整合一切可以整合的资源，就包含线上、线上、部门内、部门外、公司内、公司外… 凡是有助于目标实现的资源，如果我们有能力进行触达和整合，都应该去做相应的整合。
为什么要做整合型增长，就是我们提到的增长项目大概率其实会失败的，为了应对这个问题，我们要不断寻找各种方法和资源来提升项目成功的概率，要想到每个环节可能都不会按照我们预想的情况发展。
作者：壹百度
来源：倒退集
支付宝扫一扫
微信扫一扫
