下面是如何去做：

“構建，衡量和認知”聽起來似乎很簡單。構建一款產品將它投入市場，檢測用戶的反應和行為，從中學習和調整，并優(yōu)化產品。周而復始，不斷迭代，改進、完善直到用戶滿意為止。

瀑布式開發(fā)

這聽起來似乎很簡單，但將“構建，衡量和認知”的方式用于產品開發(fā)的創(chuàng)建和運輸卻是對20世紀傳統(tǒng)的瀑布式模型的徹底改進。追溯到那個時代，一個企業(yè)家采用了一系列的產品開發(fā)流程，這些流程都是根據(jù)客戶的反饋一小步一小步進行的。產品創(chuàng)始者假定自己了解客戶的需求，寫出工程要求的文書，設計出產品，打造好硬件和軟件，并通過不斷的測試驗證其效果，然后再將此產品正式推介給客戶，這叫作首批出貨。

瀑布式開發(fā)是全部按照這個要求的文書去執(zhí)行的。當產品的早期版本在Alpha 和Beta 的測試過程中被客戶分享時，最初讓客戶接觸此產品的目的是為了發(fā)現(xiàn)問題，而不是為了得到產品特性和使用性能的反饋。只有在出貨和試圖出售此產品時，企業(yè)才能開始得到客戶實質性的反饋。企業(yè)往往在幾個月甚至幾年的開發(fā)過程中才逐漸意識到客戶不買他們的產品是由于客戶不需要或是客戶不喜歡產品的大部分特性。

公司通常要通過三次嘗試才能得到最佳產品。第一個版本建立在沒有客戶反饋的基礎上，第二個版本早在第一個版本還沒完全完成時就已經開始做了，所以在客戶真正得知此產品之前，第三個版本就已被得出。(例如微軟的Windows 3.0)

在2000年初，軟件開發(fā)的最佳實踐開始轉移到敏捷開發(fā)(Agile Development)。這種方法通過迭代開發(fā)軟件和提高客戶參與度從而改進了瀑布式開發(fā)。但它缺少一個測量外圍所有商品化假設的框架。在敏捷開發(fā)下，你最終或許滿足了每一個客戶的需求但依然會歇業(yè)。

下面便是精益創(chuàng)業(yè)的重點——“構建，衡量和認知”。

關于“構建，衡量和認知”

“構建，衡量和認知”的目的不是為了創(chuàng)建并推出一個最終產品或構建一個產品原型，而是為了通過遞增和迭代的管理進行最大化學習(學習產品的特性，客戶的需求，正確的定價和分銷渠道等)。“構建”這一步是指構建一個最小可行化產品(Minimal Viable Product, 縮寫MVP)，關鍵要了解MVP指的并不是一個功能很少的產品，而是你可以用最簡單的方式將產品推銷給客戶以及時得到最多的反饋意見。在研發(fā)早期，一個最小可行化產品也許只僅僅像是一張幻燈片、線框、泥塑模型、或者樣本數(shù)據(jù)等。每當你在構建一個最小可行化產品時你就已確定了你到底想測試產品的哪些方面。最后，隨著越來越多的了解，這個最小可行化產品逐漸從低保真變成較高保真，但我們的目標仍然是最大化學習而不是為了建立一個功能齊全的產品原型。

相對于瀑布式開發(fā)來說，“構建，衡量和認知”是一個相當大的改進，它讓創(chuàng)業(yè)行為進行地快速、敏捷和高效。

“構建，衡量和認知”的三圓圖表很好地描述了整個流程。然而，“構建”這個詞語在一開始總會給人們造成困惑。但圖表更能直觀地反映企業(yè)所要構建的東西并將它投入市場。“構建，衡量和認知”圖表的詳細版本另加入三個元素幫助人們了解它的含義：想法——構建——代碼——測量——數(shù)據(jù)——認知。

“構建，衡量和認知”圖表五元素的版本幫助我們了解到“構建”的真實意圖是為了驗證“想法”的可行性，而不只是沒有目標地盲目構建。“代碼”的圓標貼很容易被標明為“構建硬件”或者“構建人工基因組”;“數(shù)據(jù)”的圓標貼則表明當我們經過實驗檢測后，我們會用數(shù)據(jù)進一步完善我們的認知，同時新的認知又將會影響我們接下來的想法，所以我們可以看到“構建，衡量和認知”的目標不僅僅是去構建一些產品，而是去證實或否認一些原始想法。

但它仍然是不夠完善的，我們現(xiàn)在能做的更好。

從假設開始

“構建，衡量和認知”所缺乏的是新創(chuàng)企業(yè)并非從想法開始(創(chuàng)業(yè)和新思路并存于企業(yè)之中)，他們是從假設開始的(大膽猜測的華麗詞藻)。重要的是大家需要明白“想法”和“假設”兩者完全不同。對于大部分創(chuàng)新者而言，“想法”這個詞會使得他們靈光一現(xiàn)立刻制定計劃并賦予成效。相反，“假設”這個詞則意味著我們掌握一個有根據(jù)的推測，需要實驗和數(shù)據(jù)去證實其有效性。

