什麼是MVP(最小可行產品)?

定義

MVP是Minimum Viable Product的縮寫,意思是「只包含核心功能的產品」。簡單來說就是「能用的最簡單版本」。

讓我舉個例子。假設你的朋友想做一個外賣應用程式。做一個完美的應用程式需要什麼?漂亮的設計、即時配送追蹤、多種支付方式、評價系統、優惠券、積分、AI推薦...做這些全部需要一年時間和數百萬美元。但是做完之後如果人們不用呢?你就浪費了所有的時間和金錢。

MVP方法不同。首先,你只建構核心功能:「查看餐廳列表 + 電話訂餐」——就這兩件事。甚至不是應用程式,只是一個簡單的網站。這可以在2週內用2000美元完成。在一個社區測試它。如果人們使用,就一個一個添加功能。如果不用,就快速改變方向或放棄。你節省了時間和金錢。

特點

• 只有必需品 - 只包含必需的功能,而不是好用的功能。刪除80%的功能,只保留20%
• 快速建構 - 以週為單位完成,而不是月。快速推向市場很重要
• 成本低 - 用完整產品成本的10-20%建構。即使失敗損失也不大
• 真實驗證 - 看真實使用者的反應,而不是想像。不是「這個想法好嗎?」而是「人們真的會用嗎?」
• 持續改進 - 不是一次完成,而是逐步發展。版本1、2、3...這樣

使用方法

讓我們逐步學習如何正確建構MVP。假設你要開始一項新服務。

步驟1:明確問題 首先,你需要明確要解決什麼問題。「人們有什麼不方便?」「我要解決什麼?」例如「健身房預約不方便」、「自由工作者難找工作」、「二手交易怕被騙」。問題明確了,解決方案也就明確了。

步驟2:定義核心價值 解決這個問題最重要的一點是什麼?例如對於健身房預約應用程式,核心是「能在想要的時間預約」。漂亮的設計、社交登入、新增好友——這些以後再說。專注於一個核心價值。

步驟3:建立最小功能清單 傳遞核心價值最少需要什麼?對於健身房預約應用程式:查看健身房列表、查看時間表、預約、取消預約。只有這四件事就能運作。刪除評論、好友邀請、積分、推播通知。你可以以後新增它們。

步驟4:用最簡單的方法建構 你不需要從一開始就建構應用程式。有更簡單的方法。例如:透過Google表單接受申請、透過KakaoTalk傳送通知、用Excel管理、只做一個簡單的網頁、使用現有工具(Notion、Airtable)。這樣你可以不編碼、不花錢就建構MVP。

步驟5:在2-4週內完成 快速建構是MVP的關鍵。目標是2-4週。如果時間更長,你會想做得完美。「讓我們也加這個那個...」然後就花了6個月。不要那樣做——快速建構,快速測試。

步驟6:先在小群體中測試 不要全國推廣,先在小群體中測試。10個朋友、社區的1家健身房、學校的一個班。在這個規模測試可以快速發現問題。即使有大問題,也只是在10個人面前尷尬,而不是被1000人批評。

步驟7:獲得回饋 問使用者:「什麼不方便?」「你最需要什麼功能?」「你會為此付費嗎?」這些問題告訴你接下來要建構什麼。你遵循真實使用者的需求,而不是你的想像。

步驟8:測量關鍵指標 測量有多少人使用、重複使用多少次、是否願意付費。對於健身房預約應用程式:「每週有多少預約?」「同一個人會進行第二次預約嗎?」這些很重要。看數字就能清楚成功還是失敗。

步驟9:繼續改進或轉型 如果結果好,就一個一個新增功能。如果結果不好,就改變方向。你可能會發現:「我們更需要教練配對而不是預約功能。」這叫做「轉型(Pivot)」。與最初計劃不同也沒關係。這不是失敗,是學習。

步驟10:驗證後認真投資 如果你用MVP確認了「人們真的想要這個」,那麼就認真開發和投資。在漂亮的設計、各種功能和行銷上花錢。因為已經驗證過,失敗率低得多。

例子

例子1:Dropbox Dropbox是雲端儲存服務。創始人最初沒有建構實際產品。相反,他製作了一個3分鐘的示範影片並發佈到YouTube上。「這樣的服務怎麼樣?」影片展示了檔案在多台電腦上自動同步。反響爆炸性。一天之內,5000人註冊了等待名單,最終達到75000人。只有那時他們才開始建構實際產品。他們用一個影片驗證了想法。比花數百萬美元建構然後說「沒人用」聰明得多。

