我们采访了二十位公司主管来帮你解答这一至关重要的问题,他们的东家都是有着最快发展速度的企业,例如Pinterest 和 FanDuel。
在经过了长达三十多个小时的采访之后,我们弄清了一件事:选择正确的团队发展模式不仅利于企业的发展,同时也能强化企业文化。
团队发展模式
从我们的采访中可以总结出两个较为流行的团队发展模式:
一 种是独立模式,一种是功能模式。如果你想要组建自己的发展团队,二者都是不错的着手点。“当游戏开始时,要按正确的布局玩儿”(Zack Onisko,CreativeMarket***发展官)。每种模式都聚焦于“更为深入地了解自己团队的发展模式”(Mike Duboe,Tilt发展官),然后全力解锁盈利问题。
独立模式
总结
Uber 和Facebook采用的就是独立模式。我们在采访中无意发现该模式主要有以下两个版本:
在 这两个版本中,都有一位发展副总裁在领导着团队。举个例子,在Uber ,Ed Baker就是发展副总裁,直接向CEO Travis Kalanick汇报。Ed所领导的团队由100多人组成,与产品、市场、工程、设计以及数据部门的专家共同致力于供求双方的发展。
根据采访对象所提供的信息,Uber就是利用这种模式提高了团队生产以及迭代的速度,建立了很强的团队DNA。Uber极其重视速度和迭代,他们的发展团队还为此搭建了一个稳健的反馈机制,转而再将反馈体现在Uber的产品上。
反 馈机制能够帮助一个老用户群体发展出一个新用户群体,这种情况通常由老用户的搜索、支付以及举荐机制所引发。例如,新用户是听了老用户的推荐而开始使用 Uber,这就是推荐反馈的结果。司机是因为看了“成为Uber司机”的广告而加入Uber,这就是支付广告的反馈结果。在两个案例中,无论是供方司机还 是需方乘客,都是老用户利用反馈机制创造新用户的过程。
Uber发展团队的职责就是让这些反馈机制尽可能的强大,以此来提高公司的乘数效 应。例如,在Uber推荐反馈机制的乘数效应中乘数是“10”。这也就是说,Uber通过线性手段(例如付费广告)获得的用户将会再创造十倍的新用户。如 果团队通过付费广告获得了1000名用户的话,那么这1000位用户还会通过推荐反馈机制创造10000名新用户。
乘数效应越好,那么Uber就发展的越快。
独立模式中的冲突与解决方案
Pinterest发展部的产品经理Casey Winters认为独立模式中的冲突是不可避免的。
当Pinterest采用独立模式时,发展团队的数据一直处于上升状态。事实上,Pinterest的数据增长的如此之快,以至于其他团队都开始担心这种过快的增长是否是以牺牲广大的用户体验换来的。
举个例子,当发展团队推出一个全新的注册界面时,用户的活跃度会得到显著提升,但是忧虑也会同步而来。其他团队认为这一过程让用户体验变糟。然而,数据最终会给其他团队的直觉性言论带来反击。
这种既要保证用户体验,又需要维持增长指标的强劲有力是在采用独立模式过程中需要面对的***挑战。
关于这种增长是否必须要以牺牲用户体验为代价的争论一直不绝于耳,如果不采取措施,“这将会造成用户对于平台的信任缺失。” Winters表示,接着又说道“大家应该明白(也应该相信)发展团队会尽全力为用户带来***的体验。”
信任的建立
你要如何在不同的团队间建立最基本的信任?
Casey针对上述问题给出了一个良好建议:让发展团队书面承诺自己不会为了增长指标而做出有损用户体验的行为。我们的某个采访对象建议将该承诺书交由CEO保管,因为CEO是企业文化的开创者,与此同时,也请发展和产品副总裁签订此协议,以此来减少独立模式中的冲突。
在 Invoice2Go发展主管Naomi Ionita(前印象笔记发展主管)看来,发展部门的工作将不可避免的与产品部门有所重叠。基于自己在带领这两个团队方面的经验,她解释道,如果分工明确 或者产品发展部的领导具备良好的沟通能力,那么这种冲突问题是可以避免的。问题又重新回到“了信任、透明度以及客观性”上。
功能模式
总结
采访对象们表示,当发展部门的员工需要向功能部门主管(例如产品、工程等),其他人就会觉得发展指标将会以正确的方式得以实现。
Pinterest、Twitter、LinkedIn、Dropbox和BitTorrent采用的就是功能模式。
该模式的流行得益于以下三个优点。
1、功能主管(如产品、工程等)决定发展计划。
2、由功能主管来平衡增长和非增长计划。
3、产品副总裁通常扮演功能主管的角色,从而来掌管发展。
让我们来看看第三条是如何在实践中发挥作用的。
Pramod Sokke是BitTorrent的产品主管,能够在平台上与所有客户进行接触。他要负责BitTorrent的增长及非增长指数,这就意味着 Pramod的产品规划必须围绕着增长和非增长绩效展开,因为他要为两组的绩效表现负责。BitTorrent发展团队以外的员工也都非常信任 Pramod,因为他以一种平衡的方式来制定计划,确保所有人都能成功。
功能模式中的冲突及解决方案
尽管如此,用户体验与用户增长间的冲突在功能模式中仍然存在。因为上文中提到的几个优点,冲突并不像独立模式那么明显。之所以冲突还在,是因为保证用户增长的措施往往与用户对产品的预期背道而驰。
这就是为什么我们的采访对象会提倡纵向分析的原因。通过对用户行为所进行的分析,我们能够得知用户增长是否会以牺牲用户参与的积极性为代价。同时也会了解哪种发展计划既可以保证用户数量增长又能提高用户的参与度。
我们还了解到,当增长指数的全权负责人是数据驱动型,并且认可产品是需要迭代及学习机制的,功能模式会***效果。这样一来,产品的发展蓝图就不会是单凭直觉就规划出来了。
例如,Pramod在产品上就采用了一种非常典型的数据驱动迭代方法。这使得团队中唯一的发展项目经理AnnabellSatterfield变得更高效。因为这一方法将数据分析和迭代过程结合的非常好。
Annabell解释说她所采用的增长过程就是数据驱动和迭代的,跟直觉没有任何关系,而是全在于过程本身:观察数据(分别从质和量两方面分析)、制定假定方案、推出测试方案和最小化可行产品、观察测试结果,判断是将此次实验性产品推向市场还是带着教训从头再来。
现在让我们以假设的方式来说明功能模式中另一个潜在的冲突,假设数据驱动和产品迭代两个过程未能很好结合。
比 方说Pramod在管理产品时采用非迭代的方法,而Annabell 采用的还是迭代的发展模式。Pramod很可能要求Annabell在产品发展蓝图方面放出大招,这一过程需要6-12个月的时间。Annabell可能 会答应Pramod,但是她也可能在短短数周(或者数天)内就用数据驱动产品迭代的方法来证明这都是一些烂招。Annabell表示,无论是从收益还是用 户的角度来看,这样做将会增加产品的计划成本。
我们的一些采访对象将会通过改变产品蓝图的方式来对冲突进行解决。在上述假设的例子 中,Pramod可能想要双管齐下,而不是将所有的产品工作全部压在一种模式上。一个赛道用于实践Pramod的非迭代方法,而另一个则使用 Annabell的迭代模式。每个赛道都有其独立的产品、工程以及设计资源,以确保所有的功能都内在计划的时间和预算内完成。
企业高层必读(两种模式必读之处)
不管怎样,为了促进发展,公司高层必须引入数据驱动迭代的思维模式。不然,无论你怎样规划自己的发展团队都难逃失败的命运。
结语
在我们所处的软件世界中,发展与产品相互缠绕,意味着我们很难了解产品的终点和发展的起点在何方。这仍然是一个相对较新的现象,同时也使得选择***的团队发展模式充满挑战。
我们的采访对象,二十位发展主管,无一例外的都提到了两种最为流行的模式:独立模式以及功能模式。在业务可伸缩之际,当你想要组建自己的发展团队时,这两种模式都是很好的着手点。
在运行增长试验中,独立模式能够加快产品生产和迭代的速度。不过,这种模式也会导致团队工作透明度的降低,导致企业内部不信任的滋生,而功能模式因采用更为平衡的发展模式而增加了工作的透明度。不过,无论如何,用户体验和用户增长间的冲突仍然存在。
有趣的是,我们并没有在两种模式所造成的结果上发现太大差异,也就是说在实现产品更大的指数增长方面,任何一种模式都没有好过另外一种。
这是一个非常重要的发现。
所以在为团队选择发展模式时,以企业文化、组织结构及战略适应度为考量可能会得到更好的结果。不要单纯为了企业发展而选择模式,要选择适合的模式。
两种模式都具有各自的冲突,选择那种冲突在你团队能够解决范围之内的模式,然后选择一位秉性能与之契合的人作为团队领导。
发展部门主管与产品团队的关系将会对你所选择模式以及整家企业的成功与否起到决定性作用。
作者
Andrew (Drew) McInnes目前就职于Tradecraft。在此之前,Drew是一家社交移动游戏企业的发展产品经理(特别是在Zynga),并想要继续致力于协助打造发展引擎。