業(yè)界的所謂磚家們對精益創(chuàng)業(yè)所提倡的“Build(打造))- Measure(衡量) - Learn(學(xué)習(xí))"模式的詬病和抱怨已經(jīng)不是一天兩天的事情了，但每次當(dāng)我聽到他們說這無知的話的時候，我依然會感到無比的吃驚：

“這模式無非就是將一個半成品快速的投入市場進(jìn)行試水而已。”

何以至此呢?很不幸，之所以讓人困惑的原因恰恰正是因為精益創(chuàng)業(yè)中的這個“打造-衡量-學(xué)習(xí)”模型圖而引起的，因為咋一看這模型圖的順序，這完全是一個本末倒置的東西嘛!這就好比你作為射擊教練去教學(xué)生射擊的時候卻喊著口號：“射擊 - 準(zhǔn)備 - 瞄準(zhǔn)“ 一樣。

時至今日，精益創(chuàng)業(yè)已經(jīng)大行其道很長一段時間了，我們也已經(jīng)摸索出其中如何才能真正的去“精益”的進(jìn)行創(chuàng)業(yè)的秘訣。所以，為了以正視聽，我認(rèn)為現(xiàn)在是時候?qū)@個“打造-衡量-學(xué)習(xí)”模型進(jìn)行相應(yīng)的更新了。

那么我們下面就看看應(yīng)該如何進(jìn)行更新吧，請看官們耐心往下看。

“打造-衡量-學(xué)習(xí)”，這聽上去其實是一件異常簡單的事情。無非就是先打造出一個產(chǎn)品，然后把它丟到市場上面去，然后去收集并衡量客戶的反映以及反饋，然后從中進(jìn)行學(xué)習(xí)，最后根據(jù)學(xué)習(xí)的結(jié)果進(jìn)一步打造出更好的產(chǎn)品。這是一個不斷循環(huán)的過程，過程中你需要根據(jù)上一輪學(xué)習(xí)的結(jié)果，去決定在本輪中你是需要在已有產(chǎn)品的基礎(chǔ)上進(jìn)行進(jìn)一步的迭代呢，還是需要挖掘出一個新的方向，然后重整旗鼓換條道路前進(jìn)，又或者是需要全盤推翻從頭再來。最終能跳出這個循環(huán)的出口只有一 個，就是當(dāng)你能打造出客戶真正喜歡的產(chǎn)品的時候。

閉門造車的困局 - 瀑布模型

雖然這聽上去很簡單，但相對于貫穿整個20世紀(jì)所使用的瀑布式開發(fā)來說，“打造-衡量-學(xué)習(xí)”模型可以算得上是一項徹底的變革了。那時候，企業(yè)家們是在幾乎沒有獲得任何用戶反饋的情況下，運用一系列的產(chǎn)品研發(fā)流程來進(jìn)行產(chǎn)品打造的。這些公司創(chuàng)始人會在假設(shè)自己已經(jīng)很清楚客戶碰到的問題或者客戶的需求的前提 下，開始進(jìn)行需求文檔(ERD)的編寫，進(jìn)行產(chǎn)品的設(shè)計，進(jìn)行硬件/軟件的實現(xiàn)/構(gòu)建，然后對硬件/軟件進(jìn)行測試，以驗證其和需求文檔的描述是吻合的，最后就會以首批出貨(FCS)的形式向潛在客戶揭開產(chǎn)品的神秘面紗 。

瀑布模型所做的事情其實就是去將需求文檔進(jìn)行編碼實現(xiàn)。雖然產(chǎn)品的 Alpha版本和Beta版本，最終還是會邀請客戶一起進(jìn)行測試和驗收，但是，這時客戶介入的目的，其實已經(jīng)不是為了對你的產(chǎn)品的功能或者易用性提供反饋，而僅僅是去看下你的產(chǎn)品是否完全按照需求文檔去進(jìn)行實現(xiàn)，是否存在缺陷而已了。

在這種情況下，只有在產(chǎn)品真正的賣給客戶之后，我們的初創(chuàng)公司才能獲得客戶的有實際意義的反饋。而現(xiàn)實往往更悲催——在你的產(chǎn)品經(jīng)歷了幾個月甚至幾年的閉門造車的開發(fā)過程之后，你最終卻發(fā)現(xiàn)客戶根本就不會付錢買你的產(chǎn)品，因為他們可能壓根就不需要你的產(chǎn)品所提供的大部分功能!

