MVP – 當構建、測量、學習不僅僅是把東西扔在牆上
已發表: 2017-05-29看看它們是否有效
當批評者抱怨精益創業公司的構建、測量、學習方法只不過是“將不完整的產品扔出大樓,看看它們是否有效”時,我總是感到驚訝。
不幸的是,構建、測量、學習圖表是造成這種混亂的原因。 乍一看,這似乎是一個隨時準備瞄準的過程。
是時候更新構建、測量、學習到我們現在所知道的構建精益創業公司的最佳方式了。
就是這樣。
構建、測量、學習聽起來很簡單。 構建一個產品,將它帶入現實世界,衡量客戶的反應和行為,從中學習,並利用你學到的東西來構建更好的東西。 重複,學習是迭代、調整還是重新開始,直到你擁有客戶喜歡的東西。
瀑布開發
雖然聽起來很簡單,但產品開發的構建測量學習方法是對 20世紀用於構建和運輸產品的傳統瀑布模型的根本改進。 當時,一位企業家使用了一個逐步進行的系列產品開發流程,幾乎沒有客戶反饋。 創始人假設他們了解客戶的問題/需求,編寫工程需求文檔,設計產品,實施/構建硬件/軟件,通過測試驗證它是否有效,然後以正式的形式向客戶介紹產品,稱為首次客戶交付.
瀑布式開發就是執行需求文檔。 雖然產品的早期版本在Alpha和Beta 測試中與客戶共享,但客戶早期訪問產品的目標是發現錯誤,而不是提供有關功能或可用性的反饋。 只有在發貨並嘗試銷售產品之後,初創公司才會聽到客戶的任何實質性反饋。 很多時候,經過數月甚至數年的發展,企業家們都以艱難的方式了解到,客戶之所以不購買他們的產品,是因為他們不需要或不想要產品的大部分功能。
公司通常需要三次嘗試才能獲得正確的產品。 第 1 版是在沒有客戶反饋的情況下構建的,在第 1 版完成之前,第 2 版的工作已經開始,所以直到第 3 版才真正聽到客戶的聲音(例如 Microsoft Windows 3.0)
軟件開發的最佳實踐在 2000 年代初期開始轉向敏捷開發。 這種方法通過迭代構建軟件並讓客戶參與來改進瀑布。 但它缺乏一個測試所有商業化的框架 建築物外的假設。 使用敏捷,您最終可以滿足客戶要求的每個功能,但仍然會倒閉。
然後是精益創業的構建度量學習重點。
構建測量學習

Build-Measure-Learn 的目標不是構建最終產品以交付甚至構建產品原型,而是通過增量和迭代工程最大限度地學習。 (學習可能是關於產品特性、客戶需求、正確的定價和分銷渠道等。)“構建”步驟是指構建最小可行產品(MVP)。理解 MVP 不是具有更少的功能。 相反,這是您可以向客戶展示的最簡單的東西,以便在那個時間點獲得最多的學習。 在初創公司的早期,MVP 可能只是 PowerPoint 幻燈片、線框、粘土模型、示例數據集等。每次構建 MVP 時,您還定義了您要測試/測量的內容。 後來,隨著了解的更多,MVP 從低保真度變為高保真度,但目標仍然是最大限度地學習,而不是構建產品的 beta/全功能原型。
為你推薦:
對瀑布開發的重大改進, Build Measure Learn讓初創公司變得快速、敏捷和高效。

Build Measure Learn的三圈圖很好地近似了該過程。 不幸的是,首先使用“構建”這個詞常常使人們感到困惑。 該圖似乎確實暗示了構建東西並將其扔出建築物。 Build Measure Learn 圖的更詳細版本通過添加另外三個元素來幫助闡明含義:想法- 構建 -代碼- 測量 -數據- 學習。
Build Measure Learn圖表的五部分版本幫助我們了解構建的真正目的是測試“想法”——而不是盲目地沒有目標地構建。 標記為“代碼”的圓圈很容易被標記為“構建硬件”或“構建人工基因組”。 標記為“數據”的圓圈表示,在我們測量實驗後,我們將使用這些數據來進一步完善我們的學習。 新的學習將影響我們的下一個想法。 所以我們可以看到,構建-測量-學習的目標不僅僅是構建事物,目標是構建事物以驗證或使最初的想法無效。
對測試特定想法的關注抵消了構建-測量-學習只是把東西扔在牆上,看看它們是否有效的擔憂。
但它仍然不夠好。 我們現在可以做得更好。

