前 PayPal COO、LinkedIn 联合创始人Reid Hoffman 最近回顾了自己在 PayPal 和 LinkedIn 等公司的经历，总结出公司极速扩张时的 7 个「反直觉」管理原则。光涧实验室（ID：lightstream0）邀请小伙伴金玉将文章翻译成中文，希望好的创业方法论文章有机会被更多人看到。
谈到创业公司，总是离不开「增长」和「急速扩张」。「急速扩张」感觉还是不够准确，所以我发明了一个新词「闪电式扩张」（blitzscaling）。一个公司实现「闪电式扩张」不是件容易的事情。如果它很容易，大家早就一拥而上了。
和世界上多数珍贵的事物一样，闪电式扩张也需要逆向思考。这时候想要成功，就要抛弃追求高效率和风险最小化的常规管理原则。
无论是早期创业团队，还是传统企业，如果想在充满变化和不确定的市场上，达到野心勃勃的增长目标，就需要接纳一套全新的「最佳实践」，即使它与商学院经典案例背道而驰，且与直觉相悖。
第一条原则： 接纳混沌
传统公司希望通过年度规划和营收预期做到管理有序，运行平稳和财务目标明确，这是说的通的。
公司可以通过目标和规划在运营过程中有效的调整方向，还能够让投资人得到舒适的稳定感。
但是在闪电式扩张时，效率将让位于速度。从追求有序规律，变成主动去拥抱让哈佛商学院的 MBA 和教授都头疼不已的一片混沌。
当然，放手去干并不代表就能获得成功；屈从混沌本身不是获胜的正确方法。拥抱混沌，意味着接受不确定的存在，并一步步去掌控它。
正如预见到错误即将发生时，一个人不会袖手旁观，坐等解决办法找上门来；也不会没有任何准备和规划就贸然前行。即便结果不确定，仍可以依据可能性评估，作出正确的决策。
最重要的是：与此同时你可以确定自己开始具备修正错误的能力。
第二条原则：招聘适合当下的人，而不是强人
回顾诸多硅谷公司的发展历史， 任用高管都是期待能力超强的个人能够拉动团队和业务快速成长，也意味着该聘用有过大公司工作经验的人，期待在未来某个阶段他的经验能够发挥作用。
现在的创业圈里，这个规则已经不再适用了。达尔文主义物竞天择的理论是如此的残酷，每一个团队在当下都要竭尽全力。你只需要满足的公司现在这个阶段管理层，不必为未来焦虑。
不同发展阶段所需的管理技能完全不同，请一个管理过 1000 人团队的人来运作一个 10 人的项目，结果往往适得其反。任用适应当下的人也意味着明白他们在时移势易的时候需要退出。
举个例子：也许一个了不起的设计师非常擅长个人独秀，但在设计团队里却完全无法发挥作用。
第三条原则： 容忍「管理不善」
当业务开始「闪电式扩张」时，速度要比运转良好更重要。
对于团队的管理，一般意义上都是尽量保证组织成员稳定和团队的配合度。定位不清和人员流动会导致内部人员的紧张和情绪低落。
一旦业务进入到高速扩张的阶段，可能一年内公司就要重组数次，管理团队需要反复调整；当业务年度增长率达到 300% 时，就要提前安排部分有潜力的人升职，并把那些「划水」的人清理出去。
无需浪费时间等待，决策和行动越快越好；环境的变化不随人的意志而转移，一直在变化，团队和公司要同步成长。
为了与成长速度契合，人事调整可能有时就会快到出乎所有人的意料。
以 PayPal 为例，当 PayPal 在获得巨大成功的时候，并没有衬得上已有业务规模的管理制度。
接下来我要借用其中一位高管的口吻来讲述：
「有一些事情我们做的还不错，比如确保每个员工都有明确的核心工作，参与重要项目的时候能够保持专注。但总体上， PayPal 的管理就是没有管理，没有对员工的一对一的职业发展指导，组建项目团队选人也没有固定标准。」
Paypal 的「没有管理即是管理」证明快速扩张就需要跳出常规意识。
当 Paypal 在形成商业模式创新和业务快速增长的过程中，也曾遇到过一系列需要面对的生死存亡的节点，用我的话说，都是一些 「Oh shit!」时刻：
- Oh shit，我们遇到了恶意点击，我们损失了好几百万美元。
- Oh shit，信用卡组织 Visa 反馈说如果我们不修改产品，他们就要停止合作。
- Oh shit，最重要的合作伙伴 Ebay 居然在开发一个我们的直接竞品。
因为 PayPal 的「没有管理」，我们从不去预想「未来三年这家公司会是什么样子」，混沌的管理方式让我们灵活应对各种挑战。
团队中每个人都有相对灵活的定位时，就比较容易说：「的确，你花了四天时间在这个项目上，但是现在我们得换个方向。」团队成员因为混沌管理得以快速进化，也就意味着具备更好的能力去面对频出的外部挑战。
第四条原则：让你感到尴尬的产品也要发布
尴尬的产品并不意味着垃圾产品。如果要在「快速发布一个不完美的产品」和「延期发布一个相对完美的产品」之间做选择，务必选择前者。
快速上线意味着能够及时得到改进方法——缺乏用户反馈和数据，仅仅基于个人直觉的产品改进是错误方式，并且会需要更多的迭代去弥补错误。
速度是关键，越早上线发布能够越快接近最终目标。
在我做第一个创业项目 Social Net 时，我付出了相当的代价才学到了这一课。那时我不想仓促的就把产品推出去，于是花了很长时间去打造一个完整的产品，产品发布推迟了一年时间才开发给终端用户。
上线之后我们很快发现：费尽心力开发出来的功能里有一半都是边缘功能，另一半与产品服务强相关的功能因为考虑不周被忘记了。
当然 Social Net 失败有很多原因，但是最关键在于没有快速上线和没有基于市场的反馈去迭代。
在经历过在 PayPay 通过快速上线迭代打造了成功产品之后，我决定尽可能快的推出 LinkedIn 这个产品。
团队以快速上线为目标定义了一个最小化的功能列表，几年后 Steve Blank 和 Eric Ries 将它定义为最小可用产品 MVP（译注：Steve Blank，硅谷创业家，在斯坦福与伯克利大学教授创业课程，《硅谷秘史》的作者。Eric Ries《精益创业》的作者）。LinkedIn 的 MVP 版本的功能包括用户职业履历，关注其他用户，搜索其他用户和发私信功能。
快要上线前我们开始担心，如果没有一定量的用户 LinkedIn 就失去了它的用途。假如一个用户注册之后，他在这个平台上找不到熟悉的朋友，什么能让这个产品对用户产生价值？
我们觉得可以添加「查找手机通讯录已有的联系人」功能，这样 LinkedIn 的用户可以通过这个功能，寻找潜在合作伙伴。
开发团队评估后反馈，开发这个功能需要一个月的时间。 这时候我们遇到了两难选择：延迟发布一个月或者上线一个缺失了关键功能的版本，而这个功能也许就是产品成功与否的关键。
基于不惧尴尬的原则，我们发布了没有「查找手机通讯录已有的联系人」的版本。紧接着我们发现一个更严重的问题，和熟人社交的代表产品 Friendster 不同，LinkedIn 的用户没有邀请他们的朋友来注册——基于用户分享裂变拉动增长的策略就此抛锚。
原型产品的问题在于因为没有使用者，即便我们延迟一个月添加上「查找手机通讯录已有的联系人」功能，没有足量使用者的情况也不会改变，反而意味着我们浪费了一个月的时间开发出了一个非核心的功能。
我们预估至少需要一百万注册用户，达到目标之前搜索功能和「查找手机通讯录已有的联系人」功能都是次要的，提升用户量才是最高优先级的问题。
基于上线后的数据反馈，我们专注在提升用户分享率。LinkedIn 成为第一个提供上传通讯录功能的社交网络平台，这个功能让 LinkedIn 跨过百万用户的临界值，其余的故事就是众所周知的了。
但也要记住，初始版本会让你感到尴尬，但还不至于感到耻辱。追求速度并不是把自己逼到危险角落的借口。
如果产品导致法律纠纷或浪费完预算却没学到任何东西，那就意味着确实上线太仓促了。
第五条原则：让火再烧一会
闪电扩张的每个阶段，都会有各种各样需要解决的问题，精力和资源总是不够分配。你会感觉自己像没有具体任务的消防员，而且周围都是火苗，没有时间将它们一一消灭。
长于快速扩张的创业者的生存秘诀是：专注去扑灭那些对公司生死攸关的火焰，让其他的火先烧一会。 我在 Greylock（硅谷创业投资机构）的同事Joseph Ansanelli说过：说「不」比说「是」更重要。
那些着火点的存在就是风险，你并不能一直忽视它们，早晚都需要去解决。但是在闪电式扩张的过程中它们不是关键，即便解决掉它们也并不能达成最终目标。
第六条原则： 去做无法规模化的事情
YC（硅谷知名创业孵化公司）的联合创始人 Paul Graham 写过一篇著名的文章。建议创业者要从小事做起。这条建议不仅适合那些早期创业项目，对快速扩张中的那些创业公司来说同样重要。
工程师普遍反感一次性工作，不只因为浪费，还与他们效率最大化的价值观相悖。
工程师坚信：产品应当一开始就设计完善，从而避免不断返工。
但在闪电式扩张中，无法复用的代码是普遍的存在。
速度是第一优先级，不需过多考虑安全性，不用去写可扩展的代码；某些功能在测试工具和流程完成之前就已完成历史使命。
这样的选择的确可能在未来导致一些问题，但如果在搭建产品的过程中花费太多的时间，就不再有未来了。
只需要十分之一时间的 Hack 手段，往往比精心设计的技术解决方案更高效，即使 Hack 手段很快就不得不被弃。
公司的各个方面都适用这个逻辑。在业务起步的时候，大多做的都是一些非规模化的事。Salesforce 的创始人 Marc Benioff 为公司争取到的第一个客户—— Blue Martini Software 公司——就是靠着跟这家公司 CEO Monte Zweben 的个人交情。Paul Engligh 曾把个人手机号用作 Kayak 公司（客涯，一款旅游工具产品）的客服电话专线，诸如此类的例子非常多。
「无法规模化」和「可以规模化」是没有严格区分的，前者会逐步转化为后者。可复用的代码和业务流程，在闪电式扩张的过程中下很快就会失去价值，替代方案同样是不可复用的。
Airbnb 的创始团队是怎么解决房屋照片质量差的问题的？他们决定自己去做摄影师。（注：在 Airbnb 的网站上，高质量的房屋照片能够大幅提升用户对于房子的好感度。）Brian Chesky（Airbnb创始人）告诉我：「我们从罗德岛设计学院的朋友那里借到了相机，然后逐个去敲房东的门。」
Brain Chesky 和联合创始人 Joe Gebbia 每天可以完成 10 个 房子拍摄工作。（另一位联合创始人 Nathan Blecharczyk 要守在当成办公室的公寓里，确保网站正常运行）。看看他们都是怎么做小事的。
Airbnb 的业务开始增长之后，房屋图片管理很快变成规模化的需求。于是他们想了更多的办法，比如从 Craiglist 上雇摄影师（译注：Craiglist 是美国分类广告网站，美国的 58 同城和赶集），请学院里的朋友们帮忙，招募 Airbnb 上爱好拍照的房东。Airbnb 利用这些资源搭起了一个 5-10 人的摄影团队，每套房子只需要 50 美元的拍摄成本， 他们用 Excel 表格列出所有摄影师，然后给摄影师分配任务。
很快这套体系就不能满足需求了。于是他们聘请了雪城大学的 Ellie Thiele 作为暑期的实习生来专门管理摄影团队。除了图片管理的工作之外，Ellie 把活跃摄影师数量扩展到了 50 个。
到了这个阶段 Airbnb 才开始使用规模化的解决方案：开发软件。联合创始人 Nathan Blecharczyk 写了一些代码，给网站添加了两个按钮：一个给房东提供「需要上门拍摄」功能，一个给实习生 Ellie Thiele，在摄像师完成工作之后发放酬劳。很久以后，团队聘请了 Joe Zadeh （译注：现在 Airbnb 的产品总监）作为初级开发工程师和实习生 Ellie Thiele 一起完成了的图片管理的自动化流程。
在搭建程序之前，Airbnb 用了三种不同方法去解决房屋图片管理的需求，之后也多次进行了图片管理系统的重构。Airbnb 早期搭一个可以规模化运作的系统没有任何价值。那时候的 Airbnb 网站每天只有 10 个访问用户，联合创始人 Nathan Blecharczyk 是唯一的技术资源。
他在照片处理上花费的每一分钟时间都是在耽搁其他工程任务，进而影响业务的增长。他们用一系列的无法规模化的手段解决了问题，把有限的资源都投入到业务上，尽管那个用来给摄影师分配任务的 Excel 表格，是早晚都要被弃用的。
第七条原则： 无视你的客户
客户服务的基本原则，始终都是「客户永远是对的」。但是，对于许多「闪电式扩张」阶段的公司而言，有个核心原则：「只要不减慢公司发展速度，就可以提供任何服务；而一旦发现被客户拖了后腿，宁可不提供服务。」 许多「闪电式扩张」的创业公司，早期只提供邮箱客服支持或者根本没有客服，依靠用户论坛互助解答问题。
总的来说，无视用户很难被认为是一种积极的态度。用户希望被倾听，如果总是无视他们的声音，最终会耗尽他们对公司的好感。但对于「闪电式扩张」阶段的公司来说，用户觉得被无视只是诸多火苗中的一个，你可以在扑灭更致命的火焰之前，让它先烧一会。
原文作者：Reid Hoffman
原文地址：https://medium.com/s/story/7-counterintuitive-rules-for-growing-your-business-super-fast-9dcdc2bfc649
原文标题：7 Counterintuitive Rules for Growing Your Business Super-Fast
翻译：金玉 / 光涧实验室（公众号：lightstream0）
本文由 @金玉 翻译发布于，未经许可，禁止转载
题图来自 Unsplash，基于 CC0 协议
