想要让你的产品在短期内实现指数级的增长，你可能需要组建一个发展团队帮你实现这一目标。那么，你要怎样为你的团队选择最佳发展模式呢?本文作者通过对20名来自不同公司的发展部主管的采访，向大家介绍了两种不同的发展模式。
我们采访了20位来自发展最快速的公司的主管们，比如Pinterest和FanDuel(一款幻想体育游戏)的主管，来回答这个重要的问题。
在长达30多小时的采访之后，我们弄清了一件事：团队选择正确的发展模式既可以解锁盈利大关，也会加强企业文化。
一个是独立模式(Independent Model)；另一个是功能模式(Functional Model)。如果你想去组建自己的发展型团队，这两个模式都是不错起跑姿势，“当游戏开局时，要按正确的布局玩儿”(Zack Onisko，创意市集网站Creative Market的首席发展官)。每个模式都要“更深入地理解自己团队的发展模式”(Mike Duboe，Tilt的发展官)，然后全力解锁盈利问题。
独立模式
总结
Uber和Facebook用的就是独立模式。这个模式主要有两个版本，如下：
在这两个版本中，都由一位发展部副总裁在带领团队。比如，Ed Baker就是Uber的发展部副总裁，直接向CEO Travis Kalanick汇报工作。Ed带领的发展团队由100多人组成，与产品、市场、工程、设计、数据部门的专家一起，共同研究令供求双方(指服务提供方司机和服务需求方乘客)用户数都增长的方法。
而且根据被采者提供的信息，Uber就是用这种模式提高了团队产品的生产和迭代速度，建立了很强的团队DNA。Uber很重视速度和迭代，他们的发展团队为此搭建了一个稳健的反馈机制，再将反馈体现在Uber的产品上。
反馈机制可以保证一个老用户群体可以发展出另一个新用户群体，这种情况经常发生在老用户的搜索、支付、推荐行为后。比如说，首次尝试Uber服务的乘客往往都是Uber的老用户推荐过来的，这就是推荐反馈的结果。而有的司机则是看了“成为Uber的司机”的广告，在此作用下成为了Uber的司机。两个案例中，不管的供方司机，还是需方乘客，都可以靠反馈机制通过老用户来创造新用户。
Uber发展团队的工作就是让这些反馈机制尽可能地提高他们的乘数效应。举例来说，乘数效应中的“乘数”在Uber的推荐反馈机制中是“10”。这个的意思是Uber通过线性手段(比如付费广告)获取到的乘客将会再创造10倍的新用户。如果团队通过付费广告可以得到1000名乘客的话，那这1000名乘客还会通过推荐(反馈机制)创造10000名新乘客。
这个乘数效应里的乘数越大，则Uber发展得越快。
独立模式中的冲突与解决方案
Casey Winters是Pinterest的产品发展部主管，他认为独立模式中的冲突是不可避免的。
当Pinterest采用独立模式时，发展部团队的数据都是很漂亮的上升态。曾保持着持续扩张的状态。而事实上，当发展团队亮出Pinterest的漂亮的增长数据时，其他团队却担心过快的增长是以牺牲广大的用户体验为代价换来的。
好比当发展团队为产品设计了一个用户注册界面，用户注册后才可以使用产品。这个步骤的确会显著地提升用户的活跃度，但同样也会带来一些忧虑。其他团队认为这个步骤让用户体验变糟了。然而最终数据会说话，会反击其他团队的直觉言论。
这种既要保证用户体验，又要维持数据增长的冲突是我们在独立模式中需要面对的最大挑战。
我们经常听到关于“是否用户的增长必然要牺牲用户体验”的辩论，“这会造成用户对平台失去信任。”Winters说，接着它又说“大家应该了解(也应该相信)发展团队会竭尽全力去为用户创造最佳用户体验的。”
你要怎样跨部门建立团队最基本的信任?
Casey针对上面的团队冲突问题，提出了一个建立信任的方法：让发展团队书面承诺自己不会为了增长数据漂亮而去牺牲用户体验。另一个被采访人也建议CEO可以保留这份承诺书，以此宣扬一种企业文化，同时也请产品发展部副总裁签订此协议。这种方法可以降低独立模式产生的冲突。
Invoice2Go发展部主管Naomi Ionita(前印象笔记的发展部主管)认为，发展部门的工作不可避免地会与产品部门的工作有所重叠。基于她领导这两个部门的经验，她解释道，如果员工所有的角色和责任都被明确定义，或者公司的产品及发展部主管有很强的工作沟通能力，那么冲突问题就可以避免。然后又会有新的问题：“信任、透明度和客观性。”
功能模式
总结
根据我们的采访显示，当发展部门的工作需要向功能部门主管(比如产品、工程等)回报时，其他部门的人就会相信产品的发展模式是正确可靠的。
Pinterest、Twitter、LinkedIn、Dropbox和BitTorrent就是使用的功能模式。
该模式之所以流行是因为其有如下三个优点：
功能部门主管(如产品、工程等等)决定发展计划
功能部门主管可以平衡增长和非增长计划
产品部副总裁常以功能部门主管的身份掌管发展部
我们来看下第三个优点是如何在实践中发挥作用的。
Pramod Sokke是BitTorrent的产品主管，直接在平台上接触所有的客户。他要负责BitTorrent的增长和非增长模式。这意味着Pramod必须同时为产品的增长和非增长绩效制定计划，同时为两组的绩效表现负责。BitTorrent发展团队以外的员工也很信任Pramod，因为他能用平衡发展的方式确保各部门在这场长跑中都能到达终点。
功能型模式中的冲突与解决方案
尽管如此，用户数增长与用户体验的冲突在功能模式下仍然存在。因为上文中提到的几个优点，所以这种冲突并不像在独立模式下那么明显。但之所以冲突还存在因为能够保证用户增长的措施往往与用户对产品的预期背道而驰。
这就是为什么我们的采访提倡纵向分析的原因。通过分析用户行为，我们可以看出用户的增长究竟是否会牺牲用户参与积极性。我们也会发现发展模式既可以保证用户数增长，也会提高用户的参与度。
我们还了解到功能模式最有效的情况是，其负责人对于增长数据全权负责，并认可产品是需要迭代和学习机制的。这样一来产品的发展蓝图就不会全部寄托在无根据的直觉上。
比如，Pramod就在产品上用了一个非常典型的数据驱动迭代的方法。Annabell Satterfield成为了他团队中唯一一个业绩有增长的项目经理，因为他们将分析数据和迭代这两个过程结合得很好。
Annabell解释说她的增长模式是数据驱动和产品迭代。这跟直觉没关系，而跟这一过程有关：观察数据(分别从质和量两方面分析)、制定出假定方案、推出测试方案和最小化可行产品、观察测试结果，判断是将此次实验性产品发布还是从新再来一遍学习过程。
我们假设如果数据驱动和产品迭代两个过程没有很好得结合，那么会有另一个潜在的冲突存在于功能模式下。
可以说Pramod是用非迭代的方法管理产品，而Annabell则用的是迭代的发展模式。Pramod可能市场要求Annabell的产品憋出个大招，这个过程大概需要6到12个月。Annabell也许会给Pramod放一把大招，但她也可能用数据驱动产品迭代的方法仅用数周或者数天的时间就证明这些大招都是一些烂招。所以憋大招会增加产品生产的成本，无论是从收入还是用户的角度看都是如此，Annabell如是说。
我们的一些采访对象认为解决冲突可以通过改变产品蓝图的方法。在我们上面假设的情况中，Pramod可能可以让两个赛道同时跑起来，而不是将所有产品的工作都压在一种模式上。其中一个赛道用于实践Pramod的非迭代方法，另一个赛道使用Annabell的迭代式模式。每个赛道都可以有他们独立的产品、工程师、设计资源以确保所有的工作都可以在预算内按时完成。
不管怎样，公司高层需要为了产品的发展，引入数据驱动迭代的思维模式。不然无论你怎样搭建你的发展部门，都终将失败。
全文总结
在软件主导世界的时代，产品数据的增长与产品本身有着千丝万缕的联系。因为我们不知道产品发展的重点在何方，也不知产品的增长点为何物。所以我们仍需观察时下的趋势现象，才能判断出最佳发展团队。
在我们采访的20位发展部主管中，都提到了最流行的两种模式：独立模式和功能模式。当你想组建你的发展团队时，这两种模式都是一个很好的开始。
独立模式可以加快产品的生产和迭代速度。然而，这样就会造成发展团队的工作透明度下降，造成公司内部的信任下降。而功能模式相对更加透明，让发展模式更加平衡。但在用户体验和用户增长之间的冲突仍在存在。
有趣的是，我们发现这两种模式没有造成结果上太大的差距。也就是说任何一种模式都没有一定好过另一种。
这是一个很关键的发现。
所以选择一个团队发展模式时，要考虑到企业文化、组织结构、战略调整可能会更好。不要去选择成长模式，而是去找合适的模式。
