MVP 最小可行產品

能驗證核心價值的最小版本，不是陽春版完整產品。

先用一句話理解

英文全名：Minimum Viable Product

能驗證核心價值的最小版本，不是陽春版完整產品。

打個比方

像先開快閃攤位驗證餐點受不受歡迎，再決定是否開餐廳。

什麼時候會遇到

產品想法還沒被市場或客戶驗證時。

再往深一點看

MVP 的核心問題是：哪一件事是你現在最需要驗證的假設？它不是「做少一點」，而是刻意只保留能測試核心假設的那塊——其他的都先不做。MVP 的邊界由 scope 來定義：你要把哪些功能畫進這次要驗證的範圍，哪些明確排在外面等到假設被確認後再說。一個 MVP 不一定是完整的 app，可能是一個假按鈕、一份 Google 表單，甚至只是一段手動流程——重點是用最小的資源得到最真實的使用者反應。

舉個例子

你想做一個訂閱電子報的 SaaS，MVP 不是做整個後台，而是先用 Notion 頁面說明價值、一個 Stripe Payment Link 收費，手動寄出第一封信——確認有人願意付錢後，再開始用 Next.js 開發真正的系統。

常見誤解

- 把所有想做的功能都塞進第一版，結果花了三個月才上線，卻發現核心假設根本站不住腳，等於白做。
- 把 MVP 理解成「功能少但每個功能要做完整漂亮」，反而在打磨細節上花太多時間，失去快速驗證的意義。
- MVP 上線後沒有設定要驗證什麼問題、怎麼量測結果，只是「先丟出去看看」，最後收不到可以決策的資訊。