什麼是最小可行產品#
**最小可行產品（Minimum Viable Product, MVP）**這個概念由賴瑞斯（Eric Ries）在《精實創業（The Lean Startup）》中推廣：把產品剝去所有非必要功能，留下最少的版本快速上線，用真實市場回饋驗證假設。
MVP 不是「劣質的半成品」，而是鎖定一個核心功能、做到位——拿掉所有不能驗證假設的東西。
失敗的反面：隱形模式#
**隱形模式（stealth mode）**指完全不取得任何使用者回饋，悶頭開發直到「完美版本」上線。實務上幾乎不會成功，原因有六：
Figure 3-1: 隱形模式——把 app 藏到完美再公開的迷思。
1. 失去動機#
獨自鑽研時間越久，懷疑越多——可能發現市面上已有類似工具，或開始相信「這做不出來」。早期使用者哪怕一句鼓勵都能撐住熱情。
2. 注意力被分散#
工作、家人、新點子、各種 app 都搶你的注意力。隱形時間越長，還沒上線就分心放棄的機率越高。
3. 進度失控#
你估 60 小時、計畫每天 2 小時、一個月做完。但實際每天只做 1 小時、bug 無預警冒出、研究時間爆增。MVP 因為功能少，規劃誤差也少、進度更可預測——這也是投資人愛 MVP 的原因。
4. 沒有回應#
你終於上線，結果一片寂靜——這是軟體專案最常見的結局。寂靜代表你沒命中產品市場契合（product-market fit）。沒回饋就會偏離現實，做沒人要的功能。
5. 假設錯誤#
最致命的是你最初的假設多半是錯的。作者 Christian 自己做 Finxter.com 的真實經歷：
- 假設使用者多是電腦科學系學生 → 實際多半不是
- 假設一上線就會有人來 → 實際沒人來
- 假設使用者會在社群分享成績 → 只有極少數會
- 假設使用者會自己投稿題目 → 數十萬使用者中只有零星幾人投稿
- 假設要花俏設計才好用 → 簡單極客風反而更受歡迎
每個錯誤假設都帶來幾十甚至上百小時的浪費。
6. 多餘的複雜度#
假設四個功能 A/B/C/D 一次推出，市場接受了。但你不知道：
- 其實只有 D 帶來價值，A 完全沒人用？
- 還是 B+C 才是關鍵？
n 個功能有 2ⁿ 種組合，一次塞滿就無從知道哪個有用。
Figure 3-3: 一個由四個功能組成的軟體產品。
Figure 3-4: 哪些功能組合才是市場真正接受的？
多餘功能的代價是長期的：
- 載入專案、編譯時間更長
- 每個功能都是新 bug 的溫床
- 加新功能 n 時，要確認不會干擾前面 1 到 n-1
- 每個功能都要新測試
- 程式碼庫越複雜，新人上手越慢
解法：建立一連串 MVP#
把「想驗證的假設」明確寫下來，做出只能驗證這個假設的最小產品；上線、學習、進入下一個 MVP。這個策略稱為快速原型開發（rapid prototyping）。
程式碼搜尋引擎範例#
- 假設：程式設計師需要搜尋程式碼。
- 第一個 MVP：不寫複雜後端，只架一個有輸入框的網站，背後用 Google 搜尋結果做後處理。
- 觀察：100 筆查詢中，90% 是貼錯誤訊息，60 筆與 JavaScript 有關。
- 下一步：把產品從「通用程式碼搜尋」收斂為「JavaScript 錯誤訊息搜尋」。
沒有第一個 MVP，可能會花好幾個月做正則表達式搜尋這類幾乎沒人用的功能，反而忽略所有人都用的錯誤訊息搜尋。
兩階段流程#
階段 1：透過反覆 MVP，找到 product-market fit
階段 2：每次只加一個功能，用 split test 驗證；無效就砍
Figure 3-5: 軟體開發的黃金標準——先用反覆 MVP 找 product-market fit，再透過 split test 加新功能。
Dropbox 的經典案例#
Dropbox 並沒有先實作複雜的雲端同步系統。創辦人先拍了一支示範影片——影片中的功能甚至還不存在——以此驗證需求。看到熱烈迴響後，才動手實作核心。
MVP 的四大支柱#
「極簡」不等於「粗糙」。MVP 必須在這四個面向都是高品質的。
- 功能性（Functionality）：清楚提供一個功能、做得好。可以不具經濟效率——例如聊天機器人 MVP 就是你親自跟使用者聊天。
- 設計（Design）：設計要支援價值主張。Google 早期搜尋頁設計很簡單，但為「無干擾搜尋」這個價值服務得很到位。
- 可靠性（Reliability）：寫測試、嚴謹驗證每個函式。否則你收集到的負評是「不穩定」造成的，學不到對功能本身的回饋。
- 可用性（Usability）：必須好上手、夠快、夠流暢。功能越少越容易達到——一個按鈕一個欄位，使用者不會迷路。
MVP 的優勢#
- 用最低成本驗證假設
- 在不確定要不要寫之前不寫程式碼
- 寫程式時間更少、找 bug 時間更少
- 持續推進新功能 = 持續累積真實回饋與動力
- 程式碼庫保持精簡，未來功能更易實作、bug 更少
- 上市更快、變現更快、品牌建立更穩
隱形模式的迷思：「我的點子會被偷」#
很多人堅持隱形模式是擔心點子被剽竊。
點子很便宜，執行才是王道（execution is king）。你的點子大概率早就有人想過。隱形反而可能讓對手更早跑出來——他們和你一樣以為沒人想到。
多年後勝出的，是那個早早出手、頻繁迭代、把使用者回饋吸收進產品的人。
結論#
- 寫程式之前，先想清楚使用者需要什麼。
- MVP 要有價值、設計到位、反應快、好用。
- 把所有非必要功能砍掉，一次專注一件事。
- 早發布、頻繁發布，靠迭代逐步加功能。
- 想下一個功能該不該做的時間，要比實作該功能的時間多。
- 用 split test 驗證新功能對留存、停留時間、活躍度的影響——無效就砍。
下一章將探討如何寫出乾淨而簡單的程式碼。但請記得：不寫多餘的程式碼，是通往乾淨程式碼最可靠的路。