最小可行產品：少做一點，學得更快

來自 FabricLoop 團隊 · 2026 年 5 月 · 9 分鐘閲讀

「MVP」這個詞被用得太頻繁、太隨意，幾乎已失去原本的意義。創辦人拿它來形容精心打磨的 v1 上線版本、粗糙的原型、登陸頁面，以及介於其間的一切。有些人把它當成推出殘缺產品的藉口，也有人把它當成永遠做不完的理由（「還不夠可行」）。

原始定義出自 Eric Ries 的《精實創業》（The Lean Startup），非常精確：MVP 是讓您以最少的努力，蒐集到最多有關客户之「驗證性學習」的產品版本。它是學習工具，而不是產品上線。

最關鍵的字：可行

「最小」並不是難處。創辦人天生傾向於砍功能。真正困難的是「可行」。可行的產品所提供的價值，要足以讓人真的去使用它、給您誠實的回饋——最理想的情況是願意付費。

沒人使用的 MVP 什麼都教不了您。附有電子郵件註冊的登陸頁面，只能告訴您大家對這個概念有興趣，卻無法説明您的解決方案是否真的解決了他們的問題。第一分鐘就當掉的殘缺原型，只能算「最小」，談不上「可行」。

常見的錯誤 做出的是您想像中的最小版本，而不是能為特定用戶提供核心價值的最小版本。這兩者並不相同。前者是隨意的；後者是有紀律的。

看待 MVP 最好的方式，是把它當成一項有明確假設的實驗。在動手打造任何東西之前，請先寫下：

任何 MVP 的假設結構

假设

「我們相信[客户族羣]想要[成果]，因為[原因]。」

测试

「我們將打造[最小的東西]，來測試他們是否會在[時間範圍]內做出[具體行為]。」

信号

「如果[可衡量的結果]，我們就知道假設成立；若[相反的結果]，則假設不成立。」

如果您無法説明什麼情況代表假設不成立，那您就不是在檢驗假設——而是在做產品。MVP 唯有在您事先承諾「不成立」是什麼樣子時才有效。

「沒有可證偽假設的 MVP，只是一個低質素的產品。兩者並不相同。」

MVP 存在於一條從完全手動到完全自動化的光譜上。您應該落在光譜的哪個位置，取決於您想學到什麼，以及您願意為這次測試投入多少。

MVP 擬真度光譜

禮賓式服務（Concierge） 以手動方式提供價值，不使用軟件。在自動化之前，先了解這個成果是否重要。

綠野仙蹤式（Wizard of Oz） 向用戶展示可運作的介面，但在幕後以手動方式履行。不需要基礎架構就能測試需求。

原型可點擊的模型或基本功能版本。測試可用性與流程，而非完整的可靠度。

功能型 MVP 只具備核心功能、可部署的產品。測試真實使用情況、留存率與付費意願。

許多創辦人直接跳到「功能型 MVP」，因為它感覺最正式。但禮賓式 MVP——為 10 位客户手動提供服務——往往在兩週內教會您的，比六個月的開發還多。目標是學習，而不是產品。

範圍的取捨正是大多數 MVP 出錯的地方。以下是決定納入哪些內容的框架：

納入 MVP

從 MVP 中砍掉

檢驗方式：對於您考慮加入的每個功能，問自己「這能讓我們學到什麼？」如果答案是「沒有——只是更好用」，就先砍掉。等驗證核心有效之後，再來做。

兩者並不相同，混為一談會造成問題。MVP 是為了驗證假設而設計的實驗。測試版則是您預期推出之產品的早期版本，在正式發布前釋出供測試。

MVP 在實驗結束後可能完全丟棄。測試版通常則是您最終要推出之產品的基礎。MVP 的設計目的，是讓每一分努力換取最多的學習；測試版的設計目的，是在接近完成的產品中找出錯誤。

您可以在寫下第一行代碼之前就有 MVP；但在產品大致完成之前，不可能有測試版。

回到您的假設。MVP 是否「成功」，不是看人們説了什麼好聽話，而是看他們有沒有做出您預測的具體行為。稱讚不是驗證；承諾——時間、金錢、重複使用——才是驗證。

以下三個訊號顯示您的 MVP 驗證了假設：

以下三個訊號則顯示假設不成立：

「您願意為此付費嗎？」測試 如果您不確定回饋是否真實，就直接問：「您願意為此每月支付 $X 嗎？」然後閉上嘴。接下來的沉默，是早期產品驗證中最能説明問題的數據點。

FabricLoop 如何支援 MVP 流程 MVP 階段會產生大量回饋——用戶訪談、使用過程筆記、問卷回覆、團隊辯論。FabricLoop 將您的假設、測試結果與歸納整理保存在同一條討論串中，讓團隊即使在數月之後，也能看到您學到了什麼，以及當初為何做出那些決定。