這些假設包括客戶是誰，價值定位是什么(產品和服務的特點)，定價，分銷渠道和創(chuàng)建需求(客戶獲取、激活、保留等)。

精益創(chuàng)業(yè)開始承認你的想法只是一系列未經驗證的設想，這的確是個很大的想法，因為你構建的東西需要匹配你想驗證的假設。

為了尋求合適客戶而創(chuàng)建出的最小可行化產品是不同于做價位評估的最小可行化產品的，也不同于檢驗其特殊產品特性的最小可行化產品。隨著你了解得越多，這些假設(包括最小可行化產品)也會隨之不斷改變。所以，在精益創(chuàng)業(yè)中創(chuàng)建的MVP圖表看起來就像假設——實驗——檢測——洞悉，而不是“構建，衡量和認知”。

生成假設

在使用新的“假設——實驗——檢測——洞悉”圖表時，會產生新的問題——“我應該測試哪些假設呢?” 幸運的是，Alexander Osterwadler的商業(yè)模式畫布(Business Model Canvas)在一個頁面上就能呈現(xiàn)出九個元素的視覺概述。他們分別是：

·價值定位(Value Proposition)——公司所提供的產品或者服務(連同帶給消費者的好處)

·客戶細分(Customer Segments)——比如用戶和付款者或者母親或者青少年

·分銷渠道(Distribution Channels)——客戶獲取渠道以及為其提供價格定位

·客戶關系(Customer Relationships)——創(chuàng)造需求

·收益流(Revenue Streams)——通過價格定位而形成

·活動(Activities)——實行商業(yè)模式的必要條件

·資源(Resources)——組織活動需要資源

·合伙人(Partners)——組織活動需要第三方

·成本構架(Cost Structure)——來自于商業(yè)模式

這就給我們引入了創(chuàng)業(yè)的定義：創(chuàng)業(yè)是一個探尋可規(guī)?；蓮椭苹纳虡I(yè)模式的暫時性組織。

檢驗假設

而一旦當商業(yè)模式畫布中有這些假設，那么企業(yè)家該如何去檢測他們呢?如果你是一個科學家，那么答案很簡單：做實驗。在精益創(chuàng)業(yè)中也是一樣的。(美國國家科學基金會將“精益產品打造”課程稱之為創(chuàng)業(yè)的科學方法)

客戶開發(fā)流程是新合資公司進行假設并把它放入實踐中檢驗的最簡單的方法。“發(fā)現(xiàn)客戶”則體現(xiàn)了創(chuàng)始人的遠見，并把它轉換成一系列的商業(yè)模式的假設;然后它可以進行一系列實驗去檢測客戶的反饋，讓那些假設變成事實。這些實驗可以是一系列你想要問客戶的問題，但是最常見的是最小可行化產品能夠幫助潛在客戶了解問題的解決方案。

因此另外一個大想法是創(chuàng)業(yè)并沒有通過構建最小可行化產品去構建一個產品原型。他們正在通過構建最小可行化產品去學到更多。

設計這些實驗和最小可行化產品的目的并不在于得到數(shù)據(jù)。數(shù)據(jù)并不是最終目的，任何人都能搜集數(shù)據(jù)，焦點小組也可以收集數(shù)據(jù)，但這不是一個焦點小組。設計這些實驗和最小可行化產品的目的是為了獲得洞察力。而將產品投入市場的目的則是為了展現(xiàn)創(chuàng)始人的設想。這樣的洞察力可能來自于對客戶反饋的分析，但也可能是由于忽略了數(shù)據(jù)或者你意識到你所描述的是一個不存在的、全新的、分裂的市場，這時就需要你改變你的實驗——從具體測量變?yōu)閯?chuàng)造未來。

我們學到了什么(Lessons Learned)

·“構建，衡量和認知”是對于瀑布式產品開發(fā)的巨大改進，它為讓客戶真正參與到敏捷開發(fā)提供了框架。

·將注意力集中在“構建”或者“想法”上作為第一步，這會遺漏精益創(chuàng)業(yè)的核心觀點——你以一個需要被測試的假設為開端，同時你也正在尋求一個可規(guī)?；蓮椭苹纳虡I(yè)模式。

·“假設——實驗——檢測——洞悉”可以更好地展現(xiàn)精益創(chuàng)業(yè)的流程。

·精益創(chuàng)業(yè)的流程：使用商業(yè)模式畫布去構建假設，開發(fā)客戶將產品帶入實踐從而檢驗假設，同時通過敏捷工程去打造產品的迭代和增量。