當我們談到打造成功的產品時，很多人會直接聯想到「快速交付」「使用者回饋」或「敏捷開發」，但往往忽略了一件最根本的事：我們真的理解我們在解決的問題嗎？
這正是 Product Discovery（產品探索）這個階段存在的意義。它是產品開發中最容易被低估、但卻影響最深遠的一個階段。而 Specification by Example（SBE）中的「實例化需求」技巧，正好可以在這個階段發揮關鍵影響力。
Product Discovery 的目標，是幫助產品團隊在投入開發資源之前，先釐清以下幾個問題：
• 使用者真的有這個需求嗎？
• 我們理解的「需求」跟使用者的「行為」是否一致？
• 哪些功能真的創造價值？哪些只是我們自己的想像？
• 我們有哪些關鍵假設還沒驗證？
• 如果只能先做一小部分（MVP），我們該選哪個？
這個階段不像開發有 Sprint，不像測試有測項清單，它的輸出往往比較「模糊」：假設列表、訪談筆記、用戶旅程地圖等等。這正是問題所在：缺乏具體化與對齊的機制。
這時，Specification by Example 的實例化需求技術，可以補上這個缺口。
實例化需求指的是：與其用抽象語言描述需求，不如用一組具體例子來表達使用者的行為與預期結果。
這些例子可以是：
• 某種使用情境（場景敘述）
• 輸入／行為／系統回應的組合
• Given-When-Then 的行為描述
• Decision table（決策表）
• 失敗與例外案例
透過這些具體例子，我們可以：
• 快速驗證需求是否清楚
• 找出角色理解落差
• 發現例外與錯誤情境
• 協助切 MVP 的邊界
• 作為未來驗收條件的基礎
這讓需求討論不再只是 PM 自說自話的 PowerPoint，也不是工程師一邊寫 code 一邊猜測使用情境，而是讓大家圍繞著一個具體行為場景，共同釐清需求的本質與價值。
讓我們以一個常見產品功能為例：高鐵訂票 App 的早鳥票機制，來說明如何在各個探索階段使用實例化需求。
(1) 問題定義階段：用例子釐清「到底哪裡是問題？」
假設用戶抱怨「早鳥票不好搶」，這是個模糊的抱怨。我們該怎麼處理？
與其問「要不要改進早鳥機制？」，不如列出幾個具體例子來描述使用者遇到的情境，例如：
這時我們就能討論出具體邊界，例如：
• 是不是「搭車日減 28 天」才能看到早鳥票？
• 訂票邏輯是否一致？
• 如果訂票日選錯，使用者會看到什麼錯誤訊息？
這樣的例子比「用戶覺得不好搶」具體得多，也讓問題定義變得可以討論與驗證。
(2) 需求釐清階段：建立跨角色的共識基礎
當我們進入 Product Discovery 的中段，開始聚焦在特定功能或使用者任務時，需求會變得「有一點輪廓、但還說不清楚」。這時各角色心中都有想像，但想像彼此不一樣，於是團隊會出現這種對話：
• PM 說：「我們想讓用戶能在 28 天前訂早鳥票。」
• UX 說：「那畫面上怎麼顯示？是自動標記嗎？」
• RD 說：「這個早鳥票是根據什麼欄位？我們的 API 沒那個欄位喔。」
• QA 說：「那萬一沒有早鳥票的時候，會顯示錯誤訊息還是 fallback？」
這種「大家講的都沒錯，但又沒共識」的狀況，就是需求釐清中最常見的混沌地帶。這時，如果團隊能運用 Example Mapping 技術，把抽象的故事轉化為具體例子、行為規則與可視化地圖，就能快速建立共識，也能提早發現問題。
這時我們可以把剛剛的例子搬上桌，進行所謂的 Example Mapping（範例映射）：
第一步：挑一則使用者故事（User Story）
例如：
作為一個乘客，當我在高鐵 App 上查詢票價時，我希望能看到是否有早鳥票，這樣我可以提早訂票省錢。
這一張「藍色便利貼」會放在地圖的最上方，代表本次討論的核心主題。
第二步：列出業務規則（Rules）
團隊針對這個故事，提出你認為應該遵守的行為規則。例如：
第三步：針對每條規則舉出例子（Examples）
這是整個過程最具價值的部分。你不只是列出規則，而是說：「來，我們用幾個具體的例子來看這條規則會不會卡住。」
例如對規則 #1，我們可以列出：
這些範例可以是表格，也可以寫成 Given–When–Then 句式。每個例子都貼在對應的規則下方，這樣團隊就能針對例子來挑戰規則的合理性。
第四步：記下還沒釐清的問題（Questions）
在範例討論過程中，團隊往往會冒出一些「欸這個怎麼處理？」的疑問。例如：
• 跨時區怎麼計算日期？
• 多人訂票時只有部分人可享早鳥，要怎麼顯示？
• 若用戶選擇了不可訂票的日期，是提示還是自動調整？
這些都會被記成「紅色便利貼」，貼在對應規則下，表示這些點要追問、調查、確認。不是現在馬上要解決，但必須進入追蹤清單。
透過這種範例，大家能討論得更深、更具體、更有共同語言。
(3) 假設驗證與 MVP 切割階段：哪些情境值得支援？
當你在產品探索中，常常會遇到這種對話：
• 「要不要支援跨月訂票？」
• 「萬一沒早鳥票了，我們要顯示什麼？」
• 「用戶會不會因為找不到早鳥票就放棄訂票？」
這些問題聽起來好像都值得處理，但資源有限，到底要先做哪個？晚點做哪個？哪些根本不重要？ 這正是「假設驗證與 MVP 切割」的場景。
第一步：先寫出「可能要處理的情境」
這其實就是 SBE 的基本動作 —— 寫出範例（Example），把需求講清楚。
我們舉高鐵訂票 App 的「早鳥票」功能為例，先列出幾個情境：
最後這個例子，是個模糊情境，你的團隊會問：「這要先支援嗎？」
第二步：針對模糊情境，討論這是不是一個「假設」
比如你說：「我猜用戶會很在意『到底有沒有搶到早鳥票』，所以要給提示。」
這句話是個假設，還不是確定的需求。你可以用白話方式問：
「這是我們知道的嗎？還是我們猜的？」
如果是「猜的」，就先把它標記起來，別急著寫進規格，而是進入「待驗證」。
這就是所謂的「Assumption」，你可以不用卡片，用便利貼寫也行。
第三步：回頭問範例 → 「我們要不要支援這個？」
這時，SBE 的例子就幫上忙了。
假設我們針對「早鳥額滿」列了這個例子：
Given 訂票日是 9/01，
When 查詢 9/30 車次，
And 該班車早鳥已額滿，
Then 顯示「早鳥票已售完，僅剩普通票」
你可以問團隊三個問題來做決定：
這三個問題的答案，就是你在切 MVP（最小可行產品）時的依據。
最後用表格整理：哪些要做？哪些先不做？
這些都是從範例出發來判斷的，不是憑感覺，也不是「老闆說的」。
(4) 技術可行性與設計風險探勘：例子能揭露潛在風險
在許多產品開發中，問題不是不會做，而是做下去才發現「原來這麼麻煩！」。尤其是那些「看起來只是顯示資料」「只是個欄位切換」的需求，往往隱藏著複雜的商業邏輯、資料同步難題、系統邊界問題或設計衝突。
這就是 SBE 發揮價值的地方。透過實例化需求，我們在還沒寫一行程式之前，就能提早看出這些風險。
假設我們要新增一個需求：顯示早鳥票額滿的提示與回退機制（fallback to 普通票）
從 PO 的角度聽起來可能像這樣：
「如果早鳥票已經沒了，就顯示『已售完』，然後顯示原價，這樣用戶比較不會誤會。」
聽起來沒問題對吧？但我們用 SBE 的方法，把它轉成範例來討論，你就會發現裡面潛藏的風險與挑戰。
範例 1：正常查詢 → 顯示早鳥票
Given 訂票日是 9/01，
And 搭乘日為 9/30（距離 28 天以上），
And 該班車尚有早鳥票，
When 使用者查詢車次時，
Then 顯示「早鳥票 NT$820（原價 NT$980）」
範例 2：查詢已額滿 → 顯示普通票與提示
Given 訂票日是 9/01，
And 搭乘日為 9/30（符合早鳥時段），
And 該班車早鳥票已售完，
When 使用者查詢車次時，
Then 顯示「早鳥票已售完，僅剩普通票 NT$980」
從這些範例中可能發現的風險有哪些？
為什麼這些問題要「用範例才會發現」？
如果你只是寫需求文字：「早鳥額滿時，顯示普通票」── 大家通常都會點頭說 OK。
但你一旦寫出具體範例，尤其是稍微「挑戰邊界」的例子，比如：
Given 使用者訂購 2 張票，
And 早鳥票僅剩 1 張，
Then 顯示什麼？拒絕？部分折扣？還是轉為普通票？
這樣的例子就會讓大家立刻停下來說：「欸……這好像有點複雜。」這樣問題就提前被發現，而不是等開發做完、測試卡關、設計被罵時才發現。
如何整理與追蹤這些風險？
你可以把每個例子對應到一張「風險追蹤卡」或欄位：
這樣你就能從「範例驅動」的方式，一路追蹤到「技術風險處理」，而不是靠經驗或臨時反應。
在 Product Discovery 階段，需求尚未成形、共識尚未建立，抽象的詞語往往令人誤解。這時候，實例化需求是一把能切開模糊與混亂的利刃。
透過範例，我們能：
• 看見問題真貌
• 對齊跨角色情境理解
• 篩選出真正有價值的 MVP 功能
• 預先發現風險與漏洞
這讓需求不再只是「寫在文件裡」，而是變成能被討論、被驗證、被優化的行為故事。當你希望開發出真正有價值的產品，實例化需求，是你不可或缺的思維與工具。
iThome鐵人賽
看影片追技術