|
“增长即服务”这种模式下，团队在技术上并不拥有任何功能或者代码库。他们跳到了产品的最高价值部分，进行他们的分析和优化，交付一堆的改进，然后继续。团队要保持温柔，这一点很重要，因为他们是客人，但他们保持轻量也很重要。如果增长团队最终拥有他们碰到的每一块代码的话，那他们最终就会陷入到一切的维护模式当中。
另一方面，完全的所有权模式意味着增长团队可以拥有新的用户漏斗、通知、广告技术、A/B测试平台、支付流，以及许多其他数字胜过直觉的关键领域。这样可以管用，但然后团队需要恰当地配置人员。
不同模型的优缺点：GaaS——优点是敏捷，缺点是容易冲突；自治——优点是可控，缺点是会臃肿；混合——优点理论上是各取所长，缺点很难划清团队之间的界限。
上图：每一种模式都会有各自的优缺点。Uber各自模式都试过，不过慢慢地开始拥有产品越来越多的部分。但是你得根据自己的约束、组织和产品需求决定选择哪一种。
关键问题#4：增长团队的关注点应该是什么
一旦增长团队建立起来之后，其关注点应该放在什么地方？就像之前讨论过那样，他们的使命和工具包应该跟营销或者产品团队使用的那些有所不同。尤其是在团队的早期阶段，应该有一些唾手可得的东西选用。
尽管直接跳到用户获取或者看看流失情况很容易，但是从更高的角度去看看这个体系还是很有帮助的。先从优先级框架开始。
确定优先项目的框架
上图：最终有3样关键的东西需要进行权衡——有一个尤其棘手：
投入。执行需要付出多少的设计/工程/营销资源？
成功。取得成功的可能性有多大？
提升。这个比较棘手——如果管用的话，对整体增长会产生多大的影响？
每一次增长试验最终都是根据这三样东西的排名选择出来的优先事项，慢慢地，你的增长团队在如何选择方面就会变得很明智。但我还想就增长团队可能会出问题的地方提供一些注意事项。
选择增长项目最常见的反模式是把影响到0.01%用户的功能改进+50%视为可喜可贺，却觉得一项影响50%活跃用户的功能改进只有5%很小。当然你只要算一下就知道后者要重要得多，因为你最终希望那些自下而上的试验要实现自上而下的KPI。
另一个常见的反模式是把焦点放在大规模的、好处巨大的项目而不是不需要太多努力、但好处不大或适度的项目。几乎每个人都会过高估计自己的成功机会，所以最好是多进行试验而不是孤注一掷……除非你已经穷尽了好做的想法，或者你已经有了足够的资源来建立大小项目的池子。
关于每一种因素的一些注意事项：
一般而言，投入是最容易理解的。如果你定义好了项目，你的团队就能够像其他任何东西一样针对它来执行。我一般建议增长团队早期要向低投入的项目倾斜。
成功可能会引起争议，因为对增长有效的东西未必是用户自己会报告的东西——因此，团队成员通常会说，“我永远也不想要这个。我永远也不做这个。”是的，你执行了最佳实践并且管用。典型的例子是渴望给登录页增加全面内容，那些东西会链接到无数新地方。但是一个很好理解的设计模式是只需提供必要的信息完成登录即可——不要画蛇添足。
提升在这三个因素当中是最难理解的。但同时也是最强大的手段，因为它为增长团队应该关注产品的什么地方提供了有力的指南。
那么我们就进一步看看这个因素。
提升=覆盖 x 影响
（编辑：网站开发网_安阳站长网）
【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!
|
