MVP 6 週上線
完整流程 + Founder 必知陷阱

MVP 不是「功能少一點的產品」、是「驗證一個假設的最便宜方法」。這篇拆 6 週時程 ─ 從假設驗證、scope 切分、技術選擇、定價、上線到首批用戶。給非工程背景 founder、想自己做的 indie hacker、或想做副業 SaaS 的工程師。

※ 本文 MVP 概念參考 Eric Ries《The Lean Startup》框架整理、加上實作觀察。實際表現受市場、執行、運氣影響。

先打掉3 個 MVP 迷思

01 「MVP 就是 beta 版」

錯。

MVP（Minimum Viable Product）不是「功能少的產品」、是「能驗證一個商業假設的最小版本」。

差別：

• Beta 版：產品基本功能都有、但還有 bug
• MVP：可能只有 1 個核心功能、但能回答「用戶會付錢嗎」這個問題

02 「MVP 一定要做 app / web」

也錯。

很多最有效的 MVP 是：

• 一個 landing page + 「付費等候名單」表單
• 一個 Google Form + 你手動用 Excel 處理
• 一個 Notion 頁面當「產品」、用 Stripe 收錢
• 一個 WhatsApp / LINE 群組、你當客服 + AI 在後面

這些都是合法的 MVP。能驗證假設的最便宜方法、就是對的方法。

03 「MVP 完美了再上線」

這是創業者最常見的死法。

MVP 的重點是「面對真用戶」。在你自己電腦上跑得多完美都沒用 ─ 用戶會做你想不到的事、發現你想不到的問題。

MVP 上線那天、你會很尷尬。
這是正常的。
尷尬代表你真的早期上線、不是過度準備。

第 0 週 ─ 驗證假設（最重要的一週）

這週你不寫任何 code。

你要做的：

① 寫出你的「核心假設」

模板：

「[誰] 有 [什麼問題]、嚴重到願意付 [多少錢/月] 給我用 [什麼方式] 解決。」

例：「獨立接案工程師有「追蹤多個客戶開立發票、收款進度混亂」的問題、嚴重到願意付「NT$300/月」給我用「專為自由工作者設計的記帳工具」解決。

這個句子要具體到能讓你「跟某個真人聊 10 分鐘就能驗證」。

② 找 5 個目標用戶聊

不要問「你會用我的產品嗎」 ─ 大家都會說會、然後不付錢。

要問：

• 「你現在怎麼解決 X 問題？」
• 「你上次因為這個問題卡住、是什麼時候？」
• 「你之前花過多少錢試圖解決它？」
• 「如果有個工具能 [描述]、你願意付多少？」
• 「為什麼你還沒自己解決？」

這些問題會逼出真實 ─ 你會發現一半的假設是錯的。

③ 決定 MVP 的「1 個核心問題」

訪談完、選出「用戶最痛的 1 件事」 ─ 你的 MVP 只解這 1 件。

其他「nice-to-have」、上線後再說。

Week 1 ─ 準備期

重點 ─ landing page 第一天就要能傳給用戶。沒人看的 MVP 是不存在的。

Week 2-3 ─ 核心功能

這 2 週的關鍵 ─ 用戶比 code 重要。你不是在寫 code、你在驗證假設。

Week 4 ─ 上線準備

重點 ─ Alpha 用戶不要收錢。他們是幫你 debug、不是付費用戶。

Week 5 ─ 修最關鍵的 5 個問題

Week 6 ─ 真正上線

你的第 1 個付費用戶 ─ 不論金額大小、是 MVP 階段最大的勝利。慶祝它。

4 個 Founder 必知陷阱

01 陷阱 1：「等做完所有功能再上線」

這是創業者的 #1 死法。

症狀：

• 本來 6 週、做到第 8 週還沒上線
• 每天加新功能、舊功能改不完
• 害怕用戶看到「不完美的版本」

解法 ─ 訂一個強制上線日、不管完不完整、那天一定 push 上去。

02 陷阱 2：「朋友都說會用」 = 「沒人會付」

朋友會說「哇好酷、會用會用」、然後不付錢、也不真的用。

解法 ─ 別問朋友、找陌生目標用戶。他們不認識你、會給你真實反饋。

找陌生用戶的地方：Reddit subreddits、Facebook 社團、PTT 看板、LinkedIn、相關 Discord 群。

03 陷阱 3：「用戶說想要 X、我們做 X」

用戶說「我要更快的馬」、別給他更快的馬、給他「汽車」。

用戶很會講「症狀」、不太會講「真正的問題」。

解法 ─ 用戶反饋來、問「為什麼？背後的目的是什麼？」、直到挖到真正的痛點。

04 陷阱 4：「有人付錢了 = 產品 viable」

1-2 個付費用戶可能只是「你的人脈」、不代表市場接受。

真正的 viable 訊號：

• 10+ 陌生用戶付費（不是你認識的）
• 用戶主動推薦給朋友（口碑）
• 第 2 個月續訂率 > 60%
• 有人 email 你說「怎麼還沒做 X 功能」（代表他真的在用）

沒這些訊號、不要急著加功能 / 投廣告、繼續驗證假設。

MVP 之後 ─ 3 條路

路 1：有 10+ 付費用戶 → 開始長

這是好結果。下一步：

• 補工程紀律（測試、文件、監控）─ 看「14 個分水嶺」那篇
• 改善定價策略
• 找 1-2 個成長 channel 認真投資
• 考慮要不要找 co-founder / 第一個員工

路 2：有人在用但沒人付 → 調整定位

常見原因：

• 解決的痛點不夠痛（nice-to-have）
• 定位的客群錯（找錯人）
• 定價太高 / 太低

解法 ─ 訪談「有用但沒付」的人、找出原因、調整。不要急著重寫產品。

路 3：根本沒人用 → 誠實砍掉

這也是好結果 ─ 用 6 週驗證一個錯誤的假設、比花 12 個月發現好多了。

砍掉重來、學到的東西會讓你下一個 MVP 更快上線。

失敗的 MVP 不是「白做」、是「付學費」。

最後一個提醒

MVP 的核心不是「做得快」、是「誠實面對真實」。
真實是 ─ 多數想法不會成功。
MVP 是讓你用 6 週發現失敗、而不是 12 個月。

6 週很快。1 年很慢。
1 年 = 8 個 MVP 的試驗機會。

這是 indie hacker 跟一般工程師最大的差別 ─ 能不能把「想法→驗證」的循環縮到 6 週以內。

這個能力一旦練起來、就是一輩子的 unfair advantage。