/mckinsey-issue-tree: trees to solve any problem（麥肯錫議題樹：解決任何問題的模型）

原始來源與檔名：2026-07-28T095111+0800-mckinsey-issue-tree trees to solve any problem.md

SOURCE | 資訊源評估

準確性：高 - 作者結合了經典的管理顧問思維模型（麥肯錫 MECE 原則與議題樹）與現代 AI Agent 工作流。
易理解性：高 - 結構分明，用三種類型的樹（Why, What, How）將混亂的問題解決過程具象化。
閱讀策略建議：熟記 Why / What / How 三種樹的對應場景與最終產出，並理解如何透過 AI 實現這些思維模型的自動化。

NAPKIN | 餐巾紙

餐巾紙公式

Problem Solving = MECE Principle + (Why-Tree OR What-Tree OR How-Tree) + AI Automation 在解決問題前，先確定你要找的是「原因」、「計畫」還是「方案」，然後套用對應的樹狀結構，並用 AI 來校驗 MECE（不重不漏）。

一句話

許多問題之所以無解，是因為團隊把「找原因」、「做計畫」和「找解法」混為一談；使用麥肯錫議題樹可以解開這些思維糾纏。

餐巾紙草圖

┌─────────────────────────
│ 3 Types of Issue Trees
│
│ 1. [WHY]  → Root: Why is X happening? → Leaves: Causes → Output: Testable Hypotheses
│ 2. [WHAT] → Root: What work is needed? → Leaves: Tasks  → Output: Sequenced Workplan
│ 3. [HOW]  → Root: How to achieve Y?    → Leaves: Actions→ Output: Ranked Options
└─────────────────────────

ROUND 1: SKELETON | 骨架掃描

核心問題 / 核心答案 / 論證結構
- 產品與商業問題為何經常在還沒開始研究前就已經走偏？ / 因為團隊在沒有對齊「當前要解決什麼問題」的情況下，把找原因、排計畫、找解法混在一起討論。 / 先定義問題的根源錯誤，接著介紹三種專門的議題樹（Why/What/How），然後說明 MECE 原則，最後帶入如何用 AI 將此方法標準化。

章節骨架（條列）

痛點：問題在開始前就已經走偏（思維混亂）
解開思維的糾纏（Untangle the branches of thought）
- Why-tree：找原因（產出：可測試的假設）
- What-tree：拆解工作（產出：工作計畫）
- How-tree：列出方案（產出：排序選項）
範例展示（Example）：新用戶啟動率不佳的拆解
結構性檢查的局限與 MECE 原則
讓方法可重複化（Make the method repeatable）：AI 的角色
給團隊配備此技能（AI PM OS 廣告）

ROUND 2: DISSECTION | 血肉解剖

論證鏈（ASCII）/ 3 個關鍵證據 / 隱形假設與邊界

┌─────────────────────────
│ 人類在面對複雜問題時，直覺會把「猜原因」和「給解法」混為一談
│ → 需要一種強制分離的結構：麥肯錫議題樹 (Issue Trees)
│ → 但手動建立 MECE 議題樹耗時且難以在團隊中規模化
│ → 結論：將 Issue Tree 封裝為 AI Skill，由 AI 負責結構生成與 MECE 檢查，PM 負責判斷。
└─────────────────────────
**3 個關鍵證據**：
1. 錯誤歸因：當團隊連原因都還沒找到（需要 Why-tree）時，常常就已經有人在提議解法（How-tree），導致無效決策。
2. MECE（Mutually Exclusive, Collectively Exhaustive）原則：議題樹的每一層都必須不重疊且不遺漏，這能幫助 PM 發現盲點。
3. AI 提效：單一 PM 畫樹很慢，但將其寫成 `mckinsey-issue-tree` Prompt/Skill 後，AI 可以無限次地草擬分支並執行 MECE 檢查，讓 PM 專注於審核。
**隱形假設與邊界**：
- 假設問題是可以被完全解構為樹狀邏輯的（適用於商業與產品邏輯，不一定適用於高度混沌或情感驅動的問題）。
- 邊界：結構檢查（MECE）無法證明樹的「真實性（Truth）」，AI 只能檢查邏輯上是否完備，無法驗證現實中某個原因是否真的存在。

ROUND 3: SOUL | 靈魂提取

作者盲點 / 知識連接 / 行動觸發
- 知識連接：MECE 原則與金字塔原理（Pyramid Principle），這兩者是頂級顧問公司（如 McKinsey, BCG）分析問題的基石。
- 行動觸發：下次開會討論問題時，先在白板上寫下：「我們現在是在找 Why、What，還是 How？」嚴格制止在找 Why 的階段提出 How。

留白提問（2 題）/ 跨域映射

