时间: 2021-07-30 11:51:05 人气: 5 评论: 0
前 PayPal COO、LinkedIn 联合创始人Reid Hoffman 最近回顾了自己在 PayPal 和 LinkedIn 等公司的经历，总结出公司极速扩张时的 7 个「反直觉」管理原则。光涧实验室（ID：lightstream0）邀请小伙伴金玉将文章翻译成中文，希望好的创业方法论文章有机**被更多人看到。
谈到创业公司，总是离不开「增长」和「急速扩张」。「急速扩张」感觉还是不够准确，所以我发明了一个新词「闪电式扩张」（blitzscaling）。一个公司实现「闪电式扩张」不是件容易的事情。如果它很容易，大家早就一拥而上了。
和世界上多数珍贵的事物一样，闪电式扩张也需要逆向思考。这时候想要成功，就要抛弃追求高效率和风险最小化的常规管理原则。
无论是早期创业团队，还是传统企业，如果想在充满变化和不确定的市场上，达到野心勃勃的增长目标，就需要接纳一套全新的「最佳实践」，即使它与商学院经典案例背道而驰，且与直觉相悖。
传统公司希望通过年度规划和营收预期做到管理有序，运行平稳和财务目标明确，这是说的通的。
公司可以通过目标和规划在运营过程中有效的调整方向，还能够让投资人得到舒适的稳定感。
但是在闪电式扩张时，效率将让位于速度。从追求有序规律，变成主动去拥抱让哈佛商学院的 MBA 和教授都头疼不已的一**混沌。
当然，放手去干并不代表就能获得成功；屈从混沌本身不是获胜的正确方法。拥抱混沌，意味着接受不确定的存在，并一步步去掌控它。
正如预见到错误即将发生时，一个人不**袖手旁观，坐等解决办法找上门来；也不**没有任何准备和规划就贸然前行。即便结果不确定，仍可以依据可能性评估，作出正确的决策。
最重要的是：与此同时你可以确定自己开始具备修正错误的能力。
回顾诸多硅谷公司的发展历史， 任用高管都是期待能力**强的个人能够拉动团队和业务快速成长，也意味着该聘用有过大公司工作经验的人，期待在未来某个阶段他的经验能够发挥作用。
现在的创业圈里，这个规则已经不再适用了。达尔文主义物竞天择的**是如此的残酷，每一个团队在当下都要竭尽全力。你只需要满足的公司现在这个阶段管理层，不必为未来焦虑。
不同发展阶段所需的管理技能完全不同，请一个管理过 1000 人团队的人来运作一个 10 人的项目，结果往往适得其反。任用适应当下的人也意味着明白他们在时移势易的时候需要退出。
举个例子：也许一个了不起的设计师非常擅长个人独秀，但在设计团队里却完全无法发挥作用。
当业务开始「闪电式扩张」时，速度要比运转良好更重要。
对于团队的管理，一般意义上都是尽量保证组织成员稳定和团队的配合度。定位不清和人员流动**导致内部人员的紧张和情绪低落。
一旦业务进入到高速扩张的阶段，可能一年内公司就要重组数次，管理团队需要反复调整；当业务年度增长率达到 300% 时，就要提前安排部分有潜力的人升职，并把那些「划水」的人清理出去。
无需浪费时间等待，决策和行动越快越好；环境的变化不随人的意志而转移，一直在变化，团队和公司要同步成长。
为了与成长速度契合，人事调整可能有时就**快到出乎所有人的意料。
以 PayPal 为例，当 PayPal 在获得巨大成功的时候，并没有衬得上已有业务规模的管理制度。
接下来我要借用其中一位高管的口吻来讲述：
「有一些事情我们做的还不错，比如确保每个员工都有明确的核心工作，参与重要项目的时候能够保持专注。但总体上， PayPal 的管理就是没有管理，没有对员工的一对一的职业发展指导，组建项目团队选人也没有固定标准。」
Paypal 的「没有管理即是管理」证明快速扩张就需要跳出常规意识。
当 Paypal 在形成商业模式创新和业务快速增长的过程中，也曾遇到过一系列需要面对的生死存亡的节点，用我的话说，都是一些 「Oh shit!」时刻：
因为 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 协议
