mirror of
https://github.com/cheetahlou/CategoryResourceRepost.git
synced 2025-11-04 00:03:53 +08:00
mod
This commit is contained in:
121
极客时间专栏/从0开始做增长/模块六 | 巧妙复制让增长遍地开花/37 | 积少可成多,别针换别墅.md
Normal file
121
极客时间专栏/从0开始做增长/模块六 | 巧妙复制让增长遍地开花/37 | 积少可成多,别针换别墅.md
Normal file
@@ -0,0 +1,121 @@
|
||||
<audio id="audio" title="37 | 积少可成多,别针换别墅" controls="" preload="none"><source id="mp3" src="https://static001.geekbang.org/resource/audio/5b/56/5ba0f83f4d82b7130b5711e3f0f98556.mp3"></audio>
|
||||
|
||||
你好,我是刘津。
|
||||
|
||||
今天我们又来到了一个新的模块,第六部分:巧妙复制让增长遍地开花。在这个模块里,我们来谈一谈,如何让增长积少成多,源源不断地自行运作下去。
|
||||
|
||||
了解理财的人都知道,如果你每月固定存下一笔钱去做基金定投,那么坚持若干年,将产生可观的复利。
|
||||
|
||||
增长也是这样,**如果你养成了科学实验的习惯,每次增长一点点,坚持一段时间,就会积累出巨大的成果。**
|
||||
|
||||
比如说宜人贷的营销落地页,经过40天的实验,最终累计提升转化70%。
|
||||
|
||||
又比如《增长黑客实战》提到过的微软案例,微软的Bing搜索引擎曾通过A/B测试反复调试页面配色方案,最后的胜出方案与旧版色差极小,通过肉眼几乎无法识别,却提升了1000万美元的年化营收。
|
||||
|
||||
再比如2015年雅虎发布Yahoo Mail期间,团队花费整整10周时间进行了122次测试,通过将3%、5%、8%的优化成果不断累加,最终将下载转化率提升了13倍,成功挤入App Store免费排行榜第五名。
|
||||
|
||||
优化增长的复利效应由此可见一斑。
|
||||
|
||||
当然,增长是一个很广义的概念,既可以是价值的升级,也可以是细节的优化。总体来说,我认为增长的积少成多有三个层级,分别是:价值导向的创新迭代、成功经验的二次复制、实验结果的批量复用。
|
||||
|
||||
## 价值导向的创新迭代
|
||||
|
||||
还记得我在第二讲提到的微信和头条的模式吗?
|
||||
|
||||
<img src="https://static001.geekbang.org/resource/image/fc/8e/fc1ee4597c4bad1bf0d53c628c02af8e.png" alt="">
|
||||
|
||||
微信非常注重思考和创新,围绕定位不断扩展新的功能。每一个新功能的诞生,都会引起大家的关注,带来一波又一波话题。
|
||||
|
||||
而微信的定位是什么呢?“一个生活方式的工具”。
|
||||
|
||||
围绕这个定位,微信从单人聊天拓展到群聊,在群聊的基础上又有了朋友圈,后来又有了公众号和小程序。
|
||||
|
||||
<img src="https://static001.geekbang.org/resource/image/8b/48/8be92c8dd11d293389bcd4a568497448.png" alt="">
|
||||
|
||||
它的每一个功能都不是空穴来风或盲目跟随,而是来自对生活、对用户的思考,一步一个脚印地走到了今天。
|
||||
|
||||
而每一个功能的创新,也都为微信带来了指数级的增长。
|
||||
|
||||
所以,增长的迭代可以很大,也可以很小,可以是在原有的基础上不断创新,也可以是细节上的不断改良,这些都算是增长的迭代,通过长时间的积累形成巨大的增量。
|
||||
|
||||
而这些创新也都不是零散的点子,而是围绕定位有序地开展。表面上看好像彼此毫无关系,实际上每一次创新积累的经验和成果都为下一次创新奠定了基础。
|
||||
|
||||
## 成功经验的二次复制
|
||||
|
||||
与微信不同,头条非常重视技术和算法。一旦验证某个模式可以取得成功,就会不断复制该模式到其它产品上,从而取得更大的成功。
|
||||
|
||||
<img src="https://static001.geekbang.org/resource/image/9c/24/9c38a506e06efaf6130df075af4f0a24.png" alt="">
|
||||
|
||||
比如通过算法推荐,每个用户都能看到不同的内容,形成了真正的“千人千面”,这种模式让今日头条在众多新闻类产品中脱颖而出,成为一匹黑马。
|
||||
|
||||
头条尝到了这种模式的甜头,又将这种模式拓展到了当下非常火爆的短视频领域,做出了火山小视频、TOPBUZZ、抖音等产品。尤其是抖音,已经成为当下最受欢迎的短视频产品。
|
||||
|
||||
虽然这种模式并无太多惊喜和创意,但它能快速复制、快速占领市场,这也是一种非常聪明的增长方式。相当于取了一个配方,然后通过批量生产达到更大的经济效益。
|
||||
|
||||
所以微信和头条,一个像是手工自制的老字号,一个像是批量生产的工厂,两种不同的思维最终都能带来惊人的增长。因为它们都做到了积少成多,而不是把增长变成了一锤子买卖。
|
||||
|
||||
## 实验结果的批量复用
|
||||
|
||||
当然,对大多数人来说,这两种方式都离我们比较远。
|
||||
|
||||
在实际工作中,我们可能既无法做到腾讯这样的功能创新,也没有办法像头条那样从0到1做几款可复制的产品。那么现在我就介绍第三种积少成多的方法:实验结果的批量复用。
|
||||
|
||||
其实原理很简单,就是我们每做一次实验,都会积累相应的结论。如果实验成功,我们就会知道怎样做可以带来数据提升;如果实验失败,我们会总结经验教训,明白做什么样的事情不能带来数据提升。
|
||||
|
||||
那么经过一段时间的积累,我们很可能从这些实验结论中找到增长规律。
|
||||
|
||||
### 在实验结果中找到增长规律
|
||||
|
||||
还是拿营销落地页的实验举例,我们通过一段时间的连续实验,找出最有代表性的三个方案。其中第一个是原始方案,第二个是提升转化30%的方案,第三个是最终提升70%的方案。
|
||||
|
||||
<img src="https://static001.geekbang.org/resource/image/21/3a/21603f0f3803c01d46d81b2a62d3713a.png" alt="">
|
||||
|
||||
通过这三个方案的演变,我们可以明显发现其中的规律:方案越来越“浓眉大眼”了。
|
||||
|
||||
具体体现在以下几个方面:比如视线垂直、元素简单、布局规整、颜色清爽、图大字大、图标反白等。
|
||||
|
||||
如果不通过实验的对比,仅仅是通过设计师“专业”的设计,我们是很难发现这样的规律的。所以,专业能力只是基础,在实际操作中还要配合合理的方法,才有可能做到增长。
|
||||
|
||||
### 复制增长规律
|
||||
|
||||
接下来,我们要把这些增长规律沉淀下来,形成我们新的设计规范,让团队所有人都去遵守规范,并复用到其它的场景中。
|
||||
|
||||
比如,我们用同样的风格修改某条业务线的H5介绍页面,转化立刻提升了20%以上。之所以要先在App里的某个H5页面上尝试,是因为H5页面可以立刻看到效果,如果效果不佳也可以立刻替换回原先的版本,降低错误的风险。
|
||||
|
||||
<img src="https://static001.geekbang.org/resource/image/74/6f/7416b558344d38e5ceb751e37f236c6f.png" alt="">
|
||||
|
||||
### 批量应用到更多场景
|
||||
|
||||
由于我们有多条业务线,所以后来我们索性把所有业务线的H5详情页都替换了新的风格。并且我们也同时优化了PC端的营销落地页。
|
||||
|
||||
结果不出所料,效果非常好,所有改进后的页面转化都有了20%以上的大幅提升。尤其是PC端营销落地页,提升了145%。而在此之前,我们团队的设计师同学优化了不下十个方案,数据均没有明显提升。
|
||||
|
||||
## 增长链
|
||||
|
||||
由上面这些内容我们已经可以清晰地知道,**无论你用什么方式积少成多,增长都有一条内在的链路在运作**,绝不是无序的、灵光乍现的、撞大运的结果。
|
||||
|
||||
我把这条链路叫做“增长链”,有了它,你的一点点增长成果都可能会像滚雪球一样,最终带来巨大的变化。
|
||||
|
||||
<img src="https://static001.geekbang.org/resource/image/6b/9c/6b890dd0f831cf4f8c075bdbd161279c.png" alt="">
|
||||
|
||||
拿我们团队的例子来说,我们一开始锚定在H5营销落地页上,因为从用户增长地图上我们可以看到,这个页面的优化对提升北极星指标来说非常重要,对公司的价值也非常大,并且H5页面优化起来成本很低,可以立刻看到效果。
|
||||
|
||||
持续优化了40天以后,累计转化提升70%。在这个过程中我们做了很多次的实验,每一次实验都可以得到对应的结论。但是别忘了我之前说过的“抓大放小”,我们可以找出最重要的三个方案,观察这三个方案演变的规律,得到其中明显的增长规律。
|
||||
|
||||
接下来,我们把这个规律复用到App中的H5产品详情页面上,结果三条业务线的产品详情页转化都提升了20%以上。
|
||||
|
||||
之后,我们计划把所有App里的页面都替换成新的风格。但是很显然,这么做难度很大。因为要这样做,我们会面临一个新的问题:这么大的工作量,一个设计师肯定完不成,但是如果多个设计师一起做,风格是难以保持统一的。于是我想到了组件库的概念,这样可以用更智能的方式来替代人力,既节约了成本又提升了设计质量。关于组件库,我会在下一讲重点介绍。
|
||||
|
||||
这就是我们团队的增长链,稳扎稳打、步步为营,最终带来了批量的增长。
|
||||
|
||||
当然,每个公司的情况不一样,大家的职能也不一样,我的增长链可能并不适合你,但是你可以根据这个思路去打造合适的增长链,让增长毫不费力的遍地开花。
|
||||
|
||||
<img src="https://static001.geekbang.org/resource/image/f1/d5/f192779345cca413ddc987929a37e9d5.png" alt="">
|
||||
|
||||
## 思考题
|
||||
|
||||
你能否找到属于你的增长链呢?不一定是工作方面的,个人增长方面的也可以。
|
||||
|
||||
欢迎把你的思考和疑问通过留言分享出来,与我和其他同学一起讨论。如果你觉得有所收获,也欢迎把文章分享给你的朋友。
|
||||
|
||||
|
||||
111
极客时间专栏/从0开始做增长/模块六 | 巧妙复制让增长遍地开花/38 | 四级延续:增长组件库案例.md
Normal file
111
极客时间专栏/从0开始做增长/模块六 | 巧妙复制让增长遍地开花/38 | 四级延续:增长组件库案例.md
Normal file
@@ -0,0 +1,111 @@
|
||||
<audio id="audio" title="38 | 四级延续:增长组件库案例" controls="" preload="none"><source id="mp3" src="https://static001.geekbang.org/resource/audio/60/2d/60f152426961600be340f889cd40a12d.mp3"></audio>
|
||||
|
||||
你好,我是刘津。
|
||||
|
||||
今天我们来看一个实际的有关增长链的案例——增长组件库。
|
||||
|
||||
当然这个例子只是为了抛砖引玉,希望你可以根据自己的项目情况,结合自身技术,找到更多的智能增长方式。
|
||||
|
||||
## 什么是GPL增长组件库
|
||||
|
||||
通过上一讲的内容,我们已经知道,通过不断的测试,我们总结了一套设计规律。之后把规律复用到一些关键页面上,使得转化都有了显著的提高。
|
||||
|
||||
这个时候,我们自然希望所有的页面都能复用这套风格,然而这个工作量非常大,而且很难保证质量。因为每个设计师都有自己的风格,很难完全遵循某种特定的规律。
|
||||
|
||||
之前我就想当然地给团队成员展示了这种风格,我以为大家都能够意会,但是最后成员做出的结果五花八门。每个人对视觉的感觉和理解的细微差异使得最终的呈现结果都是不一样的,所以我只好打消了这个念头。
|
||||
|
||||
后来我想到了在阿里工作时接触到的DPL(Design Pattern Library)组件库。
|
||||
|
||||
简单地说,组件库就是一套详细的设计样式控件库,它把交互规范、视觉规范、前端代码融合到了一起。我们看到的每一个标准样式,背后都对应着现成的代码。那么在实现的时候,只要找到样式,对应的代码就可以直接使用了,非常方便。
|
||||
|
||||
和传统设计方式相比,它的好处是可以保证体验的一致性,减少人力成本,提升效率。我们不需要再一个一个页面逐一设计、制作,而是抽象、提炼出常见的控件,定义它们的使用标准和规范,根据需要随时“拼装”出不同的页面。
|
||||
|
||||
<img src="https://static001.geekbang.org/resource/image/ed/2d/ed0ba77748ae7a0abc12bc90240e542d.jpg" alt="">
|
||||
|
||||
就好像这张图,以前要盖一个完整的楼,盖完一个才能再盖下一个,不同的人盖出来的很可能都不一样。现在我们有了现成的积木块,可以各种拆解复用,不仅方便快捷还保证了样式的统一性。
|
||||
|
||||
但是它的缺点也显而易见:与增长无关、耗时耗力、很难推动。
|
||||
|
||||
为了要推一套组件库,你需要提前抽象出所有必要的组件,并且要借着大改版的机会全部替换掉原来的样式,工作量不仅大,还很难推动。一般都是高级领导在征得业务老大的同意后,强行推动才行。如果设计团队话语权不够,推动力量不强,是很难做到的。毕竟业务方看中的是业绩,而组件库和改版更像是“面子工程”,很难带来什么实际的效益。
|
||||
|
||||
而且,业务线多且集中的地方才有推组件库的必要,所以我们很少在小公司里看到这种方式,这也是它的局限之处。
|
||||
|
||||
针对上述这些缺陷,我们决定结合增长规律和传统的DPL组件库,升级成全新的GPL(Growth Pattern Library)增长组件库。
|
||||
|
||||
<img src="https://static001.geekbang.org/resource/image/96/e0/96b7a2a85b31cad2ffa3bef5f70318e0.jpg" alt="">
|
||||
|
||||
## 与传统DPL组件库的区别
|
||||
|
||||
GPL和DPL是完全不同的,它们的不同体现在目标、实现方式和结果上。
|
||||
|
||||
首先,是目标不同:GPL以增长为导向,强调的是用最小成本带来最大价值。而DPL仅仅是提升工作效率、统一样式。
|
||||
|
||||
其次,是实现方式不同:GPL强调先在一个点进行实验,效果好再逐渐推动到线、再覆盖到面,用精益的思维逐步尝试,才能以小成本保证最终的批量增长。而传统DPL是一步到位,是一个浩大的工程。
|
||||
|
||||
最后,是结果不同:GPL可以用小成本带来批量增长;DPL推动成本很高,却并不能带来数据的批量增长。
|
||||
|
||||
其实就是我们之前一直在说的用户增长设计思维和传统产品设计思维的区别:一个强调以用户为中心,通过差异性洞察找到增长爆破点,用最小成本创造最大价值;一个强调专业、面面俱到。
|
||||
|
||||
GPL和DPL的差异也是如此,表面上看都是组件库,好像也没有什么区别,但背后是完全不同的思考逻辑。GPL的每一个组件设计都源于前期的深刻差异性洞察及后期的反复试验,而不是通过表面上“专业”的推导及“个人经验”得到的。
|
||||
|
||||
就好像同样都是手机,看上去也没什么区别。但是苹果手机背后是一个的生态系统,而Nokia就真的只是个手机。
|
||||
|
||||
之所以要讲这么多,是因为以前我在分享的过程中,我发现很多新手始终无法理解这其中的精髓,觉得它看上去和传统方式“差不多”,就认为这只是包装了一个概念,其实并非如此。
|
||||
|
||||
这就像很多外行人通过“速成班”学钢琴,几周时间就能弹出一支像样的曲子,引得众人喝彩。但是内行一看就知道是刚学的。**任何一个领域,没有数年的积累都很难一眼看破玄机。**
|
||||
|
||||
虽然专栏的名字叫《从0开始学增长》,但这里的0只是指零增长基础。如果没有若干年的工作经历,没有其它方面过硬的专业技能,可能也很难领悟。
|
||||
|
||||
## 通过OKR和项目制推行
|
||||
|
||||
说了这么多,现在我们言归正传,看看具体要如何着手进行GPL组件库的执行工作呢?由于我们有项目制,所以在征得领导的同意后,根据OKR的思路立了一个项目。
|
||||
|
||||
<img src="https://static001.geekbang.org/resource/image/af/21/af3d7939b87e664cbd90784acbbd7c21.jpg" alt="">
|
||||
|
||||
每个项目都需要有项目愿景,你可以理解为是项目的北极星指标。当时的领导层要求项目愿景要满足三个标准:创新、行业领先、对公司有价值。
|
||||
|
||||
基于此,我们最终定下的项目愿景是:打造行业内第一个能批量提升转化的组件库。围绕这个愿景,对应得到三个O(目标),分别是:批量提升转化、大幅提升工作效率、批量提升页面质量。
|
||||
|
||||
接下来,我们再细分KR指标。有了目标,我们现在要考虑如何执行。很显然,传统组件库那种“憋大招”的方式无法带来增长,增长的前提是深思熟虑的洞察分析+提出假设反复验证。因此,在推动方式上,我们采用了“精益”的思维。
|
||||
|
||||
<img src="https://static001.geekbang.org/resource/image/09/b5/0971f1cbec6ef29b993c39ac973e0bb5.jpg" alt="">
|
||||
|
||||
首先,在营销落地页上反复测试,得到增长规律;然后再把这些规律复用到App中的若干H5页面上看效果,后来发现转化有了显著的提升;接下来我们向不同业务线的产品经理兜售这套方案,最终有一条业务量较小的新业务线愿意采用这套样式。
|
||||
|
||||
我们打算先以这条业务线为基础,提炼一套适用的组件库。这样,我们就不需要完成所有的组件规范,暂时只考虑这一条业务线就可以了。当然,也要适度考虑延展性,避免未来出现和其它业务线不兼容的情况。
|
||||
|
||||
该业务线上线组件库后,数据效果惊人,所有页面的转化都有了显著的提升。拿着这个成果,我们又去找了其它业务线的产品经理,受到了他们的认可,最终得以在不同业务线上去推动。
|
||||
|
||||
<img src="https://static001.geekbang.org/resource/image/f4/64/f46dd20d923cf8f9e67cb1a9dc0ab664.jpg" alt="">
|
||||
|
||||
就这样,我们非常轻松的推动了组件库的落地,而不需要通过高级别领导的施压或“政治斗争”来完成。毕竟大家都是讲利益的,只要能共同推进业绩提升,没有人会拒绝能带来增长、提升效率的好点子。
|
||||
|
||||
组件库完成后,各业务线转化提升了10%以上。之后再做大改版,只要替换库里的样式就可以了,不需要再重新开发,这样减少了原先80%的开发工作量。日常的版本迭代也减少了30%的工作量。设计质量以及统一性得到了彻底的解决。还原度问题降至0。原来需要5~6个设计师维持版本迭代,现在只需要0.5的人力维护组件库即可,剩下的人可以去做更有创意的事情。
|
||||
|
||||
即使不做组件库,只是统一并维护、执行这套增长设计规范,也能大幅降低设计人力成本,提升设计质量并带来增长。
|
||||
|
||||
但如果你的公司业务线不多,或者不同业务线面向的人群或场景不同,可能并不适用于做组件库,这就需要根据情况具体地评估了。
|
||||
|
||||
## 高维打低维才是王道
|
||||
|
||||
当然,这个例子只是抛砖引玉,目的是为了让你明白如何用更聪明、更省力的方式解决日常增长乃至管理的问题。
|
||||
|
||||
还记得我在第2讲提到的吗?问题不会在发生的那个层次解决,只有上升到更高的层面才能解决。这就是我们常说的“高维打低维”。
|
||||
|
||||
我之前也招过设计管理,结果人来了以后就开始盯着每个人的产出,不断地指导、改进,整理设计规范,最后弄得所有人都非常累,设计质量在短期内也没有明显的提升,界面体验和还原度问题依然非常严重。
|
||||
|
||||
而我却反其道行之,对设计规范不管不问。因为我认为没有得到验证的成果,是没有任何意义的。然后,我一直专注在营销落地页的测试上,不断总结适合的设计规律,时机合适了再不断延展复用到其它场景。
|
||||
|
||||
这波操作让很多资深的设计师理解不了,不明白我在干什么,以为我不务正业。等到各种增长结果如雨后春笋般涌出,他们依然不明就里,以为我们只是运气好,碰巧数据上去了。
|
||||
|
||||
所以,增长真的不是常规思维可以理解的。不是说你在那天天加班,表现的自己很专业、很忙碌,就是有价值有产出。这段时间我做增长的经验就是,**如果没有想清楚,还不如什么都不做呢。**做的事情越多,可能越是南辕北辙。
|
||||
|
||||
<img src="https://static001.geekbang.org/resource/image/47/06/47554e6f55adfab412c66fe7696cc306.png" alt="">
|
||||
|
||||
## 思考题
|
||||
|
||||
你有遇到过这样的情况吗,每个人都非常辛苦,项目还是很快失败了,你认为原因是什么?
|
||||
|
||||
欢迎把你的思考和疑问通过留言分享出来,与我和其他同学一起讨论。如果你觉得有所收获,也欢迎把文章分享给你的朋友。
|
||||
|
||||
|
||||
Reference in New Issue
Block a user