在探索未知領域時，如果我們連可能的原因（Why）都無法窮盡，如何保證樹狀結構符合 MECE？
過度依賴 AI 進行 MECE 檢查，會不會導致 PM 失去直覺上的問題嗅覺，只會照本宣科？

跨域映射：這就像是資料庫設計中的「正規化（Normalization）」。把混在一起的屬性拆分到不同的表中，確保數據不重複、不遺漏，議題樹就是在對「思考過程」進行正規化。

DEEP READ | 精讀指引（2-3 段 + 推薦理由，製造認知阻力）

“Each person may answer a different question. Finding the cause, making a plan, and choosing a solution are three different jobs. When people mix them together, they can miss important facts or make weak decisions.” “Use Why for causes, What for work units, and How for actions. Each leaf type supports a different decision.” “Structural checks cannot prove the tree is true. All three trees use the same MECE rule… This check helps a PM identify areas that are covered by more than one branch and areas that are not covered at all.” 推薦理由：第一段與第二段精準地點出了團隊溝通中最常見的災難：目標錯位。強迫將思考拆分為 Why / What / How 是一種強大的思維紀律。第三段則點出了模型的極限——邏輯完美不代表事實正確，MECE 只是防呆機制，不是真理探測器。

STRUCTURE MAP | 全書結構圖（ASCII）

┌──────────────────────────────
│ McKinsey Issue Trees for Product Management
├─ The Problem
│  └─ Mixing causes (Why), plans (What), and solutions (How)
├─ The Three Trees (The Framework)
│  ├─ WHY-Tree: Finds causes → Testable hypotheses
│  ├─ WHAT-Tree: Breaks down work → Sequenced workplan
│  └─ HOW-Tree: Lists paths/actions → Ranked options
├─ The Validation Mechanism
│  ├─ MECE Rule (Mutually Exclusive, Collectively Exhaustive)
│  └─ Limitation: Checks structure, not truth
└─ The Automation (AI Agent)
   ├─ Human PM: Decides the tree type, sets context, reviews
   └─ AI Agent: Drafts branches, runs MECE checks, creates visuals
└──────────────────────────────

/mckinsey-issue-tree: trees to solve any problem (Architectural Deep Dive)

前言/背景

許多產品與商業問題在真正開始解決前就已經注定失敗，因為團隊對「當前要解決什麼問題」沒有共識。開會時，有人在找原因，有人在排計畫，有人在丟解法。麥肯錫的「議題樹（Issue Tree）」框架正是為了解開這種思維糾纏而生，而現在透過 AI Agent，這種高階思維模型可以被自動化與標準化。

章節詳細總結

解开思维的纠缠：三种议题树

解決問題時，必須明確當前處於哪個階段，並使用對應的樹狀圖：

Why-tree（為何樹）：用來找「原因」。根節點問為何發生，葉節點列出潛在原因。最終產出：可測試的假設清單。
What-tree（做什麼樹）：用來「拆解工作」。根節點問需要哪些工作，葉節點列出分析、決策或產出物。最終產出：有順序的工作計畫。
How-tree（如何樹）：用來找「解法」。根節點問如何達到目標，葉節點列出具體行動。最終產出：優先級排序的方案。

结构检查的局限与 MECE 原则

這三種樹都必須遵守麥肯錫著名的 MECE 規則（Mutually Exclusive, Collectively Exhaustive，不重疊且不遺漏）。 MECE 幫助 PM 找出哪些領域被重複涵蓋，哪些領域被徹底遺漏。但作者特別強調，結構檢查無法證明樹的「真實性」。邏輯上完美的樹，其假設在現實中可能是錯的。

规模化与 AI Automation

單個 PM 手動畫 MECE 樹非常耗時，這阻礙了該方法的普及。透過將此流程封裝為 AI Skill（如作者提到的 mckinsey-issue-tree），AI 可以自動化以下步驟：

根據上下文草擬分支。
自動執行 MECE 規則檢查，找出遺漏與重複。
繪製可視化的樹狀結構。而人類 PM 的職責則轉變為：定義問題上下文、選擇要用哪種樹，以及審核/修剪 AI 生成的結果。

總結與結論（3-5 點）

強制切分思考階段：永遠不要在尋找原因（Why）的階段討論解法（How），這是提升團隊會議效率的第一原則。
輸出決定工具：如果你的目標是找到「可測試的假設」，用 Why 樹；如果是要「工作計畫」，用 What 樹；如果是要「決策選項」，用 How 樹。
MECE 是邏輯防呆，不是事實檢測：確保選項不重疊、不遺漏能減少思考盲區，但最終仍需透過市場測試來驗證假設（Truth）。
AI 讓管理框架落地：過去只有受過專業訓練的顧問才能熟練使用的 MECE 議題樹，現在可以透過 AI Agent 固化為團隊的標準化工作流，大幅降低高階思維模型的使用門檻。