时间: 2021-07-30 11:51:07 人气: 2 评论: 0
PayPal 帮的大佬之一、LinkedIn创始人Reid Hoffman最近在研究创业的方法论。
PayPal帮的大佬之一，职业社交网络LinkedIn创始人Reid Hoffman最近在研究创业的方法论。在《扩张之道》系列播客中，他访谈了不少的初创企业创始人，跟他们讨论了初创企业应该如何快速发展的问题，并且杜撰出了“闪电式扩张”这个词。
闪电式扩张，是指面临不确定性的情况下为了追求快速增长优先考虑速度而不是效能。Reid Hoffman提出，为了实现闪电式扩张，你必须违反常识。在本文中，他列举了7条有违直觉的扩张原则。
说到初创企业，主题总是成长性，然后是**快的增长——我喜欢用“blitzscaling（闪电式扩张）”来形容。公司实现闪电式扩张并不容易，如果容易的话，大家都**这么做了。就像这个世界上大多数有价值的东西一样，闪电式扩张也是逆势而为的。要想成功，你必须违背众多的管理“原则”，因为那些原则的主旨是效率和风险最小化。
实际上，在面临着不确定和变化的情况下要想实现你那积极的成长目标，你需要遵循一套新的原则，这些原则跟商学院教的东西背道而驰，彻底有违接受早期阶段初创企业或者典型企业管理“最佳实践”的直觉。
年度计划、收入指导。传统企业总是努力实现管理、运营与财务结果的有序和规则性。
这种对于秩序和规则性的渴望是说得过去的，因为这使得公司可以调整自身的做法，尽可能地高效，让股东有令人满意的稳定感。但当你进行闪电式扩张时，就是明确选择了为了速度而牺牲效能。
这意味着传统专注于秩序和规则性需求让位于拥抱一定程度混乱的独特意愿，这**让大多数哈佛MBA和他们的教授感到恐惧。
但是放任不管是不大可能带来成功的，被动地屈从混乱并非取胜之道。拥抱混乱，从另一个意义来说，意味着存在不确定性。因此，需要采取步骤去管理。如果你知道自己**犯错误，回应不是坐下来等待答案找上门来，也不是在没有准备或者事先考虑的情况下盲目前进。哪怕缺乏确定性，你仍然可以根据对概率的估测做出明智决策。也许最重要的是，你可以确保自己有能力改正错误。
从硅谷的大部分历史来看，初创企业招聘高管的传统智慧是迅速引入一名能给企业实现扩张的高管。这意味着要招在更大组织有过经验的人，其想法是他们的经验**在后面阶段发挥作用。
招一个曾管理过1000人的人运营一家10人规模的小公司其实是有违直觉的。
在今日的初创企业世界里，这条规则不再见效。优胜劣汰式的竞争如此激烈，以至于你的组织需要全身心投入到当前阶段的扩张当中。你需要“适合”当前阶段发展所需的经理和高管。毕竟，如果你的团队不能把公司带到下一阶段的话，你就不必担心下一阶段的事情。
招一个曾管理过1000人的人运营一家10人规模的小公司其实是有违直觉的，因为在这两个阶段取得成功所需要的技能其实是很不一样的。
雇Ms. Right Now一部分也意味着当通过了某一个时刻时什么时候该让某人走。比方说：一个伟大的设计师也许擅长做一场单人秀，但作为一支更大的设计团队的一员，其效率却未必那么高。
在进行闪电式扩张时，速度要比有一个“运营得当”的组织更重要。在正常情况下，你应该努力争取组织的凝聚力和稳定性。无秩序、不稳定的组织**让员工感到紧张、影响士气。
但当你以光速来进行扩张时，你1年时间内也许就得对公司重组3次，或者管理团队成员也**反复地进进出出。当你的组织以每年300%的速度的发展时，你可能就得在手下准备好之前提拔人，然后在发现他们在溺水而不是在游泳时把他们换掉。你没有时间保持耐心，等着情况好转，你得迅速而果断地采取行动。
总**有很多的变化，而且其中很多都不是自发的。你是在同时建设团队和公司，出于速度的考虑，你可能**减少做出和实现重要决定所需的时间，这一点甚至连你的人都感到吃惊。
就拿PayPal作为例子吧。尽管PayPal取得了巨大成功，但这家公司在管理上却是非常糟糕——我在担任其资深经理时曾下过这个结论。我们做出一些好决定，比如：确保每一位员工都有一项明确的主要工作并且在致力于特定的重要项目时保持专注，但大多数时候，PayPal的管理情况其实都是缺乏管理的。除了选出谁属于哪个团队以外，在团队组建上基本上不做任何工作。
但是PayPal的“糟糕”管理在闪电式扩张时却提供了一些有违直觉的优势。在PayPal形成自身商业模式创新及进行扩张的关键时刻，我们曾经历过一系列孤注一掷式的挑战，或者按照我的说法，经历过不少的“Oh shit!”时刻。
妈的该死，我们存在欺诈问题，我们亏了几百万美元。噢该死，Visa说我们并且变更产品不然他们就让我们关门大吉。噢该死，我们最重要的商业伙伴eBay，刚刚创立自己的企业直接跟我们竞争。
因为我们的“糟糕”管理，我们对“这就是3年内公司必须发展成的样子”并没有任何预设的概念。我们管理上混乱的本质，其实让我们在面临这些严重的意料之外的地雷时，能保持敏捷。
当组织的每个人都有不明确的、处在变动中的角色时，说“我知道这是你在过去4天所做的事情，但是现在我们要换事情干了”就**显得更容易些。内部的混乱有着让激进变化正常化的作用，这意味着我们的人能够更好地对外部世界扔给我们的剧烈变动进行调整。
这么说不是叫你要炮制糟糕产品。相反，如果你需要在拿一个不完美的产品迅速上市与慢慢打磨一个“完美”产品上市之间做出选择的话，几乎每一次都要选择不完美的产品。快速上市，让你可以开始获得改进产品所需的反馈。
任何根据你的直觉而不是根据真实用户的反应和数据而精心调制的产品，都有可能错失目标，且需要显著的迭代。速度真的很重要，早点推出让你可以更快地攀上成就更伟大产品的学习曲线。
我是通过非常深刻的方式才学**这点经验的，当时我还在做自己的第一家初创企业SocialNet。我不想发布的第一版产品给自己带来尴尬，所以我们采取的方案是把产品做完整之后，再拉开窗帘让大家注册。
这种做法让pulled back the curtain的推出延误了1年，当我们终于推出产品时，我们迅速意识到我们煞费苦心实现的一半功能其实并不重要。而那些重要的，如果没有我们的服务就**变得没用的东西里面有一半都没有，因为我们并没有想到。尽管SocialNet失败还有其他的理由，但没有尽早推出并且根据市场反馈迭代可能是产品思维的主要原因。
根据我在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万用户档案的临界规模，随后就是历史了。
记住，你应该对自己的第一版感到尴尬——但不是感到难为情或者有罪！对速度的渴望不是走危险捷径的借口。如果你引起了法律诉讼或者没学到东西就把钱烧光了，这就意味着你推出得太早了。
在闪电式扩张的每一个阶段，需要引起你注意的问题总**你手头可以用来处理的资源要多得多。你可能感觉自己像一位救火队员，只不过你要救的不是一个密闭容器喷出的火焰，而是看到周围全都是火苗——而且你还没有时间把它们全都扑灭。
进行闪电式扩张的创业者还能留条活命的办法之一，是决定让哪些火自生自灭（如果可以让它们这样的话），从而把关注焦点放在**真正毁了公司的那些火点。
我在Greylock的同事Joseph Ansanelli曾经说过：“你拒绝的东西要比你同意的东西更加重要。”
你无法永远对那些火视而不见——其实那些火也是危险的，而且最终也需要你的关注，但是在闪电式扩张的大多数时候这些问题都不算是性命攸关的，因为扑灭这些火并不能对产生预期结果起到一点作用。
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其他需要完成的业务发展方面的工程工作产生延误。通过去做无法扩张的事情，该公司得以在资源受限的情况下发展，尽管后来“废弃”了电子表格等临时的管理手段。
客户服务的基本原则一直都是“客户永远是对的。”但对于许多闪电式扩张公司来说，关键的规则是“提供任意的客户服务，只要不**这些服务不**拖累你的发展——而这也许意味着没有服务！”
许多闪电式扩张型初创企业一般只提供电子邮件支持，或者根本没有支持，只能靠用户在论坛上面寻找或者相互帮助。
从绝对的意义而言，无视你的客户几乎不**有积极意义。客户喜欢被倾听的感觉，无视他们最终**耗尽公司的商誉。但对于闪电式扩张型公司来说，放任客户的被忽视感往往是你更容易放任点燃的火点，因为你还有更大更致命的火要扑灭。
译文：https://36kr.com/p/5161482.html?ktm_source=feed&tdsourcetag=s_pctim_aiomsg
编译：郝鹏程
本文由 @郝鹏程 授权发布于人人都是产品经理，未经作者许可，禁止转载
