Uber、Facebook，是怎样为团队选择最佳发展模式的？

我们采访了Pinterest和Fanduel(幻想体育游戏)等20位发展最快的公司主管来回答这个重要问题。经过30多个小时的采访，我们发现团队选择正确的发展模式不仅可以解锁利润大关，还可以加强企业文化。在我们的采访中，有两种流行的团队发展模式。一是独立模式(IndependentModel)；另一种是功能模式(FunctionalModel)。如果你想建立自己的发展团队，这两种模式都是很好的起跑姿势，“当游戏开始时，按照正确的布局玩”(ZackOnisko，CreativeMarket创意市场网站首席发展官)。每一种模式都要“对自己团队的发展模式有更深入的了解”(MikeDuboe，Tilt的发展官)，然后尽力解锁利润问题。总结Uber和Facebook的独立模式是独立模式。这个模型主要有两个版本，如下:在这两个版本中，一个开发部副总裁带领团队。比如Edbaker就是Uber发展部副总裁，直接向CEOTraviskalanick汇报工作。Ed领导的开发团队由100多人组成。与产品、市场、工程、设计和数据部门的专家一起，共同研究了增加供需用户数量的方法。而且根据被采者提供的信息，优步利用这种模式提高了团队产品的生产和迭代速度，建立了强大的团队DNA。优步非常重视速度和迭代，他们的开发团队为此建立了稳定的反馈机制，然后在优步的产品上反映反馈。反馈机制可以确保一个老用户群体能够发展出另一个新用户群体，这通常发生在老用户的搜索、支付和推荐之后。例如，第一次尝试优步服务的乘客往往是优步老用户推荐的，这就是推荐反馈的结果。而有的司机则是看着“成为Uber的司机”的广告，在这个角色下成为Uber的司机。在这两种情况下，供应商司机和需方乘客都可以通过反馈机制通过老用户创建新用户。优步发展团队的工作是让这些反馈机制尽可能提高乘数效应。例如，乘数效应中的“乘数”是Uber推荐反馈机制中的“10”。这意味着优步通过线性手段(如付费广告)获得的乘客将创造新用户的10倍。如果团队可以通过付费广告获得1万名乘客，那么1万名乘客也会通过推荐(反馈机制)创造1万名新乘客。乘数效应中的乘数越大，Uber发展得越快。CaseyWinters是Pinterest产品开发部的主管，他认为独立模式中的冲突是不可避免的。当Pinterest采用独立模式时，开发部队的数据都是漂亮的上升态。保持持续扩张的状态。事实上，当开发团队展示Pinterest的美丽增长数据时，其他团队担心过快的增长是以牺牲大多数用户体验为代价的。例如，当开发团队为产品设计用户注册界面时，用户可以在注册后使用产品。这一步确实会显著提高用户的活动性，但也会带来一些担忧。其他团队认为这一步让用户体验更糟。然而，最终的数据会说话，会反击其他团队的直觉言论。我们在独立模式下需要面对的最大挑战是保证用户体验和维持数据增长的冲突。我们经常听到关于“用户增长是否必须牺牲用户体验”的辩论，“这将导致用户对平台失去信任。Winters说：“每个人都应该理解（也应该相信）开发团队将尽最大努力为用户创造最佳的用户体验。如何在开发团队和其他团队之间建立信任，如何在跨部门建立团队最基本的信任？Casey就上述团队冲突提出了建立信任的方法：让开发团队书面承诺不会牺牲用户体验来增加美丽的数据。另一位受访者还建议，首席执行官可以保留这一承诺，以促进一种企业文化，并要求产品开发部副总裁签署该协议。这种方法可以减少独立模式产生的冲突。Naomiionita(Invoice2Go开发部主任)认为，开发部的工作将不可避免地与产品部的工作重叠。基于她领导这两个部门的经验，她解释说，如果明确定义了员工的所有角色和责任，或者公司的产品和开发部门主管有很强的工作沟通能力，就可以避免冲突。然后就会出现新的问题:“信任、透明度和客观性。根据我们的采访，当开发部门的工作需要回报功能部门主管（如产品、工程等）时，其他部门的人会相信产品的开发模式是正确和可靠的。Pinterest、Twitter、LinkedIn、使用的功能模式是Dropbox和Bittorent。该模型之所以流行，是因为它有以下三个优点：功能部门主管（如产品、工程等）决定开发计划。功能部门主管可以平衡增长，非增长计划产品部副总裁经常作为功能部门主管负责开发部门。让我们来看看第三个优势是如何在实践中发挥作用的。Pramodsoke是Bittorent的产品主管，直接接触平台上的所有客户。他负责Bittorent的增长和非增长模式。这意味着Pramod必须同时为产品的增长和非增长性能制定计划，并对两组的性能负责。Bittorent开发团队以外的员工也信任Pramod，因为他可以通过平衡开发来确保所有部门都能在这场长跑中到达终点。尽管如此，在功能模式下，用户数量增长与用户体验之间的冲突仍然存在。由于上述优点，这种冲突并不像独立模式下那么明显。然而，冲突仍然存在，因为保证用户增长的措施往往与用户对产品的预期背道而驰。这就是为什么我们的采访提倡纵向分析。通过对用户行为的分析，我们可以看到用户的增长是否会牺牲用户参与的热情。我们还会发现，开发模式不仅可以保证用户数量的增加，还可以提高用户的参与度。我们还了解到，功能模式最有效的情况是，其负责人完全负责增长数据，并承认产品需要迭代和学习机制。这样，产品的发展蓝图就不会完全寄托在无根据的直觉上。例如，Pramod在产品中使用了一种非常典型的数据驱动迭代方法。Annabelsaterfield成为他团队中唯一一位业绩增长的项目经理，因为他们将分析数据和迭代结合得很好。Annabell解释说，她的增长模式是数据驱动和产品迭代。这与直觉无关，与这个过程有关：观察数据（分别从质量和数量分析）、制定假设计划，推出测试计划，最小化可行产品，观察测试结果，判断是发布实验产品还是重新学习过程。假设数据驱动和产品迭代过程没有很好的结合，功能模式下会有另一个潜在的冲突。Pramod可以说是以非迭代的方式对产品进行管理，而Annabell则采用迭代开发模式。Pramod市场可能会要求Anabell的产品退出一个大动作，这个过程大约需要6到12个月。Annabell可能会给Pramod一个大动作，但她也可能会用数据驱动产品迭代，只需几周或几天就证明这些大动作是坏动作。因此，无论从收入还是用户的角度来看，憋大招都会增加产品生产成本，Anabell说。我们的一些受访者认为，通过改变产品蓝图，可以解决冲突。在我们上面假设的情况下，Pramod可能会让两条轨道同时运行，而不是把所有产品的工作都放在同一个模式上。其中一条用于实践Pramod的非迭代方法，另一条用于Anabell的迭代模式。每条轨道都有自己独立的产品、工程师和设计资源，以确保所有工作都能在预算内按时完成。无论如何，公司高管都需要引入数据驱动迭代的思维模式来开发产品。否则，无论你如何建立你的发展部门，你最终都会失败。在软件主导世界的时代，产品数据的增长与产品本身密不可分。因为我们不知道产品开发的重点在哪里，也不知道产品的增长点是什么。因此，为了判断最佳的发展团队，我们仍然需要观察当前的趋势现象。在我们采访的20位发展部长中，提到了两种最流行的模式：独立模式和功能模式。当你想组建你的发展团队时，这两种模式都是一个很好的开始。独立模式可以加快产品的生产和迭代。然而，这将降低开发团队的工作透明度和公司内部的信任度。而且功能模式比较透明，使发展模式更加平衡。然而，用户体验与用户增长之间的冲突仍然存在。有趣的是，我们发现这两种模式在结果上没有太大的差距。也就是说，任何模式都不一定比另一种模式好。这是一个关键的发现。因此，在选择团队发展模式时，最好考虑企业文化、组织结构和战略调整。不要选择成长模式，而是找到合适的模式。选择最能解决你的“团队DNA”冲突的模式，选择最适合这种模式的人作为发展部主管。您的开发部门主管与产品团队的关系将对模式的成功产生决定性的影响。