從假設開始
Build-Measure-Learn錯過的是新企業(初創公司和現有公司的新想法)不是從“想法”開始,而是從假設(猜測的花哨詞)開始。重要的是要理解“想法”和“假設”意味著兩個非常不同的東西。 對於大多數創新者來說,“想法”這個詞讓人聯想到一種洞察力,這種洞察力需要立即制定計劃來實現它。 相反,假設意味著我們有一個有根據的猜測,需要實驗和數據來驗證或無效。
這些假設涵蓋了從誰是客戶到價值主張(產品/服務功能)、定價、分銷渠道和需求創造(客戶獲取、激活、保留等)的範圍。
精益創業始於承認您的想法只是一系列未經檢驗的假設,這是一個偉大的想法。 這是一個非常大的想法,因為您構建的內容需要與您要測試的假設相匹配。
您需要構建以找到合適的客戶的最小可行產品與測試定價所需的最小可行產品不同,後者與您為測試特定產品功能而構建的 MVP 不同。 隨著您了解更多,所有這些假設(以及最小可行產品)都會隨著時間而變化。 因此,在精益創業中構建最小可行產品的圖表不是“構建-測量-學習”,而是看起來像假設 - 實驗 - 測試 - 見解。
產生假設
使用這個新的假設 - 實驗 - 測試 - 洞察圖表,問題就變成了,“我應該測試什麼假設?” 幸運的是,Alexander Osterwalder 的商業模式畫佈在一頁上展示了企業九個組成部分的可視化概覽。 他們是:
- 公司提供的價值主張、產品/服務(以及對客戶的好處)。
- 客戶群,例如用戶和付款人或媽媽或青少年。
- 接觸客戶並為他們提供價值主張的分銷渠道
- 客戶關係創造需求。
- 價值主張產生的收入流。
- 實施商業模式所需的活動。
- 使活動成為可能所需的資源。
- 合作夥伴第3方需要使活動成為可能。
- 由商業模式產生的成本結構。
它給我們帶來了創業公司的定義:創業公司是一個臨時組織,旨在尋找可重複和可擴展的商業模式。
檢驗假設
一旦這些假設填滿了商業模式畫布,企業家如何去測試它們? 如果您是科學家,答案很簡單:您進行實驗。 在精益創業中也是如此。 (美國國家科學基金會將 Lean LaunchPad 課程描述為創業的科學方法。)
客戶開發流程是一種簡單的方法,用於提出新的風險假設並走出大樓進行測試。 客戶發現捕捉了創始人的願景,並將其轉化為一系列商業模式假設。 然後,它開發了一系列實驗來測試客戶對這些假設的反應並將其轉化為事實。 實驗可以是您向客戶提出的一系列問題,但最常見的問題是幫助潛在客戶了解您的解決方案的最小可行產品。
所以這裡的另一個重要想法是,初創公司不會構建最小的可行產品來構建原型。 他們正在構建最小可行的產品,以盡可能多地學習。
最後,設計這些實驗和最小可行產品的目標不是獲取數據。 數據不是終點。 任何人都可以收集數據。 焦點小組收集數據。 這不是一個焦點小組。 目標是獲得洞察力。 走出大樓的全部意義在於告知創始人的願景。 洞察力可能來自分析客戶的反應,但也可能來自於忽略數據或意識到你所描述的是一個不存在的新的、破壞性的市場,並且你需要改變你的實驗,從測量細節到發明未來。
【史蒂夫·布蘭克的這篇文章首發於官網,經授權轉載。】








