同樣的問題，不同專業背景的人會看見不同的解決方案——這就是「專業化的詛咒（curse of specialization）」。LEAN sprint 是把整個團隊對齊到同一個約束、並系統化產生與測試多元構想的工具。

創新者偏誤的另一面#

在前一章 Lean Canvas 案例中，面對「啟動率太低」這個同一問題：

  • 工程師想加更多功能。
  • 設計師想改善易用性。
  • 行銷想優化登陸頁、買廣告。

「提出新問題、看見新可能、從新角度看舊問題，需要創造性的想像。」——Albert Einstein

每個人帶著自己的專業偏誤看問題並非錯——錯的是限縮了點子的多樣性。要達成突破，你需要不斷接入更大的點子來源。

好點子可以來自任何地方。問題在好點子稀少，且早期跟壞點子難以分辨。所以你需要一套既能廣泛蒐集點子又能快速分辨好壞的流程。

這個流程，就是 LEAN sprint。

LEAN Sprint 是什麼？#

創業者真正的工作：透過一系列對話，有系統地降低商業模式的風險。

LEAN sprint 是一個時間箱化的迭代週期，用來蒐集、排序、測試「打破約束、提升客戶吞吐量」的新點子——把 GO LEAN 框架落地到團隊。

時間箱長度依產品階段與團隊規模而定，建議從兩週開始。一個典型的兩週衝刺包含：

  • 衝刺前會議（presprint）：對齊約束。
  • 衝刺規劃會議（sprint planning）：選定要測試的提案與實驗。
  • 每日站立會議（daily stand-up）：協調任務。
  • 衝刺評審會議（sprint review）：分享結果、決定下一步。

LEAN sprint 全景：① Sprint Kickoff → ② 兩週 LEAN（多條 Build/Measure/Learn 並行 + 每日站立）→ ③ Sprint Review → 重複——失敗的點子（紅 ✗）淘汰，得勝的點子下一輪繼續

多開會聽起來令人疲倦——但會議經營得好，是專注對話的時間箱，是這套方法的核心。

為什麼大多數會議無效#

  1. 沒有議程：流向隨機，不一定有產出。LEAN sprint 的會議都有「後設腳本（metascript）」要達成的學習目標。
  2. 參與度不足：1–2 個人講、其他人聽。LEAN sprint 會議要求所有人動手。
  3. 缺乏原創思考：HiPPO（Highest-Paid Person’s Opinion）與同儕壓力導致集體迷思。LEAN sprint 採用 IDEO 的「對齊—發散—收斂（align-diverge-converge）」模式：會議只用來對齊與決策，不做自由發散討論。

Diverge / Converge 一個循環：理解問題 → Diverge（Create Choices）→ Converge（Make Choices）→ 定義解法

LEAN Sprint vs Scrum / Design Sprint#

vs Scrum / Agile#

  • 目標不同：Scrum 衡量「建造速度」；LEAN sprint 衡量「牽引力速度」——光是建出功能或學到東西不夠，必須證明它影響了某個牽引力槓桿。
  • 參與者不同：Scrum 多半是工程主導；LEAN sprint 需要完整跨職能團隊，包含內外部利害關係人。
  • 時間箱不決定發布節奏：可繼續以 kanban 持續交付。時間箱只用來強迫做出決策。

vs Design Sprint#

  • Design sprint 通常是 5 天衝鋒型，以解決某個設計問題並交給實作團隊。
  • LEAN sprint 是長期、一波接一波的問題探索；目標是建立長期的產品團隊，不是短期 SWAT 小隊。

LEAN Sprint 的五個階段#

五個階段以重疊的「對齊—發散—收斂」週期推進：

  1. 暴露問題（Expose Problems）：衝刺前會議對齊「目前的約束是什麼？」
  2. 定義解法（Define Solutions）：團隊各自離開、用驗證計畫產出解法。
  3. 短名單（Short-list Solutions）：在衝刺規劃會議中分享、排序、入選最佳策略。
  4. 測試解法（Test Solutions）：執行實驗。
  5. 決定解法（Decide on Solutions）：衝刺評審會議檢視結果、決定下一步。

GO LEAN 完整流程：5 個 Diverge/Converge 漏斗串成一條線——從暴露問題到決定解法，正好對應 G-O-L-E-A-N 各步

1. 暴露問題#

第 1 階段聚焦：Expose Problems——「組團隊 + 召開衝刺前會議」

組成正確的團隊#

LEAN sprint 團隊要為速度、學習、聚焦最大化：

速度 / 學習 / 聚焦的三圓 Venn 圖：最佳團隊位於三圓交集；落入兩圓而漏掉第三圓的區塊各有名稱——過早最佳化、追自己的尾巴、燒光資源

小團隊#

「團隊效率大約與成員數的平方成反比。」——Marc Hedlund

