8.4 天下武功，唯快不破

8.4　天下武功，唯快不破

每个产品都要通过不断的规划和迭代一步步成长，而互联网产品的特殊之处在于成长得格外快。几个月以内，就能亲历一个互联网产品“看他初乍到，看他起高楼，看他宴宾客，看他楼塌了”的全过程，这可比以“几十年”一个变化周期的传统行业刺激多了。

做产品，成功当然最好，但最差的不是失败，而是半死不活地一直拖着，其间的机会成本会大到很难负担得起。互联网产品追求快速，首先要强调研发周期的缩短和迭代频率的加快。因为迭代周期越短，同样时间段内获得的尝试次数越多，用来纠正和改进的机会也就越多。

下面，就让我们从速度的视角来体会一下这个“快生快死”的行业。

8.4.1 　 互联网速度到底有多快

在产品早期的验证阶段，团队灵活，流程简单，还没有太多的用户，最能体现出互联网速度。有的产品从发现问题或机会，到讨论出方案，再到上线，大约可以做到两三个小时，甚至不到一个小时。

给大家两个鲜活的小例子，第一个来自豆瓣。10多年以前的豆瓣，还是由创始人阿北一个人来写代码。如图8-6所示的这个帖子发布的时间是某个周日将近23点，跟帖的若干条讨论也就发生在几分钟内。阿北通过和用户紧密而及时地互动，在几分钟内就完成了对豆瓣页面这个小调整的一系列优化。

第二个例子是互联网产品运营社群“三节课”贡献的，展示了产品和运营是如何配合完成一次快速响应的。

2016 年 4 月 21 日，微信群里曝出一个很有意思的玩法——用户可以通过修改自己的名字、撤回已发出的消息等操作，在群里留下如图8-7所示的有意思的系统提示。

对大多数微信用户来说，这只是一个有趣的小玩法罢了。但职业敏锐度让三节课团队意识到，完全可以趁着业内人士新鲜劲还在的时候，借势做点事情，让三节课从中受益。而达成这一目标的关键，就是响应速度。

下面，依次列出他们采取行动前后几个小时内发生的事情。

11:00 发现这个玩法，三节课的同学自己开始玩。

11:40 技术同学出于好奇，主动研究微信系统提示的运行逻辑。

12:20技术同学研究出原理，开始思考是否可以做一个全民娱乐的小工具，让大家都可以更方便地留下各种系统提示。当然，这个小工具可以顺带植入三节课的广告。

12:50工具完成，运营同学接力，开始传播。

13:20微信同样反应迅速，封掉了这个也许称不上漏洞的漏洞。

在互联网行业里，每天都在上演着与时间赛跑的案例。这个行业的机会很多，但都是稍纵即逝，因此保持敏锐度和快速执行的能力，非常关键。

8.4.2 　 烧钱是为了抢时间

“烧钱”，似乎是互联网行业很有特色的一个发展策略。能理解快的重要性，就不难理解烧钱的目的——抢时间。对创业团队来说，抢时间尤其重要。

一位创业的朋友在分享运营策略时，谈到“单用户成本”的算法：计算一款产品的“单用户成本”时，要纳入整个公司的运营成本（含人员等成本），而不是只计算该产品的推广费用 。

举个例子。如果只算推广费用：

A方案：每个月花5万元带来1万个用户，单用户成本是5元。

B方案：每个月花20万元带来2万个用户，单用户成本是10元。

如果以这样计算出的单用户成本为考量依据，明显应该采取A方案，选择每个月花5万元来运营。

但如果考虑公司日常运营成本（包括人员、服务器、带宽等成本，假设一个月为20万元）：

A方案：每个月25万元带来1万个用户，单用户成本25元。

B方案：每个月40万元带来2万个用户，单用户成本20元。

这次，对比后理所应当选择单用户成本低的B方案，而这个方案中投入的直接推广费用是20万元，远大于A方案的5万元。看来“烧钱”是有量化依据的。

当然，这个例子忽略了很多实际情况，比如用户的后续活跃留存等，但其计算方法的逻辑无疑是正确的。除了单用户成本有优势外，B方案更加有利的是，比A方案提前一个月做到了2万用户，足足省了一倍时间！对于在和竞争对手赛跑或需要用漂亮数据拿到投资的互联网创业公司，这样的领先意义重大。

多年前我写过一个“攻山头的故事”，里面提到创业和某些大公司的区别：

从前有座山，山上没有庙……但是有好多好多的蘑菇、山药、木耳，让每个人都口水直流，于是，大家都想抢占这个山头，而且只有一天时间。

