編者注：本文來自被譽爲當代創新大師的Steve Blank的博客， 中文版由天地會珠海分舵編譯。全文從當今很多人對精益創業的誤解作爲一個切入點，深入的分析了爲什麼人們這麼容易就對精益創業產生誤讀，然後提出了自己獨到的解決方案...
迷失精益創業
業界的所謂磚家們對精益創業所提倡的"Build(打造) - Measure(衡量) - Learn(學習)"模式的詬病和抱怨已經不是一天兩天的事情了，但每次當我聽到他們說這無知的話的時候我依然會感到無比的喫驚:
“這模式無非就是將一個半成品快速的投入市場進行試水而已。“
何以至此呢？很不幸，之所以讓人困惑的原因恰恰正是因爲精益創業中的這個“打造-衡量-學習”模型圖而引起的，因爲咋一看這模型圖的順序，這完全是一個本末倒置的東西嘛！這就好比你作爲射擊教練去教學生射擊的時候卻喊着口號：“射擊 - 準備 - 瞄準“ 一樣。
時至今日，精益創業已經大行其道很長一段時間了，我們也已經摸索出其中如何才能真正的去“精益”的進行創業的祕訣。所以，爲了以正視聽，我認爲現在是時候對這個“打造-衡量-學習”模型進行相應的更新了。
那麼我們下面就看看應該如何進行更新吧，請看官們耐心往下看。
“打造-衡量-學習”，這聽上去其實是一件異常簡單的事情。無非就是先打造出一個產品，然後把它丟到市場上面去，然後去收集並衡量客戶的反映以及反饋，然後從中進行學習，最後根據學習的結果進一步打造出更好的產品。這是一個不斷循環的過程，過程中你需要根據上一輪學習的結果去決定在本輪中，你是需要在已有產品的基礎上進行進一步的迭代呢，還是需要挖掘出一個新的方向，然後重整旗鼓換條道路前進，又或者是需要全盤推翻從頭再來。最終能跳出這個循環的出口只有一個，就是當你能打造出客戶真正喜歡的產品的時候。
閉門造車的困局
雖然這聽上去很簡單，但相對於貫穿整個20世紀所使用的瀑布式開發來說，“打造-衡量-學習”模型可以算得上是一項徹底的變革了。那時候，企業家們是在幾乎沒有獲得任何用戶反饋的情況下，運用一系列的產品研發流程來進行產品打造的。這些公司創始人會在假設自己已經很清楚客戶碰到的問題或者客戶的需求的前提下，開始進行需求文檔(ERD)的編寫，進行產品的設計，進行硬件/軟件的實現/構建，然後對硬件/軟件進行測試以驗證其和需求文檔的描述是吻合的，最後就會以首批出貨(FCS)的形式向潛在客戶揭開產品的神祕面紗。
瀑布模型所做的事情其實就是去將需求文檔進行編碼實現。雖然產品的 Alpha版本和Beta版本最終還是會邀請客戶一起進行測試和驗收，但是，這時客戶介入的目的其實已經不是爲了對你的產品的功能或者易用性提供反饋，而僅僅是去看下你的產品是否完全按照需求文檔去進行實現，是否存在缺陷而已了。
在這種情況下，只有在產品真正的賣給客戶之後，我們的初創公司才能獲得客戶來的有實際意義的反饋。而事實往往更悲催的是，在你的產品經歷了幾個月甚至幾年的閉門造車的開發過程之後，你最終卻發現客戶根本就不會付錢買你的產品，因爲他們可能壓根就不需要你的產品所提供的大部分功能！
瀑布開發模式下，一個產品往往需要經歷三個版本才能真正走向正軌滿足客戶的需求。第一個版本毫無疑問是個閉門造車的產物了，根本沒有用戶反饋可言，所以就更談不上滿足客戶需求了。而第二個版本的開發往往又是在第一個版本還沒有完全獲得用戶大量反饋之前，就已經密鑼緊鼓的開始的了。所以，我們往往只能在第三個版本中才能真正基於用戶的反饋進行產品的打造(其中微軟的Windows3.0這個產品的開發過程就是一個很典型的例子)。
到了2000年初，敏捷開發逐漸成爲軟件開發的最佳實踐方式。這種方法通過引入迭代和邀請用戶參與的方式來對陳舊的瀑布開發模式進行大幅的改進。這其實已經是一個很大的進步，但問題是它沒有一個行之有效的框架來指導我們如何在市場上驗證那些商品化方面的猜想。所以在這種情況下在你的產品開發過程中盲目的運用敏捷開發的話，就算你將一個客戶所要求的所有功能都實現了，你的產品也難免會碰上滑鐵盧而最終鎩羽而歸。
這時，精益創業所提倡的“打造-衡量-學習”這個框架模型就應運而生了！
一波未平一波又起
“打造-衡量-學習”關於這個“打造-衡量-學習”的循環，首先我們必須明白這個循環的目的並不是要去讓我們打造出一件最終的產品或者產品原型，而是爲了讓我們在不停的迭代和增量開發的工程中最大化我們對要打造的產品的學習。（這裏的學習包括產品功能，客戶需求，產品定價以及銷售渠道等等...）而“打造”指的當然就是就是去打造出一個MVP(最小可行化產品)了。這裏並不是說你只去實現你的產品的一小部分功能就叫做MVP了，明白這一點是非常重要的。事實上，MVP指的應該是一個可以讓你快速給客戶演示並快速獲得用戶的反饋以進行學習的那麼一個最簡單可行的東東。
在創業早期，MVP可以僅僅是幾張PPT幻燈片，也可以是一幅線框圖，更可以是一個模型，甚至可以只是一些採樣數據而已。在你每次進行一個MVP的打造之前，你都需要先去定義好在該MVP中你所需要測試/衡量的究竟是什麼東西，然後你纔能有針對性的對你的產品、市場和客戶等進行學習和認知。隨着這方面知識的積累，你的MVP慢慢自然而然的就會往用戶真正需要的產品這個目標靠攏。但此時可別得意忘形了，在往下的迭代週期中，你的目標依然是爲了繼續最大化你的學習，而不是去給你的最終產品打造個產品原型或者Beta版本。相對瀑布模型來說，“打造-衡量-學習”模型令創業變得更爲簡單，靈活而且有效率。
精益創業中常用上圖對“打造－衡量－學習”這個模型對其進行闡述。但是把“打造”這個詞放在整個流程的首位往往會讓人困惑。如前文所述，這讓人咋一看是有種本末倒置的感覺。因此，爲了幫助我們能更好的瞭解精益創業的這個模型，我們還需要加入另外三個元素。所以最終更細化的一個版本就出來了：“創意－打造－編碼－衡量－數據－學習”。
“打造－衡量－學習”的這個細化版可以讓我們對容易讓人困惑的”打造“這個詞的本意有更好的認知，讓人們清楚的知道”打造”的目的是要去測試驗證你對產品的”創意“，而非”無的放矢“的盲目地去進行產品開發。而其中的“編碼（Code）”很好理解，指的就是如何的對產品進行編碼實現，當然，如果不是軟件行業的話，你也可以簡單的將其替換成“硬件開發”或“人造基因研發”。而“數據（Data）”意思是當我們的MVP發佈給用戶使用後，我們將會獲得用戶的反饋，然後我們會對獲取回來的反饋進行衡量，如找出哪些是有效的或者無效的、有用或者無用的數據，以便我們在下一步可以更深入的對這些數據進行學習。而這些學習回來的新認知又將會反過來影響我們下一輪循環迭代的”創意“。所以在此我們可以很清晰的認識到，“打造－衡量－學習”的目標並不僅僅是爲了打造MVP而打造MVP，而更應該是有針對性的去爲了驗證你的創意而進行MVP的打造。
一旦你認識到這一點，那麼你就會清楚“打造－衡量－學習”這個模型的並非如上文中磚家們所質疑的”這模式無非就是將一個半成品快速的投入市場進行試水而已。“，相反，該模型的關注點應該是在如何測試驗證你的產品的”創意“。
那麼這是否就足夠了呢？答案是否定的，我們其實可以做的更好！
精益創業需改進，從猜想開始！
“打造－衡量－學習”這個模型其實還是缺了那麼點東西，它忘了一個新產品產生之前其實都不是由創意(無論是初創企業的創意還是一個成熟企業開發新產品的創意)開始的，而是從一些還不明朗的對產品的一些猜想(其實就是”猜測“更冠冕堂皇的說法而已)開始的。
創意和猜想是兩個截然不同的東西，這一點非常的重要。對於大部份創新者來說，創意就是對產品的洞悉，一旦有了創意，就需要立刻制定詳細計劃來將之付諸實現以產生成果的。相對來說，”猜想“指的是，我們現在已經有一個根據經驗而來的猜想，但還需要一些實驗/試驗以及相應的數據來證明其究竟是可行還是不可行的。
這些猜想覆蓋面非常之廣，我們的目的就是要驗證這些猜想以確定我們的產品應該如何進行打造。從找出誰是目標客戶，到如何確立產品的價值主張，到如何給產品定價，到如何找到並打通銷售渠道，再到如何創建需求(獲取用戶，激活用戶，黏住用戶，等等等等...)，這些都需要進行驗證才能確定的。
事實上，如果你真要進行精益創業的話，承認自己的創意其實只是一系列未經證實的猜想是一個非常重要的開始。之所以說它重要，是因爲你所打造的東西應該是爲去驗證你的猜想而服務的。
你要知道，爲了驗證誰是真正潛在的客戶所打造的MVP和爲了驗證產品定價所打造的MVP的要求是不一樣的，而用於測試新功能所需要打造的MVP又是另外一回事。另外，這些猜想（及MVP）會隨着你不停的學習積累而不停的產生變化。
綜上所述，我們去打造我們的MVP的時候所運用的精益創業的框架更應該是"猜想 - 實驗設計 - 驗證 - 洞悉”，而非原來的“打造 - 衡量 - 學習”。
如何構建猜想
如果運用“猜想 - 實驗設計 - 驗證 - 洞悉”這個新的框架，那麼問題將會變成：有哪些猜想我們是應該去驗證的？關於這個問題，Alexander Osterwalde在它的商業模式畫布中早就將商業上需要驗證的九個模塊壓縮成一張可視化的圖來讓你一目瞭然了。請看下圖(如果看不清楚的話可以直接點擊這裏進行查看)。
-
價值主張：公司通過其產品和服務所能向消費者提供怎麼樣的價值？
-
客戶細分：例如是普通用戶還是付費用戶，是家庭主婦還是年輕人？
-
銷售渠道：如何找到目標客戶，並向其提供你的產品的價值主張？
-
客戶關係：如何創造更多的需求？
-
收益流：如何通過價值主張而獲得收入來源？
-
活動: 如何執行必須的活動來實現你的商業模式？
-
資源: 如何獲得活動所需要的資源？
-
第三方合作伙伴: 如何獲得別人的支持以令你的活動可以推進？
- 成本結構: 如何確立你的商業模式下所產生的成本結構？
通過以上幾點，對初創企業的重新定義就浮出水面了：初創企業指的就是一個對可複用和可擴展的商業模式進行探索的臨時性組織。
如何驗證猜想
當建立好滿足以上商業模式畫布的猜想之後，我們又將需要如何對這些猜想進驗證呢？如果你是一個科學家，那麼答案很簡單，去做實驗就完了。其實這對作爲企業家的我們同樣適用。事實上美國國家科學基金會(NSF)對Steve Blank(作者本人)的課程"精益產品打造(Lean LaunchPad)"的描述，就是將這種驗證的方式歸類成一個科學方法來看待的。
書籍《初創企業家手冊》所描述的”客戶關係拓展流程“就是一個將你的猜想交到客戶手上進行驗證的簡單且行之有效的方法。裏面章節所提及的”客戶挖掘“的方法就是用來捕獲創始人的願景，並把它們一項項的細化成商業模式的猜想。同時它還給出了一系列的驗證方法來指導我們該如何驗證我們的客戶對這些猜想的反饋，並將它們付之實現。驗證猜想的實驗可以是一系列你想要問用戶的問題，但通常情況下，提供一個幫助用戶更好的理解你是如何解決他們的痛點的一個MVP將會是一個更好的選擇。
所以這就是爲什麼說我們打造MVP的目標並不是爲了去打造一個產品原型，而是爲了最大化進行對產品相關猜想的學習。
最後，獲取數據也不是設計這些實驗和打造MVP的最終目標。任何人都可以獲得數據，想要數據的話，把潛在用戶聚集起來開個座談會做個問卷調查之類的就好了。但這並非我們最終想要的，我們如是做的最終目標其實是爲了更深入的洞悉我們的產品的方方面面。走出閉門造車的困局，重點就是要去讓客戶瞭解產品的願景並有效的對之進行驗證。那麼如何才能真正的洞悉產品呢？當然，你可以從慢慢分析用戶反饋入手。但也有可能你根本不需要分析任何的數據，因爲你可能很快就意識到你正在打造的產品其實是一個破壞性創新，這時候該產品的市場還沒有真正形成(編者注：我就沒有聽過當年喬布斯開發iphone的時候有跟用戶一起迭代過多少個版本)，這個時候你就需要將你的實驗和MVP從驗證特定功能這個目標，轉變到打造未來這個方向上來了。
小結
-
“打造－衡量－學習”模型是對瀑布模型的一個偉大改進，它提供了一套框架來讓我們真正的讓用戶參與到我們的敏捷開發流程上面來。
-
然而，如果在第一步就把注意力集中在”打造”和”創意”上面的話，你就會丟失掉精益創業所帶給我們的洞悉力 - 你應該從對產品的猜想開始，然後對這些猜想進行驗證，然後在此過程中找尋出一個屬於你的可重複且可擴展的商業模式。
-
”猜想 - 實驗設計 - 驗證 - 洞悉“的更好的闡述了精益創業的流程:
- 利用商業模式畫布來框定你的猜想，利用上面提到的"客戶挖掘”的方式走出閉門造車的困局以驗證你的假想，最後利用敏捷開發工程思想來增量迭代的打造你的產品。
橫批：敬請轉發關注
昨夜西風凋碧樹，時已三更譯此書；
看官轉發吾所欲，小編涕零淚如注。