透析Uber，Facebook，linkedin的Growth-Team架构

GrowthHacking并不是一个人的工作，而是一个团队，我们一起来看看硅谷各公司的Growth-Team是如何构成的。...



前几天Uber透露的消息中，中国区的订单量占到30%（机审筛选刷单后），Uber在近一年的时间内在全球疯狂扩张，用户增长的速度令人惊讶。被大家所熟知的一些GrowthHacker大拿也先后加入Uber，疯狂增长的背后也Uber Growthteam的支撑。我们一起来看一下，Uber，Facebook，Pinterest等，他们的Growth team架构都是怎样构成的。

最近，Andrew Mdnnes在完成了对20位Growth leads，超过30小时的采访后得出一个结论：choosing the right growth team model not only unlocks growth, butalso strengthens culture.看上去觉得不可思议，但在了解了Growth-Team的架构后，也许也就不那么难以理解了。

在硅谷，搭建Growth-Team时，各公司有自己的不同的理解与需求，虽然细节上不尽相同，但是在整体架构上都有趋同性。主要分为以下两类：

独立增长团队——Uber，Facebook采用的架构

协同增长团队——Twitter，Linkedin，Dropbox,Pinterest采用的架构

独立增长团队：

我们从两个维度，将这种架构进行划分：

维度一：按照流程与功能划分



维度二：按照增长维度划分



独立增长团队是Uber和Facebook采用的Growth-Team架构，这也是大多数公司采用的架构。在这样的架构下，由负责Growth的VP组建独立的Growth-Team并向CEO直接汇报，正如Uber的Growth VP Ed Baker直接向Travis Kalanick汇报一样。在这样的架构中，Growth-Team除了解决本身的增长需求之外，同时还会参与到产品、运营等其它部门的支持中。

Uber用这样的架构组建了一个以速度和迭代为团队DNA的绞肉机一般的Growth-Team，不断的反复测试，得到反馈之后快速迭代。因为Uber允许Growth-Team在产品中构建各类的反馈闭环（feedback loop），在这样的机制下，任何一个时间的任何一个事件，都可能成为Uber运营增长的契机。（相信大家都还记得，上海暴雨Uber 40分钟将车变船的故事）

这种各类小闭环，还能帮助产品从一批人扩展到另外一批人，而触发这个事件的则可能是搜索、付款或者推荐机制，也就是能够快速的形成网络效应。比如Uber的优惠乘车码，大多数用户第一次使用Uber就是由这个优惠码的推荐机制开始的，这个推荐机制就是一个很小很简单，但是非常有效的反馈闭环。

Uber的Growth-Team就是使这些各类反馈闭环尽可能的强劲有效，从而达到多倍效应。比如，通过付费广告加入Uber的司机有1000人，那么通过推荐闭环放大后，会由这1000人带来额外的10000人成为Uber的司机，这就是Uber的司机推荐闭环的10倍效应。

多倍效应越强，Uber增长越快。

独立增长团队的架构反应快速且高效，但是这个架构并不适用于所有产品，这样的情况就出现在了Pinterest身上。

最初Pinterest的Growth-Team选择了独立增长团队架构进行组建，在组建的初期，团队规模增长迅速，同时对数据监测的维度也急剧上升。导致产品team忙于处理这些需求难以抽身，结果使得用户体验付出了昂贵的代价。比如Growth-Team提出了新的注册流程以提升激活率，其它Team可能会觉得新的方案的用户体验并不理想，而数据Team根据就不管这些，只顾提出自己的数据打点需求。

处理好Growth-Team急速增长的数据维度需求与产品Team在工程上用户体验的要求之间的矛盾，是Pinterest采用独立增长团队架构的时候面对的主要问题。

产品优先和增长优先不可避免地存在冲突，在选择独立增长团队架构时，如何处理好Growth-Team和其它各Team之间的矛盾，会是这个架构面临的核心问题。通常的做法是让各个Team之间达成一定的协议，比如Growth-Team妥协承诺不会要求尝试任何有损用户体验的数据维度需求。这样的协议最好由CEO和各个Team的VP来协商达成，因为通常CEO代表着公司的文化，而这种文化应该由CEO和VP一同传递下去。同时负责Growth-Team的VP，最好有个好人缘，能够缓解与各个Team之间的矛盾。

协同增长团队

根据一个在采用协同增长团队架构的公司工作Growth Hacker说，当公司采用这样的增长团队架构的时候，其它各个Team会认为，增长团队所提的数据维度需求，“走在正确的路上”。

Pinterest，Dropbox，Twitter，Linkedin等采用协同增长团队架构



在协同增长团队架构中，不会设立专门负责Growth的VP，可能由负责产品、技术、营销的VP来组建增长团队。这样的架构被广泛采用，具备三个优势：

1. 负责增长团队的leader决定增长需求的数据维度的优先级；

2. 负责增长团队的leader平衡增长优先或是非增长优先（如产品优先，技术优先）的矛盾；

3. 通常由负责产品的VP组建Growth-Team；

我们来举例说明

Pramod Sokke是BitTorrent负责平台所有产品的leader，他负责所有增长与非增长的数据维度需求优先级评估。Pramod会为产品设立包括增长与非增长的roadmap，同时制定相应的KPI。尽管如此，增长团队与其它团队的矛盾依然存在，虽然不如独立增长团队那样明显。一部分增长团队的“Growth Geek”依然会对其它团队“所谓的用户体验”产生本能的排斥。

在这样的架构中，Growth-Team的数据维度需求会更多偏向于数据深度而非数据广度一些，一方面Growth-Team的产出不仅仅局限于获取新用户，同时对促活，拉长有效使用时长等都有很好的效果。这样不仅仅使得产品更加健康，同时也会缓和各个Team之间的矛盾。

当协同增长团队架构中的成员是严格的数据驱动，并且认为产品需要快速迭代而非设定一个个大的产品节点会更加有效时，这样的架构会发挥最大的效能。

假使Growth-Team并非数据驱动，或者并非快速迭代时，负责Growth-Team的leader可能会要求设定一个6-12月的输出节点KPI，而通常情况下，这个节点KPI在数周之后的测试结果中可能就将被推翻。6-12个月的节点设置方法，适用于预算控制，媒体采购或者盈利，但是并不适用于增长。

无论如何，协同增长架构需要一名严格数据驱动，并且使用快速迭代思想来实现增长的leader来领导Team，否则效率将大打折扣。

结语

增长，是一件交织在线上产品和我们现实生活之间的问题，我们很难知道增长何时开始，产品何时被抛弃。GrowthHacker在国内今年才被真正意义的全面提及，选择何种适合于公司的增长团队架构仍然是具备挑战性的。

上面是两种目前被广泛采用的增长团队架构：

独立增长团队架构具备快速高效的优势，但是由于增长数据维度需求并不透明，往往会引起其它团队的不信任或怀疑；

协同增长团队架构使增长数据维度需求更加透明，各个团队之间的摩擦也更少，但是反应速度与效率都会相应降低；

这两种架构的最终输出结果都大致相同，没有哪一种架构优于哪一种，选择一个更适合于你团队DNA的架构即可。

Facetalk是一个专注于创业团队用户增长问题的公众号，会定期分享国内外可实操的Growth Hacking的经验给创业者。同时我们也会定期举行“CEO + GrowthHacker”的线下活动，输出增长实操经验。

欢迎关注Facetalk，创业艰难，愿我们齐民协力！

    关注 FaceTalk