一支三五个人的游击队，饿得不行了，没时间探路，没时间研究，唯一的机会就是抓紧时间，乘着夜黑风高随便找一条路冲向山头。也许一场大雨引发泥石流，或者踩到一颗地雷，或者遇到一群狼，都会全军覆灭，但如果侥幸冲上去，就立马占山为王，山鸡变凤凰。

这支部队，是创业公司。

一支看上去人很多的部队，实际上是十支集合在一起的游击队。进攻之前，领头的发现依然是没时间探路，没时间研究，心想干脆不探路了，当年在游击队的时候拼的就是RP（人品）。于是召集所有兄弟开了一个统一思想的会议，言明攻下这个山头的高尚动机与社会价值。然后，十个队长带着兄弟们高喊着：“为了×××，冲啊！”从四面八方涌向山头，十支敢死队也许死了八九支，但只要有一两支冲上去，就胜利了。

这支部队，是阿里。

国内现在的创业环境，更像是综合了上面两个情况。

每个小土包，都有几十支饿得不行的游击队在往上冲，每个人都清楚地知道，他们绝大多数都会死，但从概率上讲，总有人会登顶。这时候，如果选择慢慢来、想清楚了再上，就算路径正确，也是死路一条。因为等你爬了一半，就会发现山顶已经有人了，而——快，才有可能活下去。

听起来，像是有一种“别人孩子都去上补习班，于是我也只好给娃报名”的无奈，而事实上这是一个行业从新生到成熟的必经之路。

8.4.3 　 省时间的低成本验证

单纯为了速度而横冲直撞，是不可取的，也是得不偿失的。那么，如何合理而科学地加快速度呢？答案就是低成本验证。低成本验证的理念，本质上和迭代的思路完全一致：在一个快速变化的环境下，不断地用最少的时间、成本去获取市场反馈，不断修正前进方向 。下面举几个例子。

假设你要做一个交易系统。

正常的交易流程一般叫作“正向交易”，要满足买卖双方之间下单、付款、发货、收货等常规需求，是交易系统必备的。但是，“退款/退货”这种“逆向交易”要不要做呢？做的话，系统复杂度会大幅增加，实际工作量不只翻倍，往往会超出3～5倍。

怎么办？可以这样低成本验证：先在线上做一个假的“退款/退货”按钮，用户点击以后，系统直接给客服人员发邮件，由客服人工完成处理。这样运行几周后看看效果。如果客服只收到几封邮件，那么就继续采用“人肉”处理；如果收到的邮件多到人工处理不过来，就可以理直气壮地上系统了。

除此之外，不轻易做系统还有一个现实意义：上线容易下线难。功能上线后，如果只有很少的人在用，就会陷入尴尬境地。如果下线，这些在用的人会跳起来说：“我用得好好的功能，你们为什么要下线。”而如果迫于这种压力，勉强继续维护着这一功能，一方面有成本，也很吃力；另一方面后续新功能也必须考虑和这个鸡肋功能的兼容、协作。

现在的很多创业项目，启动阶段先做微信公众号、H5页面，而不是App，一个主要的出发点也是低成本验证。这么做，开发人力的成本可以低一些，用户获取的成本可以低一些，功能调整的成本也可以低一些。用一个简单的产品雏形把业务逻辑先跑通，然后再考虑是否要做客户端，是很值得推荐的产品策略。

再来一个案例，假设你想做一个垂直领域的导航站。

这个站点可以告诉创业者，创业过程中都会碰到哪些问题，可以用哪些服务解决，可以去什么站点获取资讯。我的建议是，先不要做网站，而是把精心整理的各种资料，通过一篇高质量的文章来传播，收集阅读、收藏、转发的数据，或者挑一些目标用户来问问反馈，再决定下一步怎么做。

最后来说一种有趣的低成本验证方法——利用公关手段。

经常看到阿里PR稿件中出现“阿里又要推出×××”“阿里开始进军×××”“阿里正在秘密研发×××”这样的标题，而这很多时候都是有意为之的小动作，甚至产品、技术团队都毫不知情，更谈不上真正开始投入资源了。而很多对手会被带到沟里，开始研究对策、排兵布阵。

大机构想推出新政策的时候，先借助合适之人如专家的嘴，或其他渠道如非官方媒体、小道消息等来透露给社会大众，试探他们的反应，得到相应的结果后，或顺水推舟地证实，或矢口否认地辟谣。不用担心最终没做会辜负期待，用户总是很健忘。回顾一下以往的新闻，能想到很多这样的例子。

广义的公关之法，其本质就是先不做，却告诉受众我已经做了，从而收集反馈，其优势在于成本非常低，验证非常高效。

小结一下，低成本验证的核心，就是看谁能用更少的资源、时间等成本，拿到一些假设是否成立的结论，而更深层次的目的，还是为了更好地服务用户，更好地达成公司的商业目标。