Issue Tree Builder

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