1

我的精益创业实践

当萌生一个灵感并且坚信它能改变世界的时候,你会选择怎么做?

有些人的选择是制定精密的产品方案,然后迅速把它秘密的实现出来,上线后花力气推广,如果半年时间还没有足够的用户量或收益,就换一个方向再来。

这种方式在传统商业环境不会有什么问题,因为需求和环境都是已知的。如果你想开一家拉面馆,不需要考虑人们会不会有吃拉面的需求、不需要考虑如果腾讯在中国开了一家拉面馆,自己是不是就做不下去了。还有许多成功的做餐饮的方法可以参照,好选址、好厨师、拉回头客等等。

但在瞬息万变的互联网环境中,需求、环境、成功路径都可能是未知的、变化的。《精益创业》里有一句比喻

大多商业计划像是发射火箭,计算好精密的航向和指令,但最微小的失误都会导致千里之外的灾难。而创业实际上像是驾驶汽车,时刻控制着方向,对每一个突发情况做出即时反应。

「发射火箭」式的创业最可怕的在于,密闭开发阶段的时间成本,期间会错过无数眼前的机会。一些创业公司的团队,就是这样被拖垮的。让人震惊的是有些大公司的部分团队,也采取着这样的方式做产品。高层制定战略,一线制定策略,然后执行,不撞南墙不回头。

而「驾驶汽车」式的创业,正是意识到战略是由假设构成的。我们假设了目标用户有怎样的需求,通过我们的解决方案刚好能解决用户的问题满足用户的需求。最先赢得市场的,是最快验证假设并不断调整使其步入正轨的团队,而不是最快把产品做上线的团队,因为上线离市场接受的距离还有很远。

《精益创业》这本书,我反复读过几遍,每一次领悟的更深一点。

第一遍读,我读到了「用数据验证认知」。

AB测试无疑是最严谨的数据验证方法,可以排除时间和用户特性的干扰,于是开始琢磨怎么在手机客户端里面做AB测试。

曾和团队讨论过把AB方案的代码都打到一个安装包里,然后通过服务器分流到A和B。但这样不仅会带来代码的冗余复杂,还让安装包体积加倍。最后发现,还是灰度测试最靠谱,也就是提前发布到小渠道,这样就能在同一时段观察到线上新旧两个版本的用户数据,根据数据决定是否要全渠道发布。

经过几轮磨合,灰度测试的流程也逐渐沉淀下来:

  1. 再细微的功能,都要写出其背后的假设和目的。
  2. 每一个功能,都要在灰度发布之前做数据埋点。
  3. 在灰度测试期间,观察新版本数据。如果数据表现超出旧版本,则证明假设是对的,可以全渠道发布。如果数据表现不符合预期,则需要回过头来看假设是否经得起推敲,产品设计方案是否真正解决了问题,然后做出调整、甚至砍掉这个功能的决策。

灰度发布的好处显而易见,接触用户的时间提前,让验证认知的反馈循环变得更快了。不再是为了解释数据表现而苦思冥想,而是让数据成为验证结论的有力工具。

第二遍读,我读到了「最小化可行产品」。

它比AB测试更进一步,在开发之前就验证认知,避免宝贵的时间和资源浪费在「高效地做一件根本不该做的事」。

那时,我们在探索聚美客户端如何实现「陪用户一起变美」的目标,其中一个方案是「女神进化史」,鼓励用户分享自己变美前后的照片和变美丽的方法,并且可以浏览按热度排序的信息流。听起来蛮有趣,但实现这个方案需要投入开发、推广、运营资源,还要找到一批愿意晒照片的女神。我们决定先用最小化可行产品验证创意是否可行,简单几个步骤:

  1. 建立微信公众账号
  2. 发布一篇文章,内容是女神变美前后的照片和变美方法,还鼓励大家参与分享自己的照片与方法
  3. 看数据,观察。

事实很残酷,22.51%的人对标题和女神图感兴趣,但没有人去查看原文里的变美方法,更别提参与和传播了。

这次「最小化可行产品」的实验让我们收获到女生的细微心理,一是她们对于女神的分享可能并不信任或者不感兴趣,二是她们也许并不愿意晒出自己丑的照片。我很庆幸,用一篇文章就验证了创意的假设不成立,没有把宝贵的开发、运营、推广资源浪费在一个不靠谱的事情上。

「最小化可行产品」需要舍弃掉对完美产品和全面功能的追求,只保留一个关键点:去验证提供的解决方案是不是能真正解决用户的问题。

Zappos为了验证人们会不会在网上买鞋,跑到隔壁鞋店拍了照片放到网站上,发现真的有人买。

Groupon为了验证人们会不会参与团购,在博客上发文章说只要有20个人买披萨饼就可以打八折。

Dropbox为了验证人们会不会有云端存储的需求,做了两分钟的视频演示如何同步文件,引发了大量关注,大家都在问从哪里可以下载这个软件。

那你呢,还在等待着两个月后发布一个完美的产品,祈祷着会有人喜欢么?

第三遍读,我读到了「用户调研」。

如果说「最小化可行产品」是定量的验证假设,「用户调研」则是定性的通过理解用户心理去验证假设。有人说,用户只会说他需要一批更快的马,但他的需求已经清楚表达出来了:更快。有人说,用户调研不具备数据意义和共性,只是个人观点,但如果五个目标用户都不喜欢你的产品方案,那就很具有数据意义了。

一次机缘巧合,我参与了「冷启动」,一个产品经理入行培训的项目,起步阶段,有许多需要验证的假设:

  1. 需要培训的用户是谁?
  2. 用户最头痛的问题是什么?
  3. 冷启动提供的解决方案能否解决用户的问题?