什麼是 MVP？最小可行產品白話解說
MVP，即最小可行產品，是真實的人能夠使用並獲得真正價值的最小版本產品，它的建置目的，是讓你學習這個想法是否值得繼續投入。「最小」代表你排除了所有對核心工作而言並非必要的東西；「可行」代表剩下的部分對真實使用者來說確實能運作。重點不在於推出一個便宜的東西，而是在花上好幾個月建置錯誤的產品之前，先找出人們真正想要什麼。
這個詞的由來，以及它為何重要
這個用語是由 Eric Ries 的《精實創業》（The Lean Startup）以及更廣泛的精實創業運動所推廣的，它把產品建置視為一系列實驗：先建置小型的東西，衡量人們如何使用它，從中學習，然後加以調整。
當你用 AI 建置時，MVP 的概念既變得更容易，也變得更重要。
- 更容易，因為現在建置一個可運作的第一版只需要幾天而不是幾個月，成本也低得多。
- 更重要，因為現在很容易想要不斷加入功能。當每個新功能只差一個提示詞時，克制地不做某些事，正是讓你的 App 保持專注、並讓早期使用者的回饋保持清楚的關鍵。
日常生活的比喻
想像你想開一家餐廳。在簽下十年租約、裝潢廚房之前，你先在週末的市集擺一個攤位，只賣三道菜。
這個攤位很小，但它不是假的。人們付的是真錢，吃的是真食物。經過幾個週末，你就知道哪一道菜會先賣完、客人願意付多少錢，以及他們會不會回頭。這就是 MVP。
你從沒做過的一道菜的照片，是原型。開幕當晚的完整餐廳，則是成品。攤位位於兩者之間：足夠真實，能教你真正的事；又足夠小，即使判斷錯誤也不是災難。
MVP、原型與其他名詞
| 名詞 | 它是什麼 | 誰使用它 | 是否需要真正運作？ |
|---|---|---|---|
| Mock-up（樣稿） | 畫面可能長什麼樣子的圖片 | 你和你的團隊 | 不需要 |
| Prototype（原型） | 可點擊的模型，通常使用假資料 | 你、少數測試者、投資人 | 部分需要 |
| Proof of concept（概念驗證） | 證明某件事在技術上可行的測試 | 你或開發人員 | 只需要驗證有風險的部分 |
| MVP（最小可行產品） | 能提供價值的最小真實產品 | 真實的早期使用者或客戶 | 需要 |
| MLP／MMP | 「最小可愛產品」或「最小可行銷產品」，即帶有更多打磨的 MVP | 更廣泛的上市受眾 | 需要，且經過打磨 |
| V1 | 你會廣泛行銷的第一個版本 | 大眾 | 需要 |
你還會聽到其他用語：
- 核心循環（Core loop）：使用者重複做的主要事情，例如「發布工作、收到應徵」。
- 最危險的假設（Riskiest assumption）：如果錯了，就會讓這個想法失敗的信念。你的 MVP 應該先測試它。
- 驗證（Validation）：證明人們想要（或願意付費使用）這項產品的證據。
- 迭代（Iteration）：根據你學到的東西，以小幅的循環改進產品。
實例：遛狗預約 App 的 MVP
你的想法：一個讓城市裡的狗主人預約經過審核之本地遛狗員的 App。
你最危險的假設可能是：「飼主會透過 App 預約並付款給陌生人。」而不是「飼主想要即時 GPS 地圖來追蹤遛狗過程。」
完整的願景包括：遛狗員檔案與評價、即時 GPS 追蹤、App 內聊天、訂閱、遛狗員薪資發放、評分系統、推播通知、推薦計畫，以及遛狗員註冊流程。
MVP：
| 包含 | 暫時不做 |
|---|---|
| 一份你親自審核過的遛狗員清單，包含照片、服務區域與價格 | 遛狗員自行註冊與審核流程 |
| 預約表單：狗狗、日期、時段、地址 | 定期訂閱 |
| 預約時透過託管結帳付款 | 自動發放遛狗員薪資（你手動支付） |
| 寄給飼主與遛狗員的確認電子郵件 | 推播通知 |
| 一個簡單的管理頁面，讓你看到所有預約 | 即時 GPS、App 內聊天、評價 |
你可以在一個社區試營運一個月。如果飼主反覆預約，你就學到了值得在此基礎上建置的東西。如果他們沒有預約，你就以低成本發現了問題，而且可以直接問他們為什麼。
請注意，有些「暫時不做」的項目是靠人工完成的。手動支付遛狗員或自行審核他們，無法規模化，但在目前階段不需要規模化。在簡單的 App 背後以人工處理事務，是最有效的 MVP 技巧之一。
常見錯誤與迷思
- 「最小」變成「壞掉」。 一個會遺失預約或看起來不可信的 MVP，測試的是你的錯誤，而不是你的想法。保持規模小，但要讓已經做出來的部分運作正常。
- 為所有人建置。 針對「任何需要 X 的人」的 MVP 很難測試。請挑選一群你能接觸到的特定使用者。
- 只顧著加功能，而不跟使用者談。 當早期數據令人失望時，解決方法很少是再加一個功能。請問使用者是什麼阻止了他們。
- 跳過真正的測試。 候補名單的註冊顯示的是興趣；付款或反覆使用才顯示價值。請事先決定什麼樣的結果才算成功。
- 把 MVP 當成用完即丟。 使用 AI 建置工具時，MVP 的程式碼往往會成為真正的產品。從一開始就使用真正的資料庫，並妥善完成登入，這樣它才不必從頭來過。
- 永遠無法完成。 設定上線日期，並砍掉功能來達成它，而不是反過來。
如何用 AI 規劃 MVP 的範圍
- 寫下一句話。「[誰] 能夠 [做什麼]，以便 [獲得什麼成果]。」例如：「利茲的狗主人可以預約經過審核的遛狗員，讓他們明天不必請假離開工作崗位。」
- 列出你想像中的每一項功能。 把它們全部從腦中倒出來。
- 為每一項標記「測試想法所需」或「之後再說」。 要嚴格。大多數都應該放在「之後再說」。
- 決定哪些事情你要手動做。 薪資發放、新人審核、客服。
- 定義成功。「四週內 20 筆付費預約」是可以測試的。「大家喜歡它」則不行。
- 建置、推出給小群體，然後觀察。 再進行迭代。
如需更深入、逐步的協助，請參閱如何驗證 App 想法與如何建置 SaaS MVP。
向你的 AI 建置工具要求什麼
- 「這是我的想法與我最危險的假設。請建議能測試它的最小版本，並列出應該排除的項目。」
- 「只建置這五項功能。在我同意之前，不要加入任何其他東西。」
- 「從一開始就使用真正的資料庫與完善的登入，讓它之後能發展成真正的產品。」
- 「加入一個簡單的管理頁面，讓我可以看到每一筆預約，並手動處理事務。」
- 「加入基本的分析或事件紀錄，讓我看到有多少人完成了預約。」
- 「上線前，請檢查明顯的安全問題：誰能看到哪些紀錄，以及是否有任何金鑰外洩。」
使用 Mythex 建置 MVP
Mythex 很適合用來建置 MVP：你在聊天中描述第一個版本，在即時預覽中試用，準備好時再發布到公開網址，並在 App 需要時加入 Postgres 資料庫與檔案儲存空間。Plan 模式對規劃範圍很有用：在寫任何程式碼之前，請 Agent 先提出一個最小版本。Free 方案包含發布功能，因此你可以在付費之前就把 MVP 呈現在使用者面前；Pro 方案則在想法開始奏效時，提供自訂網域、程式碼匯出與 GitHub 同步，請參閱價格。文件中的 SaaS MVP 教學可以參考，而當你準備好尋找使用者時，請閱讀如何推出 App 並取得第一批使用者。
常見問題
MVP 代表什麼？
MVP 代表最小可行產品（minimum viable product）：真實的人能夠使用並獲得真正價值的最小版本產品，它的目的是讓你學習這個想法是否值得繼續投入。
MVP 和原型有什麼區別？
原型展示某件東西可能看起來或運作起來的樣子，通常使用假資料，用來在內部或與少數人一起測試想法。MVP 則是真實客戶為了真實目的而使用的產品，因此它必須真正能運作，例如要能儲存資料、寄出電子郵件、完成付款。
建置一個 MVP 應該要花多久時間？
沒有固定的規則，但花得越久，就越有可能已經超出最小範圍。使用 AI App 建置工具時，一個專注於簡單工具的 MVP，往往可以在幾天內運作，而不是幾個月。目標是盡快把它呈現在使用者面前。
MVP 應該有多少功能？
在能夠提供你的使用者所關心之唯一成果的前提下，越少越好。許多好的 MVP 只做一件工作，而且從頭到尾完整可用。任何無助於測試你主要假設的功能，都可以延後。