MVP 範圍設計：只做能證明付費假設的第一版

這集你會學到 ・為什麼「完整產品」是一人 SaaS 最危險的陷阱 ・Must / Should / Cut 功能分類框架 ・怎麼從付費假設反推第一版功能 ・用 Claude 幫你做功能優先級決策 ・這集產出物：MVP 範圍文件 + Must/Should/Cut 功能表 驗證完了，然後呢？ 你走完第 03 集的驗證流程，收到 3 筆預付，確認有市場。 現在大部分人做的事：把腦子裡所有功能列出來，開始建。 這是錯誤的。 過度開發是一人 SaaS 最常見的死因之一。不是技術問題，不是市場問題，是範圍失控——你花 3 個月建了 20 個功能，但用戶其實只需要 3 個。 付費假設是什麼 在你驗證的時候，用戶是為了「某一件具體的事」預付的。 那一件事，就是你的付費假設。 範例： ・用戶預付是因為「幫我把 Reddit 抱怨自動整理成可行動的痛點清單」 ・不是因為「我要一個完整的市場調查 SaaS」 MVP 的任務是：只建出能證明這個付費假設的最小版本。 Must / Should / Cut 框架 把所有想做的功能列出來，用三個分類： 分類　·　定義　·　問自己 Must　·　沒有這個，付費假設就無法成立　·　少了它，用戶還會付錢嗎？ Should　·　讓體驗更好，但不影響核心假設　·　沒有它，用戶還是能用嗎？ Cut　·　好想做但跟核心假設無關　·　這是我想要還是用戶需要？ 規則：MVP 只做 Must，其他全部砍掉。 用 Claude 做功能優先級決策 把你的功能清單丟給 Claude，用這個 prompt： ` 我正在做一個 SaaS，付費假設是：「[你的假設]」 以下是我想做的功能清單： [貼上你的功能列表] 請幫我用 Must / Should / Cut 框架分類，並說明理由。 Must = 沒有就無法證明付費假設 Should = 有更好但沒有也能用 Cut = 跟核心假設無關 最後給我一個 MVP 範圍建議。 ` 範圍控制的黃金規則 一個 Must 功能 = 一週開發時間上限 如果你的 Must 清單加起來超過 4...