mirror of
https://github.com/cheetahlou/CategoryResourceRepost.git
synced 2025-10-10 03:56:39 +08:00
77 lines
7.6 KiB
Markdown
77 lines
7.6 KiB
Markdown
<audio id="audio" title="10 | 你需要组建增长团队吗，应该如何组建呢？" controls="" preload="none"><source id="mp3" src="https://static001.geekbang.org/resource/audio/7f/73/7f6465c9bef542978e21e2b8714de273.mp3"></audio>
|
||
|
||
极客时间的专栏读者你好，我是邱岳。
|
||
|
||
之前的两次分享，我们谈到了在当前的行业环境下，“增长”可能面临的困境以及增长策略的核心。今天我们继续聊增长相关的话题，我们来谈谈增长团队的组织和实践。
|
||
|
||
有很多书和文章都会提到如何在公司中组建增长团队，包括如何设置组织结构以及增长团队包含什么角色等等。我自己并没有实际操盘过增长团队的组建，这方面的内容也是通过书和材料来了解的。
|
||
|
||
所以，这次分享的前半段我只是简单跟你转述一些书上的内容以及我的思考。然后着重分享如何基于现有的组织结构，从产品、运营甚至研发的角度，去理解和贯彻增长，协调不同角色，横向地组织一个没有编制的虚拟增长团队。
|
||
|
||
## 1. 增长团队的经典结构与搭建逻辑
|
||
|
||
增长团队的搭建通常分为“两个阶段”和“两条路径”。
|
||
|
||
“阶段”是指团队发展阶段，团队创建早期，规模相对比较小，团队中的成员身兼多职，不会建立专门的增长团队。这个阶段讲究全员关注增长，包括增长策略和指标，大家需要有机地将增长和产品的整体规划混在一起，并落地实施。
|
||
|
||
**随着团队增长，部门和人员的职责划分逐渐明确。用户从进入产品直到最后离开，这一路上不同阶段会有不同的人或团队来负责，而增长本身是需要策略贯穿始终的。**
|
||
|
||
可是，由于部门之间存在的缝隙以及权责分离，导致市场部的人不管产品，产品部的人不管技术，技术部的人不管运营。从而增长策略很难有始有终地从公司层面贯彻下去。这时，有一些公司会选择招聘专门的增长人员或组建增长团队。
|
||
|
||
这里增长团队编制也有两种典型的路径。
|
||
|
||
- 一种是独立增长团队，根据材料， Facebook 和 Uber 都采用了这样的设置，他们都有独立的增长部门和负责人，团队内的建制完整，有产品、技术、数据等等。
|
||
- 另一种则是不设独立增长部门，而是在现有产品部门中设置增长岗位，据称 Twitter 和 LinkedIn 等公司采用的是这样的方式。
|
||
|
||
独立团队的方式更容易完整地落实增长战略，搭建完善的增长迭代流程。但显而易见的是，将团队以此种方式分开，很容易导致增长团队与现有产品团队之间的隔阂和争论。
|
||
|
||
而将增长和产品团队混在一起的团队构建方式，更容易协调产品规划和优先级，也方便把增长的需求与核心产品价值做协调。
|
||
|
||
但这样做容易让增长相关的规划和设计缺乏体系，而且通常增长相关的需求优先级会低于业务，最终导致增长相关的需求支离破碎，增长这件事情也名存实亡。
|
||
|
||
关于这两种增长团队的构建方式，推荐一篇文章 [How Do You Choose the Best Growth Team Model? – The Startup – Medium](https://medium.com/swlh/how-do-you-choose-the-best-growth-team-model-632ad5a85be9) ，其中提到了不同团队对不同增长团队构建方式的实践和经验。
|
||
|
||
## 2. 在现有组织架构中的增长实践
|
||
|
||
构建增长团队通常需要由上而下的组织动作，对于大部分团队和公司来说，这个事情或许是可遇不可求的。所以对我们来说，更重要的则是在现有团队建制中，把增长的思路和策略落实下去。
|
||
|
||
### 2-1. 增长团队的角色
|
||
|
||
首先我们要弄清楚做增长所需要的职能角色。在许多增长相关的书中，很多专家都推荐以市场部为基础组建增长团队。这是由于市场部门负责的是用户进入我们产品的第一个环节，依次顺行下去，更容易形成完整的增长策略。
|
||
|
||
优秀的市场人员可遇不可求，而且有不少尚未成规模的公司可能还没有专门的市场部。在这样的情况下，通常是由运营来承担相应的职责。我认为一个虚拟的增长小组由运营来牵头可能会是一个不错的选择。
|
||
|
||
除此之外，还需要产品、设计和工程师，他们是增长策略的实施者。还有另外一个不可缺少的角色是数据分析。在增长体系中，最重要的东西就是数据，数据将会成为指导增长策略方向和验证增长效率的依据。
|
||
|
||
这并非意味着要做增长必须要凑齐这么多人，可能有的人可以扮演多种角色，也可能在不同阶段不需要所有人都投入进来，比如很多时候数据体系搭建完成后，产品经理或运营就可以进行一些基础的数据分析和监控。
|
||
|
||
在没有独立增长团队的前提下实践增长，我们需要发动和联合这些角色参与进来，有时候甚至需要用到他们的业余时间。
|
||
|
||
### 2-2. 协调增长策略的规划与产品规划
|
||
|
||
很多时候，从增长角度出发的规划和需求会与产品本身的需求难以融合，它会表现在两个方面。
|
||
|
||
**首先是从增长的角度希望去优化或者增加的功能，很可能与当前产品核心价值没有特别直接的关系。** 比如从增长的角度我们希望能做用户转介绍提成的功能，但这样的功能很可能淹没在无尽的业务需求中，久久等不到资源。
|
||
|
||
**另一种则是从增长角度出发的一些特性会对用户体验有所伤害。** 比如 Hotmail 在每封邮件结尾增加广告链接，从增长的角度来说非常成功，但它对用户来说确实是个有些侵入性的设计。
|
||
|
||
我的建议是根据节奏向两侧倾斜摆动，比如一个阶段内以增长为关键目标，当增长达成一定的成果后，再向产品核心价值倾斜，然后再回去关注增长。
|
||
|
||
比如我们在做 Readhub 的过程中，就会先重点关注信息质量和算法效率，达到某一个阶段后，再把资源倾斜到增长上，做一些传播和留存的功能，同时在这个过程中积累用户反馈和各种数据，等量开始有起色了，下一个阶段再来重点关注信息厚度和信息规模。
|
||
|
||
这就像是低头忙活一会儿，再抬头吆喝一会儿，然后再低头忙活，周而复始，产品的核心功能和增长相关的策略都能向前推进。这也是我个人更倾向于在现有团队内部做增长，而不是搭建单独增长团队的原因。
|
||
|
||
## 2-3. 一定要有实权负责人全力支持甚至直接参与
|
||
|
||
**在组织内实践增长的另一个关键因素，是一定要有实权负责人支持和参与。** 增长很难靠渐进式的方式取得成功，它需要比较宽松的试错和迭代环境。所以最好有足够级别或影响力的人参与或牵头，或者至少与他们达成充分的互信。
|
||
|
||
设想一下，如果从当前业务规划中抽调人手，连续投入几十人日做增长，但数据纹丝不动，这时要宣讲增长的意义以及逻辑，就显得缺乏说服力。这个时候唯一能撑住场面的就是权力或信任了。
|
||
|
||
## 3. 总结
|
||
|
||
好了，我们总结一下今天分享的内容，首先，我简单介绍了典型的增长团队编制，这部分内容我没有太多经验，所以只是浅尝辄止地跟你交流一些思考。接下来结合我自己的实践谈到怎样在当前组织内去推进增长，包括角色选择、协调规划和获得支持。
|
||
|
||
你所在的公司是否有独立的增长团队，你们又是如何实践增长的？欢迎在评论区中留言交流，今天的分享就到这里，谢谢你的收听，我们下次再见。
|
||
|
||
|