原始來源與檔名：2026-07-31T094109+0800-opportunity end-to-end analysis of product opportunities.md

SOURCE | 資訊源評估

這是一篇關於產品探索 (Product Discovery) 方法論的深度文章，作者以 Teresa Torres 的「機會解決方案樹 (Opportunity Solution Tree, OST)」為基礎，犀利地指出了目前產品經理過度依賴 RICE 評分模型的盲點，並提出利用 AI 強制執行 OST 方法論的解法。對於軟體 PM、創業者及 UX 設計師具有極高的實戰指導價值。

NAPKIN | 餐巾紙

在還沒有明確解決方案前（機會階段）就使用 RICE 評分是自欺欺人。正確的做法是：用「使用者旅程的節點」取代「工程分類」來梳理問題；把帶有解法的訪談原話「重構」為真實的用戶需求；最後用 4 個定性維度進行「比較」而非「打分」，並利用 AI 來強制執行這些耗神的梳理紀律。

ROUND 1: SKELETON | 骨架掃描

• 核心問題：為何產品團隊總是產出「披著探索外衣的功能清單」，而無法做出真正的戰略決策？
• 核心答案：因為在「機會探索」階段誤用了為「功能排程」設計的量化模型（如 RICE）。應該改用 OST 樹狀結構，將輸入標準化為「行為結果」與「旅程節點」，並透過定性比較來挑選機會。
• 文章骨架：
  1. 為什麼評分機制在機會階段會失效 (RICE 的盲點)。
  2. Step 1: 校準輸入（Outcome 與 旅程節點）。
  3. Step 2: 建立樹狀結構並將一切重構為「需求 (Need)」。
  4. Step 3: 用「比較」取代「評分」來選定目標。
  5. AI 如何改變這項工作：不在於速度，在於「紀律的強制執行」。

ROUND 2: DISSECTION | 血肉解剖

• 隱形假設：組織允許並願意投入時間進行深入的用戶訪談，且 PM 有權力決定產品走向，而不是只聽命於老闆的 feature list。
• 邊界條件：如果產品處於「已被驗證且急需交付特定功能」的救火期，這套完整的機會探索流程可能會顯得緩不濟急。

ROUND 3: SOUL | 靈魂提取

• 深層洞見：用戶不會想「我遇到了一個可靠性問題」，他們只會想「我開會前查個東西卻載入失敗」。用「工程領域」去分類問題，會讓你繼承公司的官僚視角；用「時間節點 (Discover, Decide, Onboard)」分類，才能看到真實的用戶旅程斷層。
• 行動呼籲：立刻審視你 Roadmap 上的項目，如果不能把它改寫為「試圖改變的用戶行為」，那你做的就只是輸出 (Output)，而不是成果 (Outcome)。

DEEP READ | 精讀指引

• Step 2: build the tree, and reframe everything as a need：這段指出了最常見的陷阱——「用戶不能輸出 PDF」不是一個需求，這是一個被剝掉動詞的「解決方案」。「我無法一次瀏覽所有行事曆」才是真實需求。這對重塑 PM 的訪談敏銳度至關重要。
• Where AI actually changes the work：作者對 AI 在產品管理的價值給出了極為獨特的視角：AI 的價值不是快，而是「執行紀律」。人在時間壓力下會跳過 MECE 檢查、懶得去除重，但 AI 永遠不會疲倦。

前言/背景

量化評分固然好，但對尚未被深刻理解的「機會」進行量化打分，並把小數點當作真理，是極度危險的。本文基於《持續探索 (Continuous Discovery Habits)》一書的框架，探討如何正確地繪製機會地圖，並利用 AI 確保這套方法論不被人類的惰性所破壞。

章節詳細總結

為什麼 RICE 評分在機會階段會崩潰

RICE (Reach, Impact, Confidence, Effort) 的前提是：你有一個已知且可估計的解法。 在「機會探索階段」，你連解法都還沒有，根本無法評估 Effort；在做研究前，你也無法知道 Reach。最終，這些數字只是用來美化「團隊早就想做的決定」。 如果你跳過機會的辯論，直接去辯論功能，你就永遠無法做出戰略級的押注，只是在排程而已。

Step 1: 在構建前校準輸入 (Intake)

• 結果導向 (Outcome)：目標必須是可衡量的「使用者行為」或「商業結果」，絕不能包含解法。例如：「建立通知中心」是錯誤的，應改為「提升 48 小時內回訪的比例」。
• 旅程節點 (Journey Nodes)：用時間點（發現、決定、註冊、使用、回顧）來分類問題，絕對不要用工程類別（穩定性、信任、效能）來分類。工程分類會帶入企業內部的視角盲點，只有時間節點能還原用戶真實遭遇的斷層。

Step 2: 建構樹狀結構，將一切重構為「需求」

機會必須是使用者的需求、痛苦或渴望，絕不能是解決方案。

• 錯誤：「使用者無法匯出成 PDF」。（這是一個披著偽裝的功能）
• 正確：「我無法一次查看所有行事曆」。 建樹時必須進行兩個嚴格檢查：

1. 獨特性測試 (兄弟節點)：如果不解決 A 也能解決 B，兩者才可並存；否則應合併。
2. 父子測試 (上下節點)：解決子節點必須能部分解決父節點。 只有真實訪談聽到的需求才能上樹，假設性的直覺應分開記錄。

Step 3: 用「比較」取代「評分」來選定目標

• 評估四個定性視角：機會規模、市場因素、公司因素、客戶因素。
• 不打分數，寫下比較：「相比於 A，B 在客戶因素上更強，但在市場因素上較弱…」。
• 避免二元提問：不要問「我們該解決這個嗎？」這會引發確認偏誤。要問「哪一個是現在最重要必須解決的？」這能強制暴露機會成本。 決策的產出應該包含：被選定的機會、其背後的假設（Unknowns），以及下一輪訪談要問的 3-4 個問題。

AI 如何真正改變產品探索工作

AI 的核心價值不在速度，而在於紀律的強制執行 (Enforcement)。 去重疊、重構敘述、做 MECE（互斥且周延）檢查，這些方法論 PM 都懂，但在死線前往往會偷懶跳過。 AI 系統（如作者設計的 PM OS 工作流）能不厭其煩地對幾十個訪談片段執行這些嚴格的邏輯檢查，把原本需要一週的手動梳理壓縮到一個下午，且產出的樹狀圖比手動建立的更加嚴謹。

總結與結論

1. 停止過早量化：在還沒釐清機會本質前，拒絕使用 RICE 評分來逃避艱難的戰略選擇。
2. 轉換視角：將 Roadmap 的描述從「功能產出」轉為「行為結果」；將問題的分類從「工程領域」轉為「時間節點」。
3. AI 的紀律價值：利用 LLM 強大的文本處理能力，將其作為一個「永遠遵守探索紀律的機器人」，強制把帶有解法的訪談重構為純粹的使用者需求。