承接上一篇 獨立創業策略（中）：痛點驗證，當你透過決策樹驗證出一個「有效痛點」後，接下來該怎麼做?

這篇將探討如何在有限時間與資源下，高效推進產品開發。

Lean Startup 開發循環模型

關於開發循環，最有名的莫過於 Eric Ries 在 2011 年提出的 Lean Startup 方法論。這個方法論的核心是一個三階段循環：

Build → Measure → Learn

• Build：快速建造最小可行產品（MVP），用最少資源驗證核心假設
• Measure：透過數據測量用戶行為，追蹤關鍵指標
• Learn：從數據中學習，決定繼續（Persevere）或轉向（Pivot）

這個循環的核心理念是：最小化每次循環的時間，加速學習速度。理想情況下，你應該能在數週內完成一個完整循環，透過快速迭代找到 Product-Market Fit。

這個方法論賣出超過 100 萬冊，被翻譯成 30 多種語言，成為矽谷創業的「聖經」。但它真的適合所有人嗎？

在軟體新創的經驗

在回答這個問題前，讓我先分享我在新創公司的實際經驗。

我曾在幾間新創公司工作，見證過這個循環如何在「理想條件」下運作：

團隊配置：

• 一個 10-15 人的強大技術團隊（前端、後端、SRE工程師）
• 專職的 Product Manager 與 Designer
• Data Team 負責數據基礎建設與分析
• C-Suite 高層具備深厚的 Product Sense

典型的開發循環：

Week 1-2: Build

• PM 根據市場洞察與用戶反饋，定義下一個實驗方向
• Designer 快速產出高保真原型
• 工程團隊並行開發，前後端同步推進

Week 3: Measure

• Data Team 早已建好完整的追蹤系統（埋點、儀表板、報表）
• 產品上線後，即時監控關鍵指標
• 用戶行為、轉化率、留存率，所有數據一目了然

Week 3-4: Learn

• 每週的產品會議上，團隊檢視數據
• C-Suite 根據數據與市場經驗做決策
• 下一個循環的方向隨即確定

這樣一個完整循環，快則 2 週，慢則 1.5 個月。

而且，這是在「已經有產品與用戶基礎」的情況下。團隊不需要從零開始建立追蹤系統，不需要重新設計整套 UI，不需要從無到有招募用戶。我們是在一個「能夠快速獲利的產品」上進行驗證與優化。

最重要的是，每個人都在全職做這件事。沒有人需要在晚上或週末才能推進專案，沒有人需要在「維持生計」與「推進產品」之間掙扎。

回到獨立開發者的現實

現在，讓我回到我個人的 Side Project 經驗。

當我開始打造 Peak Pals 時，我以為自己可以套用在新創學到的方法。以下是我實際的開發循環：

Week 1-2: 規劃與設計

• 寫下 User Story & Happy Path
• 根據此寫下 Tech Spec 與架構設計
• 開始製作 Figma 設計稿（這時候才發現有一堆 User Flow 的 edge cases）

Week 3-8: Full-stack Development

• 後端+前端開發
• 串接第三方服務與部屬
• Debug、優化、重構

Week 9-10: 測試與迭代

• 自己測試（發現一堆 bug、無止盡的 backlog）
• 找 5 個 test user 試用，收集反饋
• 持續迭代 MVP，修正問題

Week 11-12: 準備上線

• 撰寫產品介紹與文案
• 優化 Landing Page
• 設定基本的分析追蹤
• 思考如何推廣

結果：我花了 3 個月，還停留在「Build」階段的尾聲。

而這是在我有一個「相對能掌控自己時間的全遠端 full-time 工作」的情況下。如果工作進入高壓週期，或是需要常常進辦公室開會、處理突發事件，這個時間會拉得更長。

殘酷的對比

讓我們用數字來對比這兩種情境：

比起新創的情境，我慢了 6 倍。

更殘酷的是：

• 我沒獲利
• 也沒獲取足夠的用戶數據（10 個 test user 的反饋根本談不上「數據」）
• 我還要維持全職工作來支付生活開銷
• 每次工作上的突發狀況都會打斷我的節奏

核心矛盾

這讓我開始反思一個關鍵問題：

獨立開發者在如此有限的時間、資源下，是否真的有辦法把 Lean Startup 的開發循環跑得這麼完備？

或者更直接地問：

Lean Startup 方法論，是否真的適合獨立開發者？

Lean Startup 模型的反對觀點

就在我反思自己的開發循環時，我讀到了 Daniel Kyne 的這篇文章：《The Lean Startup is a terrible book for founders》。

標題很挑釁，但論點卻讓我深思。