「兩個披薩團隊」原則（Jeff Bezos）：團隊大小應該小到能用兩個披薩餵飽。

不要為一個產品養一個大團隊；考慮分成多個小團隊。

多元背景（multidisciplinary）#

完整團隊應包含建構（developers）、設計（designers）、行銷（marketers）三個職能；再加一位 LEAN Sprint Master 負責主持流程。

利害關係人也是團隊的一部分——新創的顧問或投資人；企業內的主題專家或主管贊助者。即便是 bootstrapper 也建議組一個臨時顧問板。

如果工作要靠跨團隊資源完成，吞吐量會受影響——當交付物在各自的部門 KPI 驅動下產出時，會掉入局部最佳化陷阱。

半自治（semiautonomous）#

兩個極端都不對：

  • 沒有授權：什麼都得請示，速度直接報銷。
  • 完全自治：傳統 skunk works／R&D，預算燒光卻產不出與本業相容的成果。

太空探測比喻：把企業內創新想像成發射探測器。射太遠會迷失、回不來；即使回來，帶回的東西也太陌生而被本部門斃掉。正確做法是繞著一個明確（雖然模糊）的目標公轉，並與本星球上的高層贊助者保持規律通訊。

——改編自 Manish Mehta 的對話（Dell 早期內創業者）

平衡點：外部問責系統讓團隊有探索自由，同時被某些核心商業模式約束與目標錨住。

衝刺前會議（Presprint Meeting）#

第一次跑時建議召開；之後通常不需要——學習動能會自動沿用到下次衝刺。

參與者：核心團隊（必要）、利害關係人（選擇性）。時長：45 分鐘。

衝刺前會議議程（45 分鐘）：歡迎 → 分享商業模式故事 → 基準進展 → 辨識約束 → 一般討論 → 設定預期 → 收尾

議程#

  • 歡迎與設立場景（3 分鐘）：說明動機、走議程。

  • 分享商業模式故事（精實畫布）（5 分鐘）：以畫布為視覺輔助，講背後的故事——你怎麼遇上這位客戶或這個問題？專案運作多久？目前做到哪？

    精實畫布：填寫順序 1.客戶區隔 → 2.問題 → 3.UVP → 4.方案 → 5.通路（不繪）→ 6.營收流 → 7.成本結構 → 8.關鍵指標 → 9.不公平優勢

  • 基準進展（牽引力模型）（5 分鐘）：從最小成功門檻出發，描繪期望的牽引力模型，標出當下吞吐量在哪——確認產品階段（問題/方案契合、產品/市場契合、規模化）。

    基準進展示例：「我們在這裡」——128 客戶——還在從問題/方案契合（30 trials/月）走向產品/市場契合（400 客戶）的路上

  • 辨識約束（客戶工廠）（5 分鐘）：用客戶工廠儀表板畫粉筆圈標出熱點，不追根因。

    第 90 週客戶工廠：1,232 訪客 → 312 sign-ups（25%）→ 243 啟動（78%）→ 30 天留存 202（83%）→ 10 客戶/週（5%，紅圈）；目標是 15 客戶/週——粉筆圈直接畫在最後一段

  • 討論 Q&A（15 分鐘）：避免一頭栽進設計解法——下一階段才是。

  • 設定預期（推進性問題）（5 分鐘）：給團隊大目標 + 緊約束。例：「不增加新功能的前提下，怎麼提升付費轉換率？」

  • 收尾（2 分鐘）：宣告推進性問題，散會。

2. 定義解法#

第 2 階段聚焦：Define Solutions——「把點子捕捉到驗證計畫（Learn / Leverage / Lift）」

團隊離開會議室，個別做進一步分析（避免集體迷思、保留多樣性）。每個人套用聚焦三步驟（Learn、Leverage、Lift），把提案捕捉到一頁的驗證計畫上。

3. 短名單#

第 3 階段聚焦：Short-list Solutions——「召開衝刺規劃會議」

如果上一階段做得好，提案數量大概會超過你能在這個衝刺裡測試的容量。需要在衝刺規劃會議中排序、入選。

衝刺規劃會議（Sprint Planning Meeting）#

目的：審查、排序、入選驗證計畫；定義本衝刺的實驗。 參與者：核心團隊（必要）、利害關係人（建議）。 時長：每週 1 小時——兩週衝刺 → 2 小時規劃會議。

衝刺規劃會議議程（120 分鐘）：歡迎 → 點貼排序 → 審查驗證計畫 → 超級點貼短名單 → 審查實驗 → 設定預期 → 收尾

議程#

歡迎與設立場景（3 分鐘）#
排序驗證計畫（點貼投票）（5 分鐘）#

建立衝刺速度（sprint velocity）之前，目標提案數 = 團隊規模 / 2。例：5 人團隊 → 最多 3 個驗證計畫。

