一家 B2B 軟體公司正在討論要不要進入 Market X。CEO 問：「我們明年該不該進去？如果失敗，最可能卡在哪裡？」

業務開始估市場規模，財務想算獲客成本與回收期，產品盤點在地化需求，法務查法規，營運看導入與客服量能。這些工作各自都合理，但如果此時直接分工，很可能幾週後每個人都帶回一疊資料，團隊卻還是說不清楚哪些證據真的會改變 go / no-go。

問題結構化要處理的，就是這個落差。先把決策邊界固定，再選一種適合研究的切法；檢查切法有沒有重疊與明顯缺口；把重要分支轉成可衡量的 driver；最後針對最值得驗證的不確定性提出 working hypothesis。當 leaf 已經能變成有人負責、知道要查什麼的 workstream，就該離開白板開始研究。

七階段問題結構化流程：Decision question 依序經過 Problem Statement、Issue Tree、MECE check、Driver Tree、Hypothesis Tree，最後形成 Research workstream。

畫樹之前，先界定要做的決策

McKinsey 的七步驟 problem-solving 方法把問題定義放在拆解與分析之前。原因很實際：如果問題沒有邊界，市場、產品、競爭、法規、價格、通路、組織與人力都可以繼續往下研究，資訊量會成長得比決策品質更快。

Market X 這句「要不要進」還需要幾個欄位才能成為可研究的問題。以下是本文採用的實務 synthesis，並非某個機構發布的標準格式：

欄位這個案例要說清楚的事
Decision是否在明年正式進入 Market X
Target outcome進入後能否建立具經濟可行性的客戶取得與服務模式
Time horizon進入前準備期，以及進入後第一年的表現
Scope哪一類客戶、哪一種產品方案、哪一個地理市場
Decision criteria例如可達市場、單位經濟、執行時程與必要投入是否落在可接受範圍
Baseline不進入、延後進入，或先用小規模試點測試
Non-solution wording問題不能預先假設「一定要進入」或「一定要找某個通路」

最後一欄很容易被忽略。「如何成功進入 Market X？」已經把進入市場當成前提；「是否應該進入？如果要進，哪些條件必須成立？」則保留了延後、縮小範圍與 no-go 的可能性。研究還沒開始前，這個差別就會影響後面所有 branch。

同一個問題，可以有兩種合理切法

邊界固定後，Issue Tree 才有清楚的研究物件。它的用途是把複雜問題分成能研究、能排序、最後也能交給人負責的部分。McKinsey 的 problem-solving guidance 也建議對同一個問題嘗試不同 logic-tree cuts，因為不同切法會暴露不同風險。

Market X 可以先試兩種：

Cut主要 branch它最直接幫你回答什麼
經濟性reachable demand、conversion、price / contribution margin、sales / service cost、entry / operating cost這門生意算不算得過來？
執行準備度regulatory readiness、product / localization、channel、sales capacity、onboarding / support就算 economics 成立，能不能在要求時間內做到？

兩種切法都可能服務同一個 go / no-go 決策，但研究順序與責任分工會不同。選 cut 時，比「看起來完整」更值得問的是：每個 branch 是否真的會影響決策、能否被研究，以及後面有沒有機會形成清楚的 ownership。

像「其他市場因素」這種 branch 很容易補滿版面，卻幾乎無法直接派工；另一個極端則是一路切成二十個小格，卻沒有任何一格足以影響判斷。這兩種樹都可能很整齊，但研究價值有限。

Market X 的兩種平行 Issue Tree 切法：Economics cut 分為 Demand、Conversion、Contribution、Costs；Execution cut 分為 Regulation、Localisation、Channel、Capacity。

MECE 是品質檢查，不是真理認證

Barbara Minto 對 MECE 的經典定義是 mutually exclusive、collectively exhaustive：同一層的分類盡量不重疊，並且在所宣告的範圍內不要留下明顯缺口。

實際檢查一棵 tree 時，可以先看四件事：

  1. 兩個 branch 是否其實在回答同一件事？
  2. 同一層是否混了 outcome、cause、process 與 solution？
  3. 是否漏掉一個明顯會影響決策的類別？
  4. 「collectively exhaustive」究竟是在哪一個 boundary 裡成立？

例如執行準備度這一層若同時放「銷售能力」「通路策略」「營收不足」「找代理商」，就把能力、方法、結果與解法混在一起。另一邊，如果產品、法規、銷售、客服都有了，卻完全沒看 onboarding capacity，而產品又需要大量導入服務，這個缺口可能直接改變上市時程。

第四題則是在提醒我們，MECE 的完整性永遠帶著邊界。Rittel 與 Webber 對 wicked problems 的討論，以及 Checkland 對 soft systems 的研究，都指出有些管理問題連「問題怎麼定義」本身都存在爭議。此時先界定誰的目標、哪段時間、哪個系統被納入，比追求一張看起來無縫的分類圖更重要。

把分類變成可衡量的 Driver

Issue Tree 能整理問題空間，卻還沒回答優先順序。Driver Tree 往前一步，把結果與可衡量的變數或 operational levers 接起來。Bain 的 value-tree 類型案例也採用類似做法，從較高階的結果一路連到團隊可以觀察或管理的槓桿。

先拿一個刻意簡化的 Market X 模型：

Expected entry value = reachable customers × conversion × contribution per customer - launch / operating costs

這只是教學模型，沒有把它當成通用的市場進入公式。它的好處在於，原本模糊的問題會立即變得可估算。「市場大不大」會落到實際可觸及的客戶數；「通路好不好」會落到 conversion、acquisition cost 與合作條件；購買意願則會反映在 conversion、價格與 contribution per customer。