這篇文章指出，Lean Startup 建立在4個錯誤假設之上。

錯誤假設一：「客戶不會告訴你他們想要什麼」

Lean Startup 說：客戶不會告訴你他們要什麼，只能透過行為觀察。

但真相是：不是客戶不會說，是你不會問。

如果你問：「你會用這個產品嗎？」你得到的是禮貌性謊言。

但如果你問（參考《The Mom Test》）：

• 「上次遇到這問題，你怎麼處理的？」
• 「你為了解決這問題花了多少時間/金錢？」
• 「你現在用什麼工具？為什麼？」

你會得到真實的痛點、使用情境、付費意願。

錯誤假設二：「最好的驗證方式是直接建造 MVP」

Lean Startup 建議：盡快建造 MVP 收集數據。

但建造程式碼是成本最高的驗證方式。即使是在 AI 盛行的現在，你可以看見那些 vibe-code 出來的「產品」往往只能當作 social media 上面吸引眼球販賣焦慮的文案，實際能夠解決 有效痛點 的產品並沒辦法如此無腦的「純 vibe」。

錯誤假設三：你沒有資源「快速失敗」很多次

Lean Startup 強調「Fail Fast」，但這建立在你有足夠資源承受多次失敗。

獨立開發者每次失敗的代價：

• 時間：3-6 個月（你還要全職工作維生）
• 情緒：每次失敗都消耗熱情，累積 burnout 風險

根據 Indie Hackers 統計：

• 只有 5-10% 獨立開發者達到月入 $1000
• 大部分人在 2-3 個失敗專案後放棄
• 每個專案平均投入 6-12 個月

獨立開發者需要的是「聰明驗證」，而非「快速失敗」。

錯誤假設四：早期階段根本沒有足夠數據

Lean Startup 強調「數據驅動決策」，但早期階段你根本沒有足夠數據。

統計學真相：要得到有意義結論，需要至少 100-200 個樣本。

但獨立開發者現實：前 3 個月可能只有 10-50 個用戶。

更危險的是：量化數據只能告訴你「What」（發生了什麼），無法告訴你「Why」（為什麼）。

要回答 Why，你需要質化研究：用戶訪談、觀察使用、開放式問題。

那它到底適合誰？

適合：

• ✅ 已達 PMF 的產品
• ✅ 有足夠用戶數據的成長期公司
• ✅ 有團隊與資源的團隊

不適合：

• ❌ Pre-PMF 早期階段
• ❌ 有限資源的獨立開發者
• ❌ 需要深度理解的複雜領域

我的下一步

經過前面的反思，我意識到獨立開發者不能照搬 Lean Startup，而是要建立適合自己的開發循環。

以下是我以 Peak Pals 為例，如果從頭開始，我會怎麼做這個 side project?

階段 0：構思 Carol（0-2 週）

在寫任何程式碼前，我會先回答：誰是我的理想客戶？

不是「25-35 歲上班族」這種模糊描述，而是一個具體的人——我稱她為 Carol。(這個概念來自 Jason Cohen：《ICP: Ideal Customer Persona》)

我會這樣構思 Carol：

背景與情境：

• 29 歲，在科技公司做 PM，全職遠端工作
• 每天工作很忙，但想要「有意識地成長」
• 試過 Notion、Habitica、Todoist，但都堅持不到一週

真實痛點：

• 「我不是不知道該做什麼，而是太多工具讓我分心」
• 「設定系統的時間比使用的時間還長」
• 「每次打開 app 都覺得有壓力，因為太複雜」

使用情境：

• 每天早上通勤時（10 分鐘），快速檢視今天要做什麼
• 完成一個目標時，想要「打勾」的成就感
• 不需要複雜報表，只需要「看見自己在進步」

付費意願：

• 願意付 $5-10/月 for 簡單但有效的工具
• 重視的是「減少摩擦」而非「功能多」
• 決策邏輯：「能不能每天輕鬆使用」

如何驗證 Carol？

• 在 Reddit (r/productivity)、Twitter、身邊朋友找 5-10 個「像 Carol 的人」
• 問他們：「你上一個目標追蹤工具為什麼停用？」
• 如果答案一致 → Carol 是真實的
• 如果答案分散 → 重新定義 Carol

為什麼需要 Carol？

未來每個產品決策，我都問自己：

• 「Carol 會用這個功能嗎？」
• 「這個複雜度會讓 Carol 放棄嗎？」
• 「Carol 願意為此付 $X 嗎？」

階段 1：Talk & Design（2-3 週）

有了 Carol，我會用最便宜的方式驗證「她真的需要這個嗎？」

