精益畫布 Lean Canvas

什麼時候該用它？

當你有一個產品想法，但還沒辦法跟別人在 5 分鐘內講清楚「你要做什麼、為誰做、怎麼賺錢」的時候。Lean Canvas 強迫你把思考收斂到一張紙上。

• 新產品提案：跟老闆或投資人 pitch 前，先用一頁紙整理思路
• 驗證商業模式：有了 MVP 但不確定商業模式是否成立
• Pivot 決策：需要快速比較多個方向的可行性
• 團隊對齊：讓所有人對「我們在做什麼生意」有一致的理解

框架結構

Lean Canvas 是 Ash Maurya 基於 Alexander Osterwalder 的商業模式畫布（BMC）改造的版本，更適合早期創業。9 個格子：

左半邊（產品面）

1. 問題（Problem）：使用者面臨的前 3 大痛點
2. 解決方案（Solution）：對應每個問題��核心功能
3. 關鍵指標（Key Metrics）：衡量成功的 3-5 個數字
4. 成本結構（Cost Structure）：固定成本 + 變動成本

右半邊（市場面）

5. 獨特價值主張（UVP）：一句話說明你為什麼與眾不同
6. 不公平優勢（Unfair Advantage）：競爭對手無法輕易複製的東西
7. 通路（Channels）：如何觸及目標使用者
8. 目標客群（Customer Segments）：你的早期採用者是誰
9. 收入來源（Revenue Streams）：怎麼賺錢

填寫順序

Ash Maurya 建議的順序：目標客群 → 問題 → UVP → 解決方案 → 通路 → 收入 → 成本 → 關鍵指標 → 不公平優勢。先搞清楚「為誰解決什麼問題」，最後才想「怎麼賺錢」。

來源與歷史

• 2008：Alexander Osterwalder 出版《Business Model Generation》，發表商業模式畫布（BMC）
• 2010：Ash Maurya 認為 BMC 太偏向大企業，缺少「問題驗證」的精神，開始改造
• 2012：出版《Running Lean》，正式發表 Lean Canvas，成為精益創業的標配工具
• 至今：幾乎所有加速器（Y Combinator、Techstars、AppWorks）都要求申請者提交 Lean Canvas

真實案例���Buffer 的一頁驗證

社群排程工具 Buffer 的創辦人 Joel Gascoigne 在 2010 年用了極簡版的 Lean Canvas 驗證想法：

1. 問題：社群經理需要在最佳時間發文，但不可能 24 小時盯著手機
2. 解決方案：排程發文工具
3. UVP：「用最簡單的方式排程你的社群貼文」
4. 驗證方式：做了一個只有兩頁的假網站 — 第一頁說明功能，第二頁是定價頁（還沒做產品）。點了「購買」的人會看到「還在開發中，留下 Email」

數據：三天內收到 120 個 Email，確認了「有人願意付費」。然後才開始寫程式碼。

這正是 Lean Canvas 的精神：先驗證問題和付費意願，再寫 code。

使用步驟

Step 1：20 分鐘寫出初版

計時 20 分鐘，強迫自己快速填完 9 個格子。第一版一定很粗糙，這是正常的。重點是把想法從腦子裡掏出來。

Step 2：聚焦「問題」和「客群」

這兩個格子決定了整張畫布的品質。問自己：「如果我把這兩格拿給 10 個目標使用者看，他們會點頭嗎？」

Step 3：寫出可被推翻的假設

把每個格子裡的內容轉化為假設。例如：「我假設社群經理每天花 30 分鐘在手動發文」→ 這可以被驗證或推翻。

Step 4：排序風險

哪些假設一旦錯誤，整個商業模式就崩盤？優先驗證這些。通常是「問題是否存在」和「使用者是否願意付費」。

Step 5：每週更新

Lean Canvas 是活的文件。每做一次使用者訪談、每跑一次實驗，就回來更新。持續迭代直到每個格子都有數據支撐。

這樣做 vs 避免這些

這樣做

• 一個 Canvas 對應一個客群 — 如果你有兩種使用者，畫兩張
• 把 UVP 寫成一句話 — 如果需要一段話才能解釋，那就不夠清楚
• 跟至少 5 個目標使用者驗證「問題」格 — 你以為的痛點可能只是你的幻想
• 列出「不公平優勢」時要誠實 — 如果你真的沒有，就寫「目前沒有」

避免這些

• 不要花超過 30 分鐘在第一版 — 過度雕琢的 Canvas 跟沒寫一樣
• 不要把所有功能都塞進「解決方案」— 只寫最核心的 1-3 個
• 不要把「熱情」或「努力」當不公平優勢 — 這不是競爭對手無法複製的
• 不要寫完就丟進抽屜 — 沒有持續更新的 Canvas 等於過期的地圖