| name | issue-tree-builder |
| description | McKinsey-style issue tree framework for breaking down complex problems into MECE (Mutually Exclusive, Collectively Exhaustive) components. Use when users need to decompose strategic questions, structure analysis, create work plans, or prepare for case interviews. Apply hypothesis-driven approach to problem-solving. |
Issue Tree Builder
A structured approach to breaking down complex problems into actionable components using MECE principles.
What is an Issue Tree?
A visual hierarchy that decomposes a governing question into increasingly specific sub-questions or components. Used in consulting to structure analysis, prioritize workstreams, and develop hypotheses before solutioning.
Key characteristics:
- Top-down structure (question → branches → sub-branches)
- MECE at each level (branches don't overlap, collectively cover the problem)
- Hypothesis-driven (based on initial beliefs about what matters)
- Actionable at terminal branches (lowest level = things you can analyze or do)
Framework Components
Level 0: Governing Question
- The main strategic question to answer
- Must be specific and answerable
- Examples: "How to grow revenue 40% in 12 months?", "Should we enter the European market?"
Level 1-2: Major Branches (typically 3 branches)
- Consulting "rule of 3" - aim for three major dimensions
- Decompose to fundamentals first, not actions
- Must be MECE
- Often structured around fundamental problem drivers:
- Revenue problems: Price × Quantity × Pipeline/funnel
- Profit problems: Revenue - Cost
- Growth problems: New customers, Expand existing, New products
- Market entry: Market attractiveness, Competitive position, Capability to win
Level 2: Sub-branches
- One more level of decomposition from major branches
- 2 levels total from governing question
- Terminal branches should be clear hypotheses to test with data
- Keep simple and focused
Core Principles
MECE (Mutually Exclusive, Collectively Exhaustive)
- No overlap between branches at same level
- Together they cover all relevant aspects
- Test: Can you classify any answer element into exactly one branch?
Hypothesis-Driven with Data
- Start with beliefs about what matters most
- Structure tree to test key hypotheses
- Each terminal branch = hypothesis to prove/disprove with data
- Back findings with analysis
- Example: "Hypothesis: Pricing 20% below market drives volume" → Test with data
Actionable Terminal Branches
- Lowest level = clear hypotheses to test
- Should be obvious what analysis proves/disproves it
- Examples: "Current pricing is 20% below competitors", "Conversion drops 50% at checkout", "Customer acquisition cost exceeds LTV"
Simplicity
- 2 levels total from governing question
- Consulting "rule of 3" - aim for 3 major branches (3-5 acceptable)
- Prefer clarity and focus over completeness
Example: E-commerce Revenue Growth
Governing Question: How can we increase e-commerce revenue by 50% in 18 months?
Issue Tree (Revenue = Price × Quantity × Conversion):
How to increase revenue 50% in 18 months?
├─ Average Order Value (Price)
│ ├─ Current pricing 15% below market - hypothesis: can increase without volume loss
│ ├─ Cart contains 1.8 items vs industry 2.5 - hypothesis: cross-sell opportunity
│ └─ Premium SKUs = 10% of sales vs 30% competitor - hypothesis: mix shift possible
├─ Traffic Volume (Quantity)
│ ├─ Paid CAC = $45 vs LTV $120 - hypothesis: can 2x spend profitably
│ ├─ Organic = 20% vs 40% competitor - hypothesis: SEO underinvested
│ └─ Repeat rate 25% vs 45% industry - hypothesis: retention issue
└─ Conversion Rate (Pipeline efficiency)
├─ Checkout abandonment 68% vs 58% benchmark - hypothesis: friction in checkout
├─ Mobile converts 1.2% vs desktop 3.5% - hypothesis: mobile UX broken
└─ First-time visitor 0.8% vs repeat 4.2% - hypothesis: trust/credibility gap
Each branch = testable hypothesis backed by data analysis
Usage Patterns
When creating an issue tree:
- Start with the governing question (Level 0)
- Decompose to fundamentals - not actions (Level 1, aim for 3 branches)
- Identify 2-3 key hypotheses under each branch (Level 2)
- Verify MECE at each level
- Ensure each terminal branch is testable with data
When reviewing an issue tree:
- Is the governing question specific and answerable?
- Does Level 1 break down to fundamentals (not actions)?
- Are branches at each level MECE?
- Does each terminal branch represent a clear hypothesis?
- Can you test each hypothesis with data?
- Is it 2 levels from the governing question?
Common use cases:
- Beginning of client engagement or strategic initiative
- Case interview preparation and practice
- Structuring analysis before diving into data
- Creating work plans with clear workstreams
Prioritization: Where to Start
After building the issue tree, prioritize which branches to tackle first. State: "We will start here because..." with data-backed reasoning and business impact.
Prioritization Criteria:
Impact and Effort
- Quantify potential impact on the governing question
- Consider implementation effort and cost
- Example: "Start with pricing - 10% increase = $5M revenue with minimal implementation cost"
Data-Backed Reasoning
- Reference benchmarks, customer data, financial models
- Example: "Checkout abandonment 68% vs 58% benchmark = immediate 15% conversion gain if fixed"
Quick Framework:
High Impact + Low Effort = Start here
High Impact + High Effort = Plan carefully, Phase 2
Low Impact + Low Effort = Do if time permits
Low Impact + High Effort = Deprioritize
Example Prioritization Statement:
"Start with checkout abandonment (Branch 3.1) because:
- 68% vs 58% benchmark = 10 percentage point gap
- Fixing yields immediate 15% conversion lift = $2M revenue
- 4-week implementation with known solutions
- De-risks overall 50% growth target"
Dependencies:
- Some hypotheses must be tested before others
- Start with highest conviction hypotheses
Common Mistakes to Avoid
- Not MECE: Overlapping branches or missing key dimensions
- Actions instead of fundamentals: Level 1 should decompose problem (Price × Quantity), not list solutions
- Too many branches: Stick to rule of 3 where possible (3-5 max)
- Too deep: Should be 2 levels from governing question
- Not testable: Terminal branches must be provable/disprovable with data
- Wrong starting question: Vague or non-specific governing question
- Missing the hypothesis: Each branch should represent something testable
Tips for Effective Issue Trees
Start with the right question
- "How to grow revenue?" → Good starting point
- "What should we do?" → Too vague, refine first
Use natural problem structures
- Profit = Revenue - Cost
- Growth = New customers + Expansion + New products
- Market entry = Attractiveness + Competitive position + Capability
Think hypothesis-first
- What do you believe is most important?
- Structure tree to test that belief
- Don't boil the ocean
Make it visual
- Best on paper or whiteboard first (quick sketching)
- PowerPoint: Use SmartArt → Hierarchy for clean diagrams
- Diagramming tools (Lucidchart, Miro, etc.) for team collaboration
- ASCII tree format works well for documentation
- Makes MECE gaps more obvious when visual
Iterate
- First draft won't be perfect
- Refine based on initial analysis
- Add/remove branches as you learn
