前 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 表格，是早晚都要被棄用的。
第七條原則： 無視你的客戶
客戶服務的基本原則，始終都是「客戶永遠是對的」。但是，對於許多「閃電式擴張」階段的公司而言，有個核心原則：「只要不減慢公司發展速度，就可以提供任何服務；而一旦發現被客戶拖了後腿，寧可不提供服務。」 許多「閃電式擴張」的創業公司，早期只提供郵箱客服支持或者根本沒有客服，依靠用戶論壇互助解答問題。
總的來說，無視用戶很難被認為是一種積極的態度。用戶希望被傾聽，如果總是無視他們的聲音，最終會耗盡他們對公司的好感。但對於「閃電式擴張」階段的公司來說，用戶覺得被無視只是諸多火苗中的一個，你可以在撲滅更致命的火焰之前，讓它先燒一會。
原文地址：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 協議
閱讀更多 人人都是產品經理 的文章
