本文的主要內容會按照是什么、為什么以及如何做的邏輯展開，主要包括以下幾部分：
- 什么是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；如果產品開發不復雜，如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;