假設驗證板 Hypothesis Board

什麼時候該用它？

每個產品決策背後都是一堆假設。問題是，大部分團隊從來不把假設攤開來看，更不會去驗證它們。Hypothesis Board 是一面牆（或一塊 Notion / Miro 看板），強迫你把所有假設寫出來、排優先順序、設計實驗、追蹤結果。

• 新功能要不要做：老闆說「使用者一定想要這個」— 真的嗎？先寫成假設再說
• 產品方向大爭論：PM 說往左、設計師說往右，先把雙方的假設都攤出來，用數據分勝負
• Sprint Planning 前：下個 sprint 要做什麼？先看看哪些假設風險最高、驗證成本最低，優先做那些
• 上線後數據不如預期：功能上了但數據沒動，回頭看看當初的假設哪個錯了
• 向利害關係人溝通：用假設驗證板說明「我們為什麼做這個決定」，比「PM 的直覺」有說服力一百倍

框架結構

假設驗證板本質上是一個看板（Kanban），每張卡片就是一個假設，卡片在不同欄位之間流動。

假設卡片的結構

每張卡片至少包含：

• 假設陳述：用「我們相信 [做了 X]，會導致 [Y 結果]，因為 [Z 原因]」的格式
• 風險等級：高 / 中 / 低 — 如果這個假設是錯的，對產品影響多大？
• 驗證方法：用什麼實驗來測試？A/B test？用戶訪談？Wizard of Oz？
• 成功指標：什麼數據出現就算「驗證通過」？要具體到數字
• 期限：什麼時候要有結果？

看板欄位

典型的假設驗證板有五個欄位：

1. Backlog（待驗證）：所有新提出的假設先進這裡
2. Prioritized（已排序）：經過風險 × 成本評估後，決定先驗證哪些
3. Testing（驗證中）：目前正在跑實驗的假設
4. Validated（已驗證）：實驗結果支持假設，可以放心往下做
5. Invalidated（已推翻）：實驗結果不支持假設，需要調整方向

優先排序矩陣

用兩個維度排序：

• 風險程度：如果假設錯了，後果有多嚴重？（影響核心價值 > 影響便利性 > 影響美觀）
• 驗證成本：測試這個假設要花多少時間和資源？（用戶訪談 < 假門測試 < A/B test < 完整 MVP）

優先驗證：高風險 + 低成本 的假設。

來源與歷史

• 2008：Steve Blank 在《四步創業法》中強調「假設導向開發」，主張創業的每一步都是在驗證假設
• 2011：Eric Ries《精益創業》出版，把 Build-Measure-Learn 迴圈推廣到全世界，假設驗證成為核心實踐
• 2012：Ash Maurya 在《Running Lean》中提出 Lean Canvas，將假設可視化變成操作工具
• 2014：Jeff Gothelf 和 Josh Seiden 在《Lean UX》第二版中系統化了 Hypothesis Board 的看板格式，成為敏捷團隊的標準配備
• 至今：假設驗證板被整合進 Notion、Miro、Productboard 等工具，從創業圈擴散到企業產品團隊

真實案例：Booking.com 每年跑 25,000 個實驗的秘密

Booking.com 是全球最瘋狂的假設驗證機器。他們每年跑超過 25,000 個 A/B test，平均每天 68 個實驗同時進行。

他們的做法：

1. 所有人都能提假設：不只 PM，客服、業務、工程師都能提。每個假設都用標準格式寫在看板上
2. 嚴格的成功標準：上線前就定好「轉換率提升 2% 就算成功」，不允許事後改標準
3. 快速失敗：一個實驗最多跑 2 週，數據不顯著就直接標記 Invalidated，不戀棧
4. 失敗是常態：他們公開表示，只有 10% 的實驗是成功的。但那 10% 的累積效果驚人

數據成果：這套假設驗證文化讓 Booking.com 的轉換率在 10 年內提升了超過 25%（累積效果），每 1% 的轉換率提升約等於 數億美元的年營收增長。

關鍵啟示：不是他們比別人聰明，是他們比別人更快知道自己哪裡錯了。

使用步驟

Step 1：盤點所有假設

找團隊做一場 30 分鐘的工作坊。每個人把「目前產品策略中隱含的假設」寫在便利貼上。通常一個功能背後有 5-10 個假設，大部分人從來沒意識到。

Step 2：結構化假設陳述

把每張便利貼改寫成標準格式：「我們相信 [做了 X]，會導致 [Y 結果]，因為 [Z 原因]」。寫不出來的假設通常代表「其實你自己也不知道為什麼要做」。

Step 3：風險排序

每個假設評估兩個分數（1-5）：「錯了多痛」和「驗證多貴」。先處理「很痛但驗證便宜」的那些。

Step 4：設計最小實驗

為排在前 3 的假設設計最小成本的驗證方式。能用訪談解決的不做 A/B test，能用假門測試的不做完整 MVP。

Step 5：追蹤與更新

每週團隊花 15 分鐘看一次看板：哪些假設在測、結果如何、下一步怎麼做。看板要活的，不是做完就放著。

這樣做 vs 避免這些

這樣做

• 把「我覺得」改成「我們相信…因為…」— 光是語言的轉換就能改變團隊的思維方式
• 讓成功指標在實驗前就定好，不要事後用數據找解釋
• 慶祝「推翻假設」— 快速發現錯誤跟快速做對一樣有價值
• 保留所有 Invalidated 的卡片 — 這是團隊的學習資產，未來新人可以看到「為什麼當初沒做 X」

避免這些

• 假設寫太模糊 — 「使用者會喜歡新設計」不是假設，「新結帳流程會讓完成率提升 15%」才是
• 只放高風險假設 — 低風險假設也要記錄，否則會有知識斷層
• 跳過實驗直接標記 Validated — 「開會討論覺得應該對」不算驗證
• 看板更新頻率太低 — 超過兩週沒更新的看板就是裝飾品