瀑布開發(fā)模式下，一個產(chǎn)品往往需要經(jīng)歷三個版本，才能真正走向正軌滿足客戶的需求。第一個版本毫無疑問是個閉門造車的產(chǎn)物了，根本沒有用戶反饋可言，所以就更談不上滿足客戶需求了;而第二個版本的開發(fā)往往又是在第一個版本還沒有完全獲得用戶大量反饋之前，就已經(jīng)密鑼緊鼓的開始的了;所以，我們往往只能在第三個版本中才能真正基于用戶的反饋進(jìn)行產(chǎn)品的打造(其中微軟的 Windows 3.0 這個產(chǎn)品的開發(fā)過程就是一個很典型的例子)。

到了2000年初，敏捷開發(fā)逐漸成為軟件開發(fā)的最佳實踐方式。這種方法通過引入迭代和邀請用戶參與的方式，來對陳舊的瀑布開發(fā)模式進(jìn)行大幅的改進(jìn)。這其實已經(jīng)是一個很大的進(jìn)步，但問題是它沒有一個行之有效的框架來指導(dǎo)我們?nèi)绾卧谑袌錾向炞C那些商品化方面的猜想。所以在這種情況下，如果你的產(chǎn)品開發(fā)過程中盲目的運用敏捷開發(fā)的話，就算你將一個客戶所要求的所有功能都實現(xiàn)了，你的產(chǎn) 品也難免會碰上滑鐵盧而最終鎩羽而歸。

這時，精益創(chuàng)業(yè)所提倡的“打造-衡量-學(xué)習(xí)”這個框架模型就應(yīng)運而生了!

一波未平一波又起

關(guān)于這個“打造-衡量-學(xué)習(xí)”的循環(huán)，首先我們必須明白這個循環(huán)的目的，并不是要去讓我們打造出一件最終的產(chǎn)品或者產(chǎn)品原型，而是為了讓我們在不停的迭代和增量開發(fā)的工程中，最大化我們對要打造的產(chǎn)品的學(xué)習(xí)(這里的學(xué)習(xí)包括產(chǎn)品功能、客戶需求、產(chǎn)品定價以及銷售渠道等等)。

而“打造”指的當(dāng)然就是就是去打造出一個MVP(最小可行化產(chǎn)品)了。這里并不是說你只去實現(xiàn)你的產(chǎn)品的一小部分功能就叫做MVP了，明白這一點是非常重要的。事實上，MVP指的應(yīng)該是一個可以讓你快速給客戶演示，并快速獲得用戶的反饋以進(jìn)行學(xué)習(xí)的那么一個最簡單可行的東東。

在創(chuàng)業(yè)早期，MVP可以僅僅是幾張PPT幻燈片，也可以是一幅線框圖，更可以是一個模型，甚至可以只是一些采樣數(shù)據(jù)而已。在你每次進(jìn)行一個MVP的打造之前，你都需要先去定義好在該MVP中你所需要測試/衡量的究竟是什么東西，然后你才能有針對性的對你的產(chǎn)品、市場和客戶等進(jìn)行學(xué)習(xí)和認(rèn)知。隨著這方面知識的積累，你的MVP慢慢自然而然的就會往用戶真正需要的產(chǎn)品這個目標(biāo)靠攏。

但此時可別得意忘形了，在往下的迭代周期中，你的目標(biāo)依然是為了繼續(xù)最大化你的學(xué)習(xí)，而不是去給你的最終產(chǎn)品打造個產(chǎn)品原型或者Beta版本。相對瀑布模型來說，“打造-衡量-學(xué)習(xí)”模型令創(chuàng)業(yè)變得更為簡單，靈活而且有效率。

精益創(chuàng)業(yè)中常用上圖對“打造-衡量-學(xué)習(xí)”這個模型對其進(jìn)行闡述。但是把“打造”這個詞放在整個流程的首位往往會讓人困惑。如前文所述，這讓人咋一看是有種 本末倒置的感覺。因此，為了幫助我們能更好的了解精益創(chuàng)業(yè)的這個模型，我們還需要加入另外三個元素。所以最終更細(xì)化的一個版本就出來了：“創(chuàng)意-打造-編碼-衡量-數(shù)據(jù)-學(xué)習(xí)”。

“創(chuàng)意-打造-編碼-衡量-數(shù)據(jù)-學(xué)習(xí)”的這個細(xì)化版，可以讓我們對容易讓人困惑的”打造“這個詞的本意有更好的認(rèn)知，讓人們清楚的知道”打造”的目的是要去測試驗證你對產(chǎn)品的” 創(chuàng)意“，而非”無的放矢“的盲目地去進(jìn)行產(chǎn)品開發(fā)。

其中的“編碼(Code)”很好理解，指的就是如何的對產(chǎn)品進(jìn)行編碼實現(xiàn)，當(dāng)然，如果不是軟件行業(yè)的 話，你也可以簡單的將其替換成“硬件開發(fā)”或“人造基因研發(fā)”。

