You've framed the problem (Lesson 1). Now you need to take it apart. A vague problem statement is useless for analysis — you need to break it into concrete, non-overlapping pieces that can be investigated independently.
This is what Issue Trees do. They're the single most powerful tool in the strategic problem solver's toolkit.
An issue tree (or logic tree) is a hierarchical breakdown of a problem into sub-questions. Think of it as a mind map with discipline — every branch follows a rule that keeps it clean and useful.
Here's a simple example — the checkout abandonment scenario from Lesson 1:
Each branch is a hypothesis about what's causing the problem. The tree makes your thinking visible — and gaps obvious. Notice: we haven't solved anything yet. We've just organised what we need to investigate.
The quality of your tree depends on one rule: MECE (pronounced mee-see), coined by Barbara Minto in The Minto Pyramid Principle.
No overlap between branches. Each sub-problem belongs in exactly one bucket. If you could place the same item in two branches, your categories aren't clean.
❌ Messy: "Slow performance" and "Backend latency" — backend latency is a type of performance issue, they overlap.
✅ MECE: "Frontend rendering" vs. "API latency" vs. "Database queries" — each is a distinct source of slowness.
All possible causes are covered. If something is missing from the tree, you'll miss it entirely when analysing.
✅ Exhaustive: "Price too high" + "Value not clear" + "Trust deficit" — these cover all reasons someone might not buy.
❌ Gap: Only "Price too high" — you'd miss the trust issue entirely.
MECE forces you to think systematically rather than reactively. Most people think of one cause and run with it. A MECE tree makes you ask "What else could it be?" — and that's where the strategic insight lives.
Write the exact problem as a question. Not "Checkout is broken" but "Why is checkout abandonment 40%?" The question frames what the tree must answer.
What are the major categories of possible causes? Use an existing framework if one fits (see below), or your own logic. Keep them MECE at this level.
For each bucket, ask "What specifically could cause this?" Dig 2–3 levels deep until you reach concrete, testable statements.
Check for overlap (ME) and gaps (CE). Reorganise branches until each leaf belongs in exactly one place and everything plausible is covered.
Now that you have the full map, which branches are most likely and most impactful? Those get investigated first. The tree helps you allocate attention, not just organise ideas.
You don't always have to invent categories from scratch. These proven frameworks give you a MECE starting point for common problem types:
Company | Customer | Competitor
Use when: Analysing a business or product problem — revenue drop, user churn, feature adoption.
Example: "Why did our signup conversion drop?" → Is it us (bug/UX), them (users don't see value), or someone else (competitor offering a better alternative)?
Input → Process → Output → Feedback
Use when: Analysing a broken workflow, CI/CD pipeline, or team process.
Example: "Why are PRs taking 3 days to merge?" → Is the input bad (poor requirements), the process slow (review bottleneck), or the output broken (failing CI)?
People | Process | Product | Platform
Use when: Analysing team effectiveness, engineering velocity, or org friction.
Example: "Why did our sprint velocity drop 30%?" → People (loss/morale), Process (standups/planning), Product (scope creep), Platform (tooling/CI issues).
Frameworks help you start fast, but great problem solvers eventually build custom trees from scratch. The goal isn't to memorise frameworks — it's to internalise the MECE thinking so you can decompose any problem on the fly.
Let's walk through a realistic engineering scenario step by step.
The problem: Users report that the dashboard page loads 3x slower than last month. The engineering team is already split — is it the new charting library? The API change? The database migration?
Step 1 — Problem question: "Why is dashboard load time 3x slower than last month?"
Step 2 — First-level MECE buckets: Most performance problems break down by where the time is spent:
Step 3 — Validate MECE: Check — is there overlap between "Frontend rendering" and "API / Network"? No — they're distinct phases of the page load waterfall. Is there a gap? What about client-side compute (low-end device)? That could go under Frontend rendering. What about browser extension interference? That's client-side too. The tree is reasonably exhaustive at this level.
Step 4 — Prioritise: The team suspects the new charting library. That's one leaf under Frontend rendering. But notice — the tree reveals there are three other branches nobody was talking about. A quick check: the API response time (browser DevTools) can be verified in 2 minutes. If API payload grew 2x, that's your culprit — not the charting lib.
Before the tree: "It's the charting library!" — the team spends a week optimising bundles. After the tree: "Let's check API response size first (2 min)" — finds the real cause (missing DB index from schema migration) in 10 minutes. The tree saved a week.
Don't write "Use React Server Components" as a leaf. Write "Bundle size increased." The tree is for analysis, not solutions. Solutions come after you've confirmed the cause.
If a leaf could logically sit under two branches, your categories aren't MECE. Redraw until each leaf has exactly one home. This forces clarity.
A tree that's only one level deep is just a list. Keep decomposing until each leaf is testable — you can point to data or an experiment that would confirm or refute it.
The best trees come from diverse perspectives. Build a draft, then show it to a colleague. Ask: "What did I miss?" and "Does any branch overlap?" Their blind spots are different from yours.
Take the problem statement you (or a hypothetical) wrote in Lesson 1. Now decompose it.
Read: Wikipedia articles on Issue Trees and MECE
Next level: Chapter 3 of The Minto Pyramid Principle by Barbara Minto — the original source. It's a short, dense book used by McKinsey. Focus on the MECE chapter.
Also recommended:
In Lesson 3, we'll use your issue tree to generate and test hypotheses — turning each leaf into a falsifiable claim and designing the quickest experiment to validate or kill it. The tree gives you the map; Lesson 3 gives you the compass.