我很好奇為什么總有人在抱怨精益創業(The Lean Startup)中的“構建，衡量和認知”(Build, Measure, Learn)這一方式不過是把未完成的產品引入市場檢驗它的效果而已。

或許問題出在“構建，衡量和認知”的圖表上。因為乍一看，它就像一個“開火——準備——目標”的過程。

那么，現在是時候更新大家所理解的“構建，衡量和認知”這個建立精益創業的最好方法了。

下面是如何去做：

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

瀑布式開發

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

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

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

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