“數(shù)據(jù)(Data)”意思是當(dāng)我們的MVP發(fā)布給用戶使用后，我們將會獲得用戶的反饋， 然后我們會對獲取回來的反饋進(jìn)行衡量，如找出哪些是有效的或者無效的、有用或者無用的數(shù)據(jù)，以便我們在下一步可以更深入的對這些數(shù)據(jù)進(jìn)行學(xué)習(xí)。而這些學(xué)習(xí)回來的新認(rèn)知又將會反過來影響我們下一輪循環(huán)迭代的”創(chuàng)意“。

所以在此我們可以很清晰的認(rèn)識到，“打造-衡量-學(xué)習(xí)”的目標(biāo)并不僅僅是為了打造MVP而打造MVP，而更應(yīng)該是有針對性的去為了驗證你的創(chuàng)意而進(jìn)行MVP的打造。

一旦你認(rèn)識到這一點，那么你就會清楚“打造-衡量-學(xué)習(xí)”這個模型的并非如上文中磚家們所質(zhì)疑的“這模式無非就是將一個半成品快速的投入市場進(jìn)行試水而已。”相反，該模型的關(guān)注點應(yīng)該是在如何測試驗證你的產(chǎn)品的”創(chuàng)意“。

那么這是否就足夠了呢?答案是否定的，我們其實可以做的更好!

精益創(chuàng)業(yè)的改進(jìn)該從猜想開始

“打造-衡量-學(xué)習(xí)”這個模型其實還是缺了那么點東西，它忘了一個新產(chǎn)品產(chǎn)生之前其實都不是由創(chuàng)意(無論是初創(chuàng)企業(yè)的創(chuàng)意，還是一個成熟企業(yè)開發(fā)新產(chǎn)品的創(chuàng)意)開始的，而是從一些還不明朗的對產(chǎn)品的一些猜想(其實就是”猜測“更冠冕堂皇的說法而已)開始的。

創(chuàng)意和猜想是兩個截然不同的東西，這一點非常的重要。對于大部份創(chuàng)新者來說，創(chuàng)意就是對產(chǎn)品的洞悉，一旦有了創(chuàng)意，就需要立刻制定詳細(xì)計劃來將之付諸實現(xiàn)以產(chǎn)生成果的。相對來說，”猜想“指的是，我們現(xiàn)在已經(jīng)有一個根據(jù)經(jīng)驗而來的猜想，但還需要一些實驗/試驗以及相應(yīng)的數(shù)據(jù)來證明其究竟是可行還是不可行的。

這些猜想覆蓋面非常之廣，我們的目的就是要驗證這些猜想，以確定我們的產(chǎn)品應(yīng)該如何進(jìn)行打造。從找出誰是目標(biāo)客戶，到如何確立產(chǎn)品的價值主張，到如何給產(chǎn)品定價，到如何找到并打通銷售渠道，再到如何創(chuàng)建需求(獲取用戶、激活用戶、黏住用戶等等)，這些都需要進(jìn)行驗證才能確定的。

事實上，如果你真要進(jìn)行精益創(chuàng)業(yè)的話，承認(rèn)自己的創(chuàng)意其實只是一系列未經(jīng)證實的猜想，是一個非常重要的開始。之所以說它重要，是因為你所打造的東西，應(yīng)該是為去驗證你的猜想而服務(wù)的。

你要知道，為了驗證誰是真正潛在的客戶所打造的MVP，和為了驗證產(chǎn)品定價所打造的MVP的要求是不一樣的，而用于測試新功能所需要打造的MVP又是另外一回事。另外，這些猜想(及MVP)會隨著你不停的學(xué)習(xí)積累而不停的產(chǎn)生變化。

綜上所述，我們?nèi)ゴ蛟煳覀兊腗VP的時候所運用的精益創(chuàng)業(yè)的框架更應(yīng)該是"猜想 - 實驗設(shè)計 - 驗證 - 洞悉”，而非原來的“打造 - 衡量 - 學(xué)習(xí)”。

如何構(gòu)建猜想

如果運用“猜想 - 實驗設(shè)計 - 驗證 - 洞悉”這個新的框架，那么問題將會變成：有哪些猜想我們是應(yīng)該去驗證的?關(guān)于這個問題， Alexander Osterwalde在它的商業(yè)模式畫布中早就將商業(yè)上需要驗證的九個模塊壓縮成一張可視化的圖來讓你一目了然了。請看下圖(如果看不清楚的話可以直接點擊這里進(jìn)行查看)：

價值主張：公司通過其產(chǎn)品和服務(wù)所能向消費者提供怎么樣的價值?

客戶細(xì)分：例如是普通用戶還是付費用戶，是家庭主婦還是年輕人?