例子2:Airbnb Airbnb的創始人為房租發愁。他們聽說舊金山有一個大型會議,所有飯店都訂滿了。他們在客廳裡放了3個充氣床墊,一天內做了一個叫「Air Bed and Breakfast」的網站。沒有複雜的系統,只有幾張照片、聯絡方式、當面付款。三位客人每天付80美元。「這行得通?」他們逐漸擴大,現在是一家價值數百億美元的公司。如果他們從一開始就建構完美的應用程式,可能會失敗。

例子3:Zappos(鞋子購物商城) Zappos是線上鞋店。創始人想知道「人們會線上買鞋嗎?」如何確認?不囤貨測試。他去社區鞋店拍鞋子的照片並發佈到網站上。有訂單來了?他去那家鞋店,按原價購買,然後寄給客戶。他虧了錢但學到了重要的東西:「人們會線上買鞋!」有了這個信心,他建立了一個正規的購物商城,最終以10億美元賣給了亞馬遜。如果他從一開始就投資倉庫、庫存和系統,可能會失敗。

例子4:Twitter Twitter最初是一家播客平台公司。進展不順利。員工們製作了一個簡單的訊息工具用於內部溝通。簡短回答「你現在在做什麼?」開發時間:2週。他們在內部試用,很有趣。他們向朋友開放,反響很好。「嘿,這比我們的主業還好?」他們完全改變了方向。他們放棄了播客,專注於Twitter。沒有內部測試,他們不會有這個發現。這就是MVP精神。

優缺點

優點

• 節省時間和金錢 - 不用花一年和數百萬在完整產品上,你可以在2週內用數十萬測試。即使失敗,損失也很小
• 快速發現失敗 - 在2週內發現「這不對」比在6個月建構後「沒人用」好得多。快速失敗意味著快速學習和快速改變
• 用真實資料決策 - 基於真實使用者行為做決定,而不是想像或猜測。「人們可能會喜歡這個」vs「1000人真的用了」——哪個更確定?

缺點

• 品質較低 - MVP字面上是最小的。有bug、設計差、很多不便。早期使用者可能會失望
• 在第一印象重要的市場有風險 - 在某些市場,第一印象就是一切。在奢侈品牌、高階產品或安全很重要的醫療裝置中,「讓我們先粗略做」行不通
• 以後可能需要重建 - 作為MVP快速建構的東西基礎薄弱。以後建構正規產品時,你可能要從頭開始

常見問題

問:MVP必須是軟體或應用程式嗎? 答:完全不是!MVP是測試想法的方法,不一定是產品。例如:1)著陸頁 + 郵件收集:「如果這個產品出來你會感興趣嗎?」並收集郵件。2)人工服務:在做應用程式之前讓人手動處理。3)群眾募資:透過Kickstarter確認需求。4)線下活動:用快閃店測試一天。5)調查:問100個人。用最快最便宜的方式確認「人們想要這個嗎?」就是MVP。

問:建構MVP應該花多長時間? 答:理想情況下是2-4週。最晚在2-3個月內應該有可測試的版本。如果超過6個月,就有問題了。你試圖包含太多功能。「我們還需要這個那個...」然後時間就過去了。相反,把它減少到「這就是我們讓它運作所需的全部」的水平。刪除80%的功能,只保留20%。其餘的可以在驗證後新增。

問:我的MVP太簡陋,我很尷尬? 答:這很正常!MVP本來就應該簡陋。你看過早期Facebook、蘋果的第一個產品或亞馬遜的早期網站嗎?都很簡陋。重要的不是「完美的第一印象」而是「傳遞核心價值」。早期使用者會理解。他們甚至可能會為你加油說「還有不足但顯示出潛力」。但是,核心功能必須正常工作。設計可以差,但承諾的功能必須可靠。如果是「配送時間追蹤應用程式」但追蹤不工作,那就不行。

問:我用MVP測試了但反響不好。我應該放棄嗎? 答:不一定。首先分析。1)想法本身不好?還是實現不好?問使用者:「這個想法本身不必要?」vs「好但這不方便」。2)目標錯了?你可能給大學生看了,而工作的人才真正需要它。3)推廣不夠?如果只有10個人看到,那不是足夠的測試。至少需要100-1000人看到。檢查這些並嘗試2-3次改進後仍不成功,那就轉向另一個想法。第一次嘗試就成功很少見。Twitter也是在轉型後成功的。