這就是「在製品（WIP, work-in-progress）限額」——精實思維中減少「快做完但沒做完」浪費的核心做法。

點貼投票（dot voting）：

  • 把驗證計畫匿名公開（貼在牆上、印發、投影）。
  • 每人拿一張點貼紙投給最喜歡的提案，可在同一份貼多張表示強烈偏好。
  • 排序由高到低，取前 WIP × 2 個進入下一輪審查（5 人團隊 → 入選前 6 個）。
  • 匿名與沉默投票避免被作者口才干擾——最好的點子應該自己會發光。

排序的兩個軸：

  • 驗證計畫的潛在收益（potential upside）。
  • 分析的深度（depth of analysis）。

直覺有它的位置，但有實證背書（資料、質性、可參考的類比）的提案應優先。

排序矩陣：x 軸「實證分析的深度」、y 軸「點子的潛在收益」——優先選右上角（高收益、低不確定性）

技術可行性與實作量級不應是初期排序重點——任何大策略都能拆成小、快、可疊加實驗。

審查驗證計畫（每件提案 5 分鐘 pitch + 5 分鐘 Q&A）#

提案者揭名後，5 分鐘描述計畫（搭配輔助物件：訪談摘要、線框圖、類比方案的截圖、收斂的子精實畫布）。再 5 分鐘 Q&A。

短名單（超級點貼投票）（5 分鐘）#

每人 1–2 張不同顏色「超級貼」，挑出最頂尖的提案。可給利害關係人額外票數作為加權，承認公司文化的現實。

審查實驗（每件 5 分鐘 + 5 分鐘討論）#

提案者描述：

  • 怎麼測？
  • 多久？
  • 需要哪些資源？

其餘團隊用 5 分鐘討論能不能找到更快的測法。

設定預期（每實驗 5 分鐘 — 估算遊戲）#

每位團隊成員 3 分鐘內獨自寫下對結果的預期（用計時器）。可以共享所有預測或只看分布。目標是訓練判斷力——真正的價值在衝刺評審會議揭曉。

收尾（2 分鐘）#

確認每個人對接下來的任務都清晰。

4. 測試解法#

第 4 階段聚焦：Test Solutions——「以實驗測試策略」

實驗各自跑 Build/Measure/Learn 週期。一個驗證計畫在一個衝刺中可以跑多個實驗，但所有實驗必須在衝刺時間箱內完成。

每日站立會議#

每日站立會議（≤15 分鐘）：昨天 / 今天 / 阻礙——僅同步，不解問題

參與者：核心團隊（必要）、利害關係人（建議）。 頻率：每日一次，通常上午。 時長：不超過 15 分鐘。

每人 3 分鐘內回答：

  • 昨天做了什麼？
  • 今天要做什麼？
  • 有什麼擋路？

這不是「狀態報告會」也不是「問題解決會」——只是同步，問題拉到會後處理。

分散式團隊可用 Slack + stand-up bot 異步進行。

結果分析#

實驗完成後對齊目標。常常需要在衝刺評審會議前再跑學習實驗或分析——留足時間。

5. 決定解法#

第 5 階段聚焦：Decide on Solutions——「召開衝刺評審會議」

衝刺評審會議（Sprint Review Meeting）#

目的：檢視結果、為每個驗證計畫決定下一步。 參與者：核心團隊（必要）、利害關係人（建議）。 時長：60 分鐘。

衝刺評審會議議程（≤60 分鐘）：歡迎 → 分享總體結果（客戶工廠）→ 發表實驗結果 → 決定下一步行動 → 收尾（標出下一個約束）

議程#

  • 歡迎與設立場景（2 分鐘）。
  • 分享總體結果（客戶工廠）（5 分鐘）：用更新後的儀表板判斷原約束是否被打破——若是，慶祝後重新對焦下一個約束。
  • 發表實驗結果（每實驗 5 分鐘 + 5 分鐘 Q&A）：頒發估算遊戲冠軍獎品的好時機。
  • 決定下一步行動（每實驗 10 分鐘）：團隊投票決定四種狀態之一：
    • 退場（Retire）：移到下一個點子。
    • 堅持（Persevere）：保持方向。
    • 轉向（Pivot）：改變方向。
    • 重置（Reset）：放棄這個點子。
  • 收尾（標出下一個約束）（3 分鐘）：宣告新的（或不變的）推進性問題。確認商業模式、牽引力模型、客戶工廠儀表板都已更新。

章節重點回顧#

  • 好點子可以來自任何地方。
  • 要達成突破，需要一套蒐集、排序、測試點子的有效流程。
  • LEAN sprint 是把這件事時間箱化的方式。
  • 兩週是不錯的起始長度。
  • LEAN sprint 需要完整的團隊參與。
  • 五個階段：暴露問題、定義解法、短名單、測試解法、決定解法。
Backward 面對失敗 對自己負責 Forward