銷售渠道：如何找到目標(biāo)客戶，并向其提供你的產(chǎn)品的價值主張?

客戶關(guān)系：如何創(chuàng)造更多的需求?

收益流：如何通過價值主張而獲得收入來源?

活動：如何執(zhí)行必須的活動來實現(xiàn)你的商業(yè)模式?

資源：如何獲得活動所需要的資源?

第三方合作伙伴：如何獲得別人的支持以令你的活動可以推進(jìn)?

成本結(jié)構(gòu)：如何確立你的商業(yè)模式下所產(chǎn)生的成本結(jié)構(gòu)?

通過以上幾點，對初創(chuàng)企業(yè)的重新定義就浮出水面了：初創(chuàng)企業(yè)指的就是一個對可復(fù)用和可擴展的商業(yè)模式進(jìn)行探索的臨時性組織。

如何驗證猜想

當(dāng)建立好滿足以上商業(yè)模式畫布的猜想之后，我們又將需要如何對這些猜想進(jìn)驗證呢?如果你是一個科學(xué)家，那么答案很簡單，去做實驗就完了，其實這對作為企業(yè)家的我們同樣適用。事實上美國國家科學(xué)基金會(NSF)對Steve Blank(作者本人)的課程"精益產(chǎn)品打造(Lean LaunchPad)"的描述，就是將這種驗證的方式歸類成一個科學(xué)方法來看待的。

書籍《初創(chuàng)企業(yè)家手冊》所描述的“客戶關(guān)系拓展流程”，就是一個將你的猜想交到客戶手上進(jìn)行驗證的簡單且行之有效的方法。里面章節(jié)所提及的“客戶挖掘”的方法，就是用來捕獲創(chuàng)始人的愿景，并把它們一項項的細(xì)化成商業(yè)模式的猜想。同時它還給出了一系列的驗證方法，來指導(dǎo)我們該如何驗證我們的客戶對這些猜想的反饋，并將它們付之實現(xiàn)。驗證猜想的實驗可以是一系列你想要問用戶的問題，但通常情況下，提供一個幫助用戶更好的理解你是如何解決他們的痛點的MVP將會是一 個更好的選擇。

所以這就是為什么說我們打造MVP的目標(biāo)，并不是為了去打造一個產(chǎn)品原型，而是為了最大化進(jìn)行對產(chǎn)品相關(guān)猜想的學(xué)習(xí)。

最后，獲取數(shù)據(jù)也不是設(shè)計這些實驗和打造MVP的最終目標(biāo)。任何人都可以獲得數(shù)據(jù)，想要數(shù)據(jù)的話，把潛在用戶聚集起來開個座談會做個問卷調(diào)查之類的就好了。 但這并非我們最終想要的，我們?nèi)缡亲龅淖罱K目標(biāo)其實是為了更深入的洞悉我們的產(chǎn)品的方方面面。走出閉門造車的困局，重點就是要去讓客戶了解產(chǎn)品的愿景并有效的對之進(jìn)行驗證。

那么如何才能真正的洞悉產(chǎn)品呢?當(dāng)然，你可以從慢慢分析用戶反饋入手。但也有可能你根本不需要分析任何的數(shù)據(jù)，因為你可能很快就意識到：你正在打造的產(chǎn)品其實是一個破壞性創(chuàng)新，這時候該產(chǎn)品的市場還沒有真正形成(編者注：我就沒有聽過當(dāng)年喬布斯開發(fā)iPhone的時候有跟用戶一起迭代過多 少個版本)，這個時候你就需要將你的實驗和MVP從驗證特定功能這個目標(biāo)，轉(zhuǎn)變到打造未來這個方向上來了。

小結(jié)

“打造-衡量-學(xué)習(xí)”模型是對瀑布模型的一個偉大改進(jìn)，它提供了一套框架來讓我們真正的讓用戶參與到我們的敏捷開發(fā)流程上面來。

然而，如果在第一步就把注意力集中在”打造”和”創(chuàng)意”上面的話，你就會丟失掉精益創(chuàng)業(yè)所帶給我們的洞悉力 —— 你應(yīng)該從對產(chǎn)品的猜想開始，然后對這些猜想進(jìn)行驗證，然后在此過程中找尋出一個屬于你的可重復(fù)且可擴展的商業(yè)模式。

”猜想 - 實驗設(shè)計 - 驗證 - 洞悉“的更好的闡述了精益創(chuàng)業(yè)的流程：

利用商業(yè)模式畫布來框定你的猜想，利用上面提到的"客戶挖掘”的方式走出閉門造車的困局，以驗證你的假想，最后利用敏捷開發(fā)工程思想來增量迭代的打造你的產(chǎn)品。