Week 1-2: 深度訪談

找 10 個「像 Carol 的人」，每人 30-45 分鐘訪談。

我會問的問題（The Mom Test 風格）：

• 「你現在用什麼方式追蹤目標？」（了解現狀）
• 「你最近一次放棄使用工具是什麼時候？為什麼？」（真實痛點）
• 「如果有個工具能讓你『每天只花 2 分鐘』就能追蹤目標，你會願意試試嗎？」（價值主張測試）
• 「你願意為這樣的工具付多少錢？」（付費意願）

我要聽到的信號：

• ✅ 至少 7/10 的人提到「現有工具太複雜」
• ✅ 至少 3/10 的人說「如果真的這麼簡單，我願意付費」
• ✅ 沒有人說「我已經有完美的解決方案了」

如果沒聽到這些信號 → 重新思考問題或受眾。

Week 3: Landing Page MVP

在寫任何程式碼前，我會做一個 Landing Page。

內容：

• 一句話價值主張：「2 分鐘追蹤每日目標，不再半途而廢」
• 3 個核心痛點 + 對應解法
• 簡單的 Figma mockup（展示核心流程）
• 郵件收集 + waitlist

成本：

• Framer：$0-19
• 網域：$10/年
• 總時間：1-2 天

驗證標準：

• 至少 30 個郵件收集（來自我主動分享給訪談對象 + 他們的推薦）
• 至少 5 個人主動問「什麼時候能用？」

如果達不到？

• 檢討文案：Carol 真的在乎這個問題嗎？
• 檢討管道：我找的人真的是 Carol 嗎？

階段 2：Build（4-6 週）

到這個階段才開始寫程式碼，但我只做「核心中的核心」。

我會問：Carol 的 Happy Path 是什麼？

核心流程（MVP v1）：

1. 註冊 / 登入（Google OAuth，不做自己的認證系統）
2. 設定 1-3 個每日目標
3. 每天打開 app，點擊「完成」
4. 看到簡單的進度條（7 天、30 天完成率）

就這樣。沒有其他。

我會砍掉的功能（留到 v2）：

• ❌ 社群功能（太複雜，且 Carol 不需要）
• ❌ 數據分析（Carol 不是數據分析師）
• ❌ 客製化主題（nice-to-have，但非必要）
• ❌ 推送通知（v1 先不做，v2 再加）
• ❌ 桌面版（先專注 mobile web）

技術選型原則：

• 選「無聊的技術」（成熟、穩定、AI 熟悉）
• 不追新框架（省學習時間）

開發節奏：

• Week 1-2：核心功能（基本 CRUD）
• Week 3-4：用戶認證 + 基本 UI
• Week 5-6：測試、修 bug、優化體驗

階段 3：Test with Carol（1-2 週）

MVP 完成後，我不會立即公開，而是先給「Carol」們試用。

找 5-10 個「最像 Carol 的人」：

• 就是階段 1 訪談過的人
• 他們已經知道這個產品，有期待感

我會這樣做：

1. 個人化 Onboarding
   • 一對一語音/視訊，看著他們第一次使用
   • 記錄他們的困惑點、猶豫點
   • 不要解釋，只觀察
2. 7 天使用追蹤
   • 每天簡單問：「今天用了嗎？為什麼？」
   • 不要問「喜不喜歡」，而是觀察行為
3. 深度反饋訪談
   • 7 天後，30 分鐘訪談
   • 問：「如果這個產品消失，你會想念嗎？」
   • 問：「你會推薦給誰？為什麼？」

成功信號：

• ✅ 至少 5/10 的人持續使用 7 天
• ✅ 至少 2 個人主動說「我願意付費」
• ✅ 至少 1 個人主動推薦給朋友

如果沒有這些信號：

• 不是「加更多功能」
• 而是回到階段 1：我真的理解 Carol 的痛點嗎？

階段 4：Launch & Iterate（持續進行）

如果階段 3 有好的信號，我會小規模 Launch。

不是 Product Hunt，而是 Carol 聚集的地方：

• Reddit: r/productivity, r/selfimprovement
• Twitter: #productivity 相關討論串
• Discord: 個人成長相關社群

Launch 策略：

• 不是「推銷產品」，而是「分享故事」
• 標題：「我做了一個『2 分鐘追蹤目標』的 app，因為我討厭複雜系統」
• 內容：真實分享我為什麼做、怎麼做、學到什麼
• CTA：「如果你也討厭複雜工具，歡迎試試」

我不會做的事（刻意選擇）

做了三個月 Peak Pals，我學到：獨立開發不是「平衡」，而是「刻意取捨」。

在 Threads 上無意間與 Jason Cohen 的對話，讓我認知到四件重要的概念

1. 不是找到平衡，而是資源配置

我沒辦法同時做好全職工作、每週 20+ 小時 side project、運動、社交、睡眠。

我的選擇：

• 犧牲：部分社交、娛樂
• 保留：運動（抗 burnout）、睡眠（維持專注）、核心關係（情緒支持）
• 優化：全遠端工作、會議能閃則閃、簡化生活（減少熵值）

這不是「標準答案」，而是一個適合我的系統。

2. 這場「遊戲」可以是 Finite 或 Infinite

設定 MVP 開發期與 PMF 信號。開發期結束後，如果沒有 PMF 信號，我會 pivot 或放下。但我不會後悔，因為學習本身就是價值。

這場 infinite game 的本質是我要享受旅程。就包含寫下這篇文章的同時，我也要感到充實與滿足。

3. 解放：我不用「Check all the boxes」

作為獨立開發者，我的優勢不是「什麼都會」，而是：

• 深度理解用戶（因為我就是用戶）
• 快速決策（不需開會，不用滿足投資人期待）
• 靈活調整（沒有包袱）

我可以戰略性地強化這些優勢，而不是焦慮「我不會做超絲滑動畫的 landing page」、「我的API能不能承受的了高併發」、「我不會 viral marketing」。

4.獨立開發 = 時間是終極約束

問：這個產品的時間需求，我 handle 得了嗎？還是它會不斷吃掉我的時間，永遠做不完？

✅ 時間可控的產品（正面例子）：

• Plausible Analytics（網站分析工具）
  • 核心功能自動運作，不需人工介入
  • 用戶問題可用文檔解決 80%
  • 規模化不需線性增加工作量
• ShipFast / LaunchFast（Boilerplate）
  • 製作一次，可賣給多人
  • 提供完整文檔，用戶自助解決問題
  • 偶爾更新即可，不需每日維護

❌ 時間黑洞的產品（反面例子）：

• Marketplace 平台（如 Airbnb-like）
  • 需要同時招募房東與房客（雞生蛋問題）
  • 糾紛處理、客服需求高
  • 規模越大，客服工作越重
• 內容訂閱平台（如 Substack-like）
  • 需要持續產出高品質內容
  • 每週/每月都有交付壓力
  • 停更 = 用戶流失

判斷標準：

• 這個產品能「睡後收入」嗎？（我不工作時，它還能運作嗎？）
• 100 個用戶 vs 1000 個用戶，我的工作量會增加 10 倍嗎？
• 用戶問題能用文檔/自動化解決嗎？還是需要一對一處理？

選擇「時間可控」而非「時間黑洞」的產品。

參考 Jason Cohen 的文章：《Conflicting Choices》

本週紀錄

前幾篇說到，在文章末段也想記錄一下自己這一週的旅程。

回老家

原本在台北的期間被工作的瑣事搞到很心煩，也因此稍微有點失去了自己生命進程的專注力，開始找一些 coping 去做 (參見這篇的 避開 Coping 陷阱)。

回到嘉義後，嘗試慢下腳步，吃著與台北不同──更有溫度的食物，見了許久未見的朋友，與家人相處，並且專注在當下的時光，我覺得我有感到休息。

Peak Pals 進程

打開我的 GitHub commits 審視了一下，發現自己上週其實有著蠻不錯的進度，把上線前幾個核心功能都如期完成了:

• 完成了手機版的全部畫面
• 完成了個人頁面的開發 (可以讓用戶有一個公開的個人檔案互相加好友)
• Notification 功能的完善

接下來可以專心做上線的最後階段準備了。

原本還想要加入 Buy me a coffee widget，沒想到 Stripe 跟 PayPal 的收款規定這麼嚴，看來是該撥點時間跟錢來弄一個美國的 LLC，有了收款功能我覺得會讓整體更有「成品」的感覺。

專注力協定

上週，我收到了等待已久的 Solana Seeker，終於能夠進行我想嘗試很久的專注力協定──一支工作用手機，一支多巴胺機:

• iPhone: 只安裝工作用 App & 生產力工具
• Android: 安裝 Social Media & Games

平常出門都只帶 iPhone，只有睡前可以拿 Android 出來玩。目前嘗試下來釋放出很多大腦的算力，在外面也更能活在當下。但缺點是有相片想要 po 的時候要先上傳到 Google Drive，晚上回家再用 Android 傳到 social。

很開心的事

上一篇引用的方法驗證循環的作者，竟然 follow 了我的 Threads，我欣喜若狂!