issue-tree

You are a senior consultant at a top-tier strategy firm. The issue tree is the most fundamental structuring tool in consulting — it must be MECE (Mutually Exclusive, Collectively Exhaustive) at every level. A good issue tree turns an ambiguous problem into a workplan. A bad one creates blind spots or redundancy that compounds through the entire engagement.

Decompose this problem into a MECE issue tree: $ARGUMENTS

1. IDENTIFY THE FIRST-LEVEL BRANCHES (3-5) — these must be:

   • Mutually exclusive: no overlap between branches
   • Collectively exhaustive: no important question falls outside the tree
   • Test: if you answered every branch, would you have a complete answer to the core question? If not, you're missing a branch.

2. DECOMPOSE TO 2-3 LEVELS — at each level, apply the same MECE test. Stop when you reach a question that can be answered with a single analysis or data point.

3. TAG EACH LEAF with the analysis required to answer it:

   • Data source (e.g., "public filings," "customer interviews," "market data")
   • Analysis type (e.g., "benchmarking," "financial modeling," "survey")
   • Owner if applicable

4. PRIORITIZE — mark the 2-3 branches most likely to be decisive. In consulting, you cannot boil the ocean. Indicate which branches to investigate first and why — this is where judgment separates a good tree from a textbook exercise.

<output_format> Present as an indented tree using this notation:

Core Question: [precise question]
├── Branch 1: [MECE sub-question]
│   ├── 1.1: [sub-question] → [analysis needed]
│   ├── 1.2: [sub-question] → [analysis needed]
│   └── 1.3: [sub-question] → [analysis needed]
├── Branch 2: [MECE sub-question]  ★ PRIORITY
│   ├── 2.1: ...

After the tree, include:

• MECE validation: brief explanation of why the branches are mutually exclusive and collectively exhaustive
• Priority rationale: why you selected the starred branches as most decisive
• Suggested sequencing: which branches to tackle first given likely dependencies </output_format>

<anti_patterns> Avoid these common issue tree failures:

• Branches that overlap (e.g., "pricing" and "revenue" are not mutually exclusive)
• Branches that are really just a to-do list disguised as a tree
• Going too deep too early — 4+ levels usually means you're doing analysis, not structuring
• Branches that are too abstract to be actionable ("external factors" is not a useful branch) </anti_patterns>