Driver Tree 也讓敏感度更容易被看見。假設 reachable customers 在 8,000 到 10,000 之間變化仍不太影響最後判斷，但 conversion 在 2% 到 6% 之間就足以讓 economics 翻面，研究資源自然應先往 conversion 集中。

這裡要保留一個證據邊界。Driver Tree 上的 edge 可能是數學分解、營運關聯，也可能只是團隊目前相信的 causal mechanism。後一種關係仍需要額外驗證；畫出 edge 本身不構成因果證明。

把優先 Driver 變成會被證據改變的假設

高影響 driver 找到了，團隊還需要決定「先查哪一個解釋」。Hypothesis-driven 的方式是把目前最值得懷疑的機制說清楚，再為它指定能讓信念上升或下降的證據。McKinsey 在營運診斷的文章中，也描述了先提出 hypotheses，再用資料 validate、disprove 或 refine 的工作方式。

Market X 可以先從三個互相競爭的 working hypotheses 開始：

Hypothesis目前的工作假設優先 evidence request哪種結果會削弱它
H1Reachable demand 足夠，但 partner-channel acquisition economics 讓 entry 失去吸引力partner terms、pilot 或 benchmark acquisition inputs、conversion assumptions、contribution per customer可信的通路條件顯示 acquisition cost 明顯低於原先假設，而且 conversion 仍合理
H2Binding constraint 在 regulatory / localization lead time，而非 demand明確 requirements 與可信的 lead-time estimates必要工作可以平行處理，或可靠時程遠短於原估計
H3初始 ICP 太寬，把一個可行的較窄 segment 平均掉了segment-level demand、conversion、willingness-to-pay evidence合理分群後仍看不到穩定差異

H1 若成立，會看到合作費用、分潤或 lead cost 即使搭配合理 conversion，仍吃掉太多 contribution。H2 若成立，則 approval、data requirements、product changes 或 compliance work 會形成超過可接受時程的 critical path。H3 的觀察重點不同，它期待某些 segment 的需求、conversion 或 willingness to pay 明顯優於其他群組。

這裡的 hypothesis 是管理上的 working hypothesis。它與統計課裡的 null hypothesis / alternative hypothesis 不同；本文也不延伸到 p-value、實驗設計或正式 causal inference。需要的是一個可以被新證據修正的暫時解釋，而非先替答案找佐證。

葉節點能研究，才算工作流

一個 leaf 到了 tree 最底層，仍可能只是一個標籤。真正能派出去做的 workstream，至少要接得上這條鏈：

Leaf → Question → Evidence needed → Owner / workstream → Decision implication

以 H1 為例，leaf 可以先寫成：Partner-channel acquisition cost 可能高到超出 contribution economics 能承受的範圍。 接著再把它變成可執行工作：

元素內容
LeafPartner-channel acquisition cost 可能過高
Question在合理的合作條件與 conversion 下，實際 acquisition cost 會是多少？
Evidence needed合作／分潤條件、pilot 或 benchmark acquisition inputs、conversion assumptions、contribution per customer
Owner / workstreamGrowth / GTM + Finance，僅為示意
Decision implication重設通路、縮小 segment、修改經濟模型、延後進入，或在限制持續存在時 no-go

如果一個 leaf 說不出要查什麼、誰能查、查完可能改變哪個決策，它通常還需要再具體化。「品牌影響力不足」就是典型例子。這句話可能指 awareness、trust、channel access，也可能指品牌造成較低 sales conversion；四種情況需要的證據與 owner 都不一樣。

到了這一步，問題結構才真正轉成研究工作，而不是一張只有分類關係的圖。

有些問題不是再多畫一層樹就會變清楚

結構化工具有一個很重要的適用邊界：有時候團隊爭議的正是問題邊界本身。

例如 CEO 把 Market X 的成功定義成兩年內獲利；策略團隊在意的是建立區域 foothold；產品團隊則希望藉此理解新產業需求。此時把「Market X success」再拆十層，不會自動消除三套不同目標。它可能只是把不同 worldview 排進同一張圖裡。

類似情況也會出現在 stakeholder 對 scope 有根本歧見、重要 feedback loop 讓 boundary 持續改變，或「誰有權決定什麼算進問題」仍未釐清時。wicked-problem 與 soft-systems 文獻提醒的正是這類情境。

遇到這些訊號，下一步應先把成功定義、stakeholder disagreement 或 system boundary 攤開來處理；必要時採用更適合多方觀點與系統邊界的方法，再回到 Issue Tree。繼續新增 branch 只會讓圖更乾淨，不一定讓問題更清楚。

下一步已清楚，就停止繼續拆

何時可以停？可以用下面七個條件做 readiness gate。這是一個實務 synthesis，並非單一機構發布的標準流程。

  1. 決策與 boundary 已明確。 團隊知道要支援哪個決策，也知道目前排除哪些東西。
  2. Issue Tree 的 cut 產生可區分、與決策相關的 research questions。
  3. MECE 檢查已做過。 重疊與明顯缺口是相對於既定 boundary 被檢查。
  4. 優先 driver 可以衡量，或已明確標記為仍待驗證的假設。
  5. Working hypotheses 有能夠改變團隊信念的 evidence requests。
  6. 重要 leaf 已有 owner，也說得出它對決策的 implication。
  7. 尚未解決的 stakeholder / boundary 爭議仍然可見。

如果這七項已經成立，再多一層 branch 未必增加決策品質。此時研究團隊已經知道下一個問題、需要什麼證據，以及哪個結果會讓原先的判斷改變，白板的工作也就完成了。

References