> ## Content Index
> Fetch the complete content index at: https://www.davehuang.io/llms.txt
> Use this file to discover other available public pages before exploring further.

# 獨立創業策略（下）：開發循環
- URL: https://www.davehuang.io/solopreneur-3/
- Published: 2025-10-12T15:45:31.000Z
- Updated: 2025-10-20T15:07:58.000Z
- Author: Dave H
- Tags: Indie Hacking

承接上一篇 [獨立創業策略（中）：痛點驗證](https://www.davehuang.io/du-li-chuang-ye-ce-lue-zhu-tong-dian-yan-zheng-kai-fa-xun-huan/)，當你透過決策樹驗證出一個「有效痛點」後，接下來該怎麼做?

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

## Lean Startup 開發循環模型

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

> Build → Measure → Learn

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

![](https://www.davehuang.io/content/images/2025/10/image-7.png)

Source: [https://medium.com/@dominic\_11011/build-measure-learn-cycle-ace388a13b4d](https://medium.com/@dominic%5F11011/build-measure-learn-cycle-ace388a13b4d?ref=davehuang.io)

這個循環的核心理念是：最小化每次循環的時間，加速學習速度。理想情況下，你應該能在數週內完成一個完整循環，透過快速迭代找到 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](https://peakpals.io/?ref=davehuang.io) 經驗。

當我開始打造 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 工作」的情況下。如果工作進入高壓週期，或是需要常常進辦公室開會、處理突發事件，這個時間會拉得更長。

### 殘酷的對比

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

| 項目         | 新創團隊         | 獨立開發者 (我)  |
| ---------- | ------------ | ---------- |
| **循環時間**   | 2-6 週        | 12 週（3 個月） |
| **人力**     | 5-10 人全職     | 1 人兼職      |
| **每週投入時間** | 200-400 小時   | 15-20 小時   |
| **基礎建設**   | 完整（追蹤、部署、監控） | 從零開始       |
| **用戶基礎**   | 已有數千到數萬用戶    | 從 0 開始     |
| **數據可靠性**  | 高（統計顯著）      | 低（樣本太小）    |
| **決策速度**   | 快（團隊協作）      | 慢（一人思考）    |

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

更殘酷的是：

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

### 核心矛盾

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

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

或者更直接地問：

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

## Lean Startup 模型的反對觀點

就在我反思自己的開發循環時，我讀到了 Daniel Kyne 的這篇文章：[《The Lean Startup is a terrible book for founders》](https://fullstackresearcher.substack.com/p/the-lean-startup-is-a-terrible-book?s=w)。

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

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

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

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

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

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

但如果你問（參考《[The Mom Test](https://pagerank.ing/product-managers-must-read-the-mom-test/?ref=davehuang.io)》）：

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

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

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

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

但建造程式碼是成本最高的驗證方式。即使是在 AI 盛行的現在，你可以看見那些 vibe-code 出來的「產品」往往只能當作 social media 上面吸引眼球販賣焦慮的文案，實際能夠解決 [有效痛點](https://www.davehuang.io/du-li-chuang-ye-ce-lue-zhu-tong-dian-yan-zheng-kai-fa-xun-huan/) 的產品並沒辦法如此無腦的「純 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》](https://longform.asmartbear.com/icp-ideal-customer-persona/?ref=davehuang.io))

**我會這樣構思 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，我學到：**獨立開發不是「平衡」，而是「刻意取捨」**。

![](https://www.davehuang.io/content/images/2025/10/image-8.png)

在 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》](https://longform.asmartbear.com/conflicting-choices/?ref=davehuang.io)

---

## 本週紀錄

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

### 回老家

原本在台北的期間被工作的瑣事搞到很心煩，也因此稍微有點失去了自己生命進程的專注力，開始找一些 coping 去做 (參見這篇的 [避開 Coping 陷阱](https://www.davehuang.io/ren-sheng-you-le-chang-xia-jie-jue-tong-ku/))。

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

![](https://www.davehuang.io/content/images/2025/10/image-5.png)

嘗試一家新的雞肉飯

### Peak Pals 進程

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

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

![](https://www.davehuang.io/content/images/2025/10/image-3.png)

Peak Pals 的個人檔案

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

原本還想要加入 [Buy me a coffee](https://buymeacoffee.com/?ref=davehuang.io) widget，沒想到 Stripe 跟 PayPal 的收款規定這麼嚴，看來是該撥點時間跟錢來弄一個美國的 LLC，有了收款功能我覺得會讓整體更有「成品」的感覺。

### 專注力協定

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

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

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

![](https://www.davehuang.io/content/images/2025/10/image-4.png)

等有夠久的 Seeker

### 很開心的事

上一篇引用的方法驗證循環的[作者](https://longform.asmartbear.com/jason-cohen/?ref=davehuang.io)，竟然 follow 了我的 [Threads](https://www.threads.com/@95sailor%5F?ref=davehuang.io)，我欣喜若狂!

![](https://www.davehuang.io/content/images/2025/10/image-6.png)