闪电式扩张的 7 条“反常识”原则

根据我在PayPal的经验以及我们通过快速推出和产品迭代发现的成功之道，我决定尽快推出LinkedIn。我们的团队定义了一系列我们认为是进入时候所需的最精简功能。几年之后，Steve Blank和Eric Ries把这种做法称为是“最小可行产品（MVP）”。对于LinkedIn来说，MVP包括了用户的职业档案，与其他用户建立关系的能力，一个搜索功能用来寻找其他用户，以及给朋友发消息的机制。

在推出后不久，我们开始担心如果档案达不到临界规模的话LinkedIn是否会有用。如果一位用户登入了LinkedIn的话，如何才能让它在此人的任何一位朋友都没有注册的情况下页能变得有用呢？我们认为产品还少了一个Contact Finder（通信录查找器）的功能，这种查找功能可以让LinkedIn用户找到潜在的供应商。我们的工程团队估计得花一个月才能做出这个功能。我们面临艰难选择——推迟一个月发布，或者在一项我们认为对产品成功必不可少的功能缺席的情况下推出产品。但基于这项让自己尴尬的原则，我们在没有Contact Finder功能的情况下也发布产品了。很快我们又发现了一个更大的问题：跟Friendster这类的个人社交网络不一样，当新用户邀请朋友加入时这些网络会出现爆发式增长，但LinkedIn的用户却任何邀请都不发出。我们的用户增长停滞了。我们的基线产品令人窘迫，因为没人使用！如果我们推迟一个月开发Contact Finder的话，仍然不会有足够的人使用它，意味着我们本来会浪费一个去开发那项无法解决核心问题的功能。我们估计我们至少需要100万用户才能发挥搜索（及Contact Finder）的作用，解决那个问题变成了我们的头号要务。

基于发布时数据，我们把焦点放在了增加病毒传播性，就这样我们成为了第一家允许你上传地址簿的社交网络。这项功能帮助LinkedIn实现了超过100万用户档案的临界规模，随后就是历史了。

记住，你应该对自己的第一版感到尴尬——但不是感到难为情或者有罪！对速度的渴望不是走危险捷径的借口。如果你引起了法律诉讼或者没学到东西就把钱烧光了，这就意味着你推出得太早了。

规则#5：让火燃烧起来吧

在闪电式扩张的每一个阶段，需要引起你注意的问题总会你手头可以用来处理的资源要多得多。你可能感觉自己像一位救火队员，只不过你要救的不是一个密闭容器喷出的火焰，而是看到周围全都是火苗——而且你还没有时间把它们全都扑灭。进行闪电式扩张的创业者还能留条活命的办法之一是决定让哪些火自生自灭（如果可以让它们这样的话）从而把关注焦点放在会真正毁了公司的那些火点。我在Greylock的同事Joseph Ansanelli曾经说过：“你拒绝的东西要比你同意的东西更加重要。”

你无法永远对那些火视而不见——其实那些火也是危险的，而且最终也需要你的关注，但是在闪电式扩张的大多数时候这些问题都不算是性命攸关的，因为扑灭这些火并不能对产生预期结果起到一点作用。

规则#6：做无法扩张的事情

Y Combinator联合创始人Paul Graham曾经写过一篇著名的文章，里面建议创业者去做无法扩张的事情。这条建议针对的是初创企业，但对于闪电式扩张的初创企业来说这一点甚至更加重要。

耗时仅占1/10的一次暴力破解也许要比一个设计优雅的解决方案还要好。

工程师讨厌做抛弃型的工作。这不仅是因为做这种事情属于浪费，也是因为这有违他们的效率感。传统智慧认为最好第一次就把产品做对，这样你就只需做一次即可，他们是这种思想的忠实信徒。但当你进行闪电式扩张时，低效才是规则，而不是例外。为了优先考虑速度，你也许在安全方面的投入就没那么大，写出的代码可能无法伸缩，并且在你开发好QA工具和流程之前等着事情出错。是，所有这些决策都会导致后面出问题，但如果你花太长时间去开发产品的话也许就没有后面了。耗时仅占1/10的一次暴力破解也许要比一个设计优雅的解决方案还要好，哪怕你的这次努力在后面也会被废弃。

同样的逻辑很大程度上也适用于你的企业的几乎每一个方面。在进行销售时你往往得做一些无法扩张的事情（比方说创始人Marc Benioff是找了CEO Monte Zweben帮忙才发展了Salesforce.com的第一位客户Blue Martini Software的），运营（Paul English将他的个人手机号码放出来作为Kayak当初的客服电话号码）等也是这样。

而且这个世界也不是能够优雅地区分为“无法扩张的事情”和“可以扩张”的事情，前者要平滑地、永久性地让位给后者。在闪电式扩张某个阶段可以扩张的代码或者流程在下一阶段也许就会失效，而不管你用什么去取代它，在一开始的时候其扩张性也是没有的。不妨想想看Airbnb创始人一开始是如何解决房东在Airbnb.com上面发布的房源照片质量不高这个问题的：他们自己成为了摄影师。就像Brian Chesky告诉我那样，“我们从RISD（罗德岛设计学院）的朋友那里借来了相机，然后一户户敲门去帮他们拍照片。”

就这样，Brian和联合创始人Joe Gebbia一起每天大概要拍摄10户房源的照片。（另一位联合创始人Nathan Blecharczyk得呆在公寓里付出双倍努力确保网站不会崩溃。）

随着Airbnb业务日渐起色，拍摄的职能也必须相应上规模才行。于是创始人从Craigslist上招来了摄影师，请求RISD朋友的帮忙，甚至招募将摄影列为自身爱好的Airbnb房东。通过利用这些资源，这家公司得以打造一支稳定的、由5到10名摄影师组成的拍摄队伍，以每户50美元的价格帮公司拍摄，然后利用电子表格做成的复杂管理工具列出摄影师和任务安排，跟踪其工作动态。

很快，这套系统变得不堪重负。于是他们又招来了雪城大学（Syracuse University）的Ellie Thiele作为暑期实习生，随后又把摄影师管理当作了她的全职工作。通过把主要精力集中在拍摄管理上，Ellie得以将活跃摄影师的数量增加到了50个。只有到了这个时候Airbnb才上马了真正具备扩张性的解决方案：软件。Nathan写了一点代码，给网站增加了2个按钮：一个是给房东请求摄影师的，另一个是在摄影师完成拍摄任务后给Ellie启动支付的。最终，创始人招聘了Joe Zadeh作为入门级的工程师，让他跟Ellie一起工作将拍摄的流程完全自动化。

Airbnb在开发任何代码之前用了3种不同的方式来处理拍摄的问题，并在此后重写了数次拍摄系统。对于Airbnb来说一开始做一个全自动的拍摄管理系统没有意义；等到公司走上这条道路时，网站每天大概才有10位左右的访客，唯一的工程师资源只有Nathan Blecharczyk。他在这个问题上做的任何工作都会导致Airbnb其他需要完成的业务发展方面的工程工作产生延误。通过去做无法扩张的事情，该公司得以在资源受限的情况下发展，尽管后来“废弃”了电子表格等临时的管理手段。

规则#7：无视你的客户

（编辑：PHP编程网 - 钦州站长网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!