生於MVP，死於PMF
本文的主要內容會按照是什麼、為什麼以及如何做的邏輯展開，主要包括以下幾部分：
- 什麼是MVP與PMF；
- 為什麼要有MVP與PMF；
- 如何建立MVP；
- 如何驗證PMF。
什麼是MVP與PMF
MVP(Minimal Viable Product)，意思是最小可行性產品。即通過一個最小化、卻可以滿足核心需求的產品來測試市場的反應。
為了能更好的理解MVP的概念，可參考下圖。
PMF(Product/Market Fit)，意思是產品符合市場需求，這個概念最早出現在馬克·安德森2007年的一篇部落格，他在文章中這樣定義“在一個好的市場裡, 能夠用一個產品去滿足這個市場”。
為了能更好的理解PMF的概念，可參考下圖。
以一個簡單的例子來說明下MVP與PMF，拋開市場分析、競品分析、產品定位等不談，僅從MVP與PMF的角度來說明一下。
你看到身邊有不少人穿著有特定圖案的T恤，比如漫畫人物、表情包、有趣的文案等，於是蹦出來一個念頭，要不做一款支援自定義建立T恤圖案的產品？
那首先需要驗證的就是使用者是否真的有這個需求，我們應該用什麼樣的解決方案來滿足，我們的MVP可以只給一個簡單的展示網頁，交易走微信／支付寶轉賬，商品從淘寶上買，然後發給買的人…
之後需要驗證的就是使用者是否願意埋單，有多人會來買，客單價是多少，復購率是怎樣的等等…這就是PMF的驗證，即達成了什麼樣的標準證明了我們的方案是可行的，
換句話來說，MVP是你在發現某個問題之後給出的一個解決方案，而PMF則是看這個解決方案使用者願意不願意埋單。
為什麼要有MVP與PMF
說完了是什麼之後，簡單的說明下為什麼要這麼做。
需求不一定存在
下圖為2015年CB Insights總結的146家失敗初創企業的20大原因，可以看到高居前三位的分別是沒有市場需求(42%)、沒錢了(29%)、團隊不合適(23%)，從中可以看到沒有市場需求的佔比高達42%。
需求本身已經不存在了，那解決方案就很難被使用者接受了，更不要說使用者會為解決方案埋單了…
資源永遠是有限的
資源永遠是有限的，不管是創業公司還是大公司，一方面公司總會有基於現狀更大的野心，也就需要更多的資源，另一方面資源是公共的，可能會有其他的團隊來爭奪。
所以，相同的資源為什麼不放到價效比更高的專案上去，而且做這個事情還有機會成本。
視窗期越來越短
視窗期變得越來越短，也就意味著留給你犯錯的空間越來越小，試錯的成本也越來越高，甚至你的一個錯誤就可能給競爭對手帶來反超的機會。
有時候你贏了可能並不真的是你贏了，可能只是你的對手都輸了…
產品生命週期規律
產品本身是有著自己客觀發展規律的，就是我們通常說的“S曲線”，從探索期到成長期，再到成熟期、衰退期…
MVP與PMF的思想是和產品規律相吻合的，MVP主要對應的就是探索期的階段，先不斷的探索可行性。
PMF對應著的就是探索期與成長期的臨界點，驗證了PMF之後就可以進行大規模的推廣了，幫助產品快速達到成長期。沒有被驗證可行的產品／模式強行進行推廣的話，甚至可能會起到反作用。
上面絮絮叨叨說了那麼多，都是在說明MVP與PMF是什麼，以及為什麼要這麼做的，下面就來看下如何做。
如何建立MVP
既然MVP指的是針對問題的解決方案，那方案就要明確是解決什麼人在什麼場景下的問題，同時和現有的一些解決方案相比，有什麼優勢…
下面按照產品從需求到方案的流程來說明下如何建立MVP。
使用者、場景和需求分析
首先要明確產品是要解決什麼人在什麼場景下的什麼問題，使用者的表層需求是什麼，深層需求是什麼，更底層的需求是什麼。
定義產品方案
之後要明確方案的方向是什麼，比如多快好省這幾個維度選擇哪個點進行切入，不同的方向，需要做的事情是不同的。
這部分涉及到產品的定位，決定著後續的具體實現路徑。
使用者行為流梳理
根據使用者的目標和任務梳理使用者為了達成目標需要完成的子任務，然後按照相應的順序進行組織。
比如在網際網路線上教育產品裡，使用者最終的目標是學習知識，為了實現這個目標，使用者要來選課、上課。那整個主線行為流就是瀏覽課程》下單購買》支付》課程學習。
功能羅列
結合上兩步中的產品方案、使用者的行為流來梳理對應的功能模組，可以先按照使用者的行為流將所有可行的功能先列舉出來。
下圖為最近羅列的一個網際網路線上教育App的一個MVP版本示意圖，背景不再說明，僅作參考。
定義優先順序
首先需要明確優先順序的標準是什麼，然後再來確定優先順序，我一般會從使用人數、使用頻次和重要程度這幾個維度來進行評估。
還有其他很多的評判標準，比如目標貢獻度、緊急程度、實現難度等等，選擇合適的標準，達成共識之後，再按照這個共識來定義就好。
明確MVP版本功能
最終就是結合優先順序明確下來MVP版本需要有哪些功能，這裡面有幾個原則可以參考一下：
- 一次最好只解決一個主要問題；
- 優先保證主流程能夠走通；
- 活動或者H5先行，最後再產品化。
如何驗證PMF
這部分就是如何驗證產品達到了PMF的標準了，在產品上線之前就應該有一個預期目標，達成了目標可視為已找到PMF的點。
市面上目前常用的方式有兩種，一種是通過定量的資料指標驗證，一種是通過定性的用研結果驗證。
定量驗證
這組參考資料指標來源於Andrew Chen，在網上或者其他一些書籍裡面也能夠看到它的身影。
Andrew Chen是矽谷的創業者，之前領導過Uber的增長團隊，還為灣區的數十家創業公司提供過諮詢和投資…
使用者級產品標準
- 每週使用天數超過3天
- 初始日新增使用者（DNU）超過100
- 30%新使用者次日留存率
- 達到10萬用戶量
Saas產品標準
- 5%付費轉化率
- LTV/CAC>3，即使用者生命週期價值/獲取成本>3
- 月流失率<2%
- 月銷售流水達到10萬元
這些資料指標在不同行業、不同業務模式的產品中對應的數值應該是不同的，核心思想在於需要找到一些關鍵的資料指標，然後通過資料指標來判斷產品是否達到了PMF的標準。
定性驗證
這個方法又叫做Sean Ellis 測試，測試的方法是告訴現在的使用者“你們今後無法再使用這個產品了。”如果有40%的人對此表示“非常失望”，那麼你的產品就達到了PMF。
Sean Ellis是最早提出增長黑客理論的人，在 Dropbox 任職期間，踐行著他自己的這套理論，曾經用一年的時間把使用者的基數和使用頻率提高了500%...
需注意的是，這個測試方法最好採用問卷調查的形式，並且回收的有效問卷的數量最少在40-50份，而且選擇傳送問卷的使用者必須是使用過產品的核心功能，且最近2周還在活躍的使用者，不然問卷的結果可能會存在偏差。
一日一日又一日，又到一週發文時。上次介紹了一個概念，MVP（Minimum Viable Product，最小可行產品），不知道大家還有多少印象。忘了沒關係，先來複習一下。
傳統的產品開發流程，先定義最終產品，然後逐步進行開發測試上線，這通常需要花費數月甚至數年的時間。當投入使用後，才知道產品是否和市場契合，使用者是否喜愛。如果失敗了，則浪費大量的人力物力財力。而MVP呢，倡導先開發一款具有基本功能和吸引力的產品，立即投入執行，視市場的反饋來決定是繼續還是轉型，有效地降低了風險、而且能及時獲取使用者反饋。更具體的內容，請看《如果你有一個創意》。
上一篇文章算是對MVP做了簡單介紹，這篇文章打算講一講MVP和原型（prototype）的區別。
位於矽谷的Dropbox公司開發了一種非常簡單易用的檔案分享工具，可以在多個裝置間共享檔案。初創之時，由於技術限制等原因，暫時無法開發可操作的產品來驗證想法，CEO Drew Houston想出一招，他拍攝了一段3分鐘的視訊，以演示軟體使用情況，結果視訊吸引了幾十萬人訪問他們的網站，公測版等候名單一夜間從5000人增加到了75000人[2]。現在的Dropbox是什麼情況呢？不說市值，就說一個情況：Dropbox目前共有38位廚師，而且不止一位曾經在米其林餐廳工作[3]。
斯坦福的一個創業團隊打算在無人機上安裝高清攝像頭，拍攝（每一顆）農場作物的病害、施肥和灌溉情況。農場主可以根據採集並經過處理的資料來決定如何更好地播種，團隊則可以通過銷售資料來盈利。創業者們本想先購買無人機、超清攝像頭、影象處理軟體，然後花費數月時間來進行開發整合。但是Steve Blank（Steve Blank和下文的Eric Ries均為MVP推廣者）的建議是：既然團隊目標是想確定農場主是否願意購買資料，而農場主並不關心資料是來自衛星、無人機或者魔法，那麼，只需要租借一個手動控制的飛機模型、安裝上普通相機，然後飛躍農場拍攝、手動處理資料，再驗證農場主是否願意為這些資訊付費即可[4]。
以上兩個事例，哪一個是MVP，哪一個是原型呢？它們似乎都是為了驗證初創團隊的想法和測試使用者的反應，二者有何不同？先說明一下，在知識的掌握上，我是奉行“無招勝有招”的，就像張三丰問張無忌，剛剛教你的太極拳記住了嗎？張無忌答道，已經忘記了（然後便以“無招”大獲全勝）。這裡要區分MVP和原型，主要是希望大家認識到此處有歧義，注意到不清晰的定義無益於溝通，瞭解到融會貫通、為我所用的前提是理解準確。
想象一下，小花（甜點師兼創業者）的老公小草（網際網路從業者）一時興起，給小花普及了MVP，小花聽得心潮澎湃，對小草說，她也要做MVP，然後讓老公帶去公司宣傳。於是，小草通知同事們不要吃早餐，等他老婆的糕點。第二天一早，小草拿著小花包裝好的精美禮盒去到了單位，在飢腸轆轆的同事面前拆開後，但見盒裡躺著一本精美的相簿，相簿中羅列著小花製作的各種糕點照片，卻哪裡有蛋糕的蹤影？小草只能報之以一臉尷尬。之後小草責備小花，說好的MVP呢，為什麼是本相簿？小花委屈道，照片就是MVP呀，Dropbox的MVP不就是一段視訊麼？小草心有不甘，卻也無言以對，畢竟他們兩都沒錯，問題在於各自理解的偏差。誠然這情節是虛構的，但是團隊如果對概念理解不統一，將可能造成比故事中更嚴重的後果。
在MVP相關文章和書籍的例子援引中，幾乎是不區分MVP和原型的，就連Steve Blank說的也是“原型MVP”（prototype minimum viableproduct）；Eric Ries則將原型歸類到MVP中，在他看來，P不一定必須是切實可行的產品，只要能以最快的方式、最少的精力完成“開發-測量-認知”的反饋迴圈即可[2]。而Marty Cagan（《啟示錄》作者）認為Eric Ries的MVP其實是測試具體假設的最小可行實驗，稱作“MVP測試”更為恰當，這樣可以避免混淆“實驗”和真實“產品”[5]。這裡的“MVP測試”其實就是原型。
在《Managing Software Requirements:A Use Case Approach》一書中，不止一次提到原型是應該用完即棄的，是個一次性的玩意兒。在日常專案中，也都是用Axure等工具進行高保真原型開發，而真實產品開發則是另起爐灶。原型和產品隔離，一方面可以加速原型開發、激發創意，另一方面可以提高產品穩定性，因為避免了通過對原型進行修修補補來製造產品。而MVP呢？是最小可行產品，也是第一代產品，是可以讓使用者使用的產品——儘管功能不豐富。原型背後的邏輯都是軟體模擬的、是假的、使用者是不能真正用其解決問題的，它只是看起來像真的而已。因此，在上文的兩個例子中，Dropbox的視訊是原型，Steve Blank建議的遙控飛機是MVP。
（原型和MVP比較）
知道了原型和MVP的區別，那麼我們是不是需要在驗證創意的時候猶豫用哪個呢？其實大可不必糾結在概念上，還是那句最實用又最沒用的話，視情況而定。當然，通用原則還是有的：如果產品複雜度高，那麼建議先嚐試原型、再開發MVP；如果產品開發不復雜，如Unsplash（例子可以看《如果你有一個創意》），那大可以直接產出MVP。再次強調，不要在區分概念上鑽牛角尖，區分的目的是在於更好的交流討論和融會貫通。無論是MVP還是原型，又或是MVP測試，認準了，就動手吧！
【花事】
在為本週文章蒐集材料時，看到一些有關Apple的軼事，忍不住又寫了一段題外話：
神祕的Apple
每一次iPhone的釋出，都是各種“內部訊息”“揭祕”類資訊大火的時刻，就拿iPhone 8來說，前置指紋識別、後置指紋識別、側面指紋識別，以及沒指紋識別（人臉識別代替指紋），各種說法都煞有介事，吃瓜群眾也紛紛捧場。正是Apple這種接近神祕的保密舉措，吊足了大眾胃口，才引起了各種猜測——從產品的猜測到運作的猜測。據說，早在1977年，當Apple還是一家初創公司時，在大廳裡就有一塊寫著“言多必失”（loose lips sink ships，直譯是“口風不緊船艦沉”）的告示牌。因為作為一家硬體公司，Apple知道如果新產品細節被洩露的話，會危及到現有產品的銷售，所以Apple在早期就已經把保密作為企業文化。Apple不允許員工告訴合作商他們當前的工作；不允許無關人員參加會議，以至於在一個會議中，當下一個主題與你無關時，你將會被邀請離開；實驗室中的未釋出產品都用黑布蓋住，以免被不相關的人員看到[6]。更有甚者，API名稱都會偽裝，在iPhone 5S釋出以前，iOS7 beta版已經發布了一段時間，為了防止其他開發者通過iOS介面名稱提前知悉iPhone 5S的靜止影象穩定功能，於是相關的介面名稱：
(BOOL)isStillImageStabilizationActive;
被偽裝成了[7]：
(BOOL)isYoMamaWearsCombatBootsActive;