An issue tree is how you take a big, overwhelming question and break it into smaller, answerable pieces. It’s a visual structure, literally a tree, where the trunk is the core question and each branch is the sub-question that, if answered, contributes to answering the big one.

Think of it this way: An executive says: “We’re losing enterprise clients. Why?” That’s the trunk. You can’t answer it directly. It’s too big of a question. But you can break it into branches:

1. Is it a product problem?
2. Is it a pricing problem?
3. Is it a service or support problem?
4. Is it a competitive problem?
5. Is it a market-level shift?

Each of these branches can break further. For example:

1. Product problem: Is it features, reliability, or integration?
2. Pricing: Is it absolute cost, perceived value, or competitor undercutting?

You keep branching until you reach questions you can actually investigate and test with data, interviews, or observation.

An issue tree turns an overwhelming mess into a map. It provides a legitimate place to nest the existing the threads. Instead of compressing them out of existence, you can organize them into a structure where each one has a position. Nothing is lost and everything has an address.

The key discipline. Issue trees follow one rule, called MECE. The acronym stands for Mutually Exclusive, Collectively Exhaustive.

1. Mutually exclusive means the branches don’t overlap. If “pricing” is one branch and “customers think it’s too expensive” is another branch, that’s overlap. The second one lives inside the first.
2. Collectively exhaustive means the branches, taken together, cover the entire problem. If you have a product, pricing, and support as your branches but you’ve left out competitive dynamics, your tree has a gap.‍
3. Perfectly MECE trees are rare in practice. But the discipline of trying forces you to think about what you might be missing and where your categories bleed into each other. It makes your thinking cleaner even when it’s not perfect.‍
4. MECE is quality standard. It’s the test you apply to any structure to check whether it’s clean. It doesn’t tell you what to build, but whether what you built holds up. Learning MECE separately would be like learning “grammatically correct” as a separate skill from writing. You get a hold of it by applying it inside the structures that need it.‍

How it connects to SCR. Issue trees are what you do between “I see the mess” and “Here’s what matters most.” They’re the analytical engine underneath the compression move (SCR). In practice, one often uses them sequentially: build the issue tree to map the full problem space, then compress the tree into an SCR for the person who needs to make a decision. Expand first, compress second, SCR third.‍

Who created the framework? Issue trees come from the same consulting ecosystem as SCR: McKinsey, specifically. They emerged as a core tool in the 1960s-70s as management consulting professionalized and needed structured approaches to problem-solving. The person most associated with popularizing issue trees as a problem-solving method is Ethan Rasiel, a former McKinsey consultant who wrote The McKinsey Way in 1999. But the tool itself predates the book. It was internal methodology that consultants learned on the job for decades before anyone wrote it down publicly.

Who uses it? Everyone in strategy consulting, but also increasingly in product management, venture capital due diligence, policy analysis, intelligence work, and corporate strategy teams. Anytime someone faces a complex question and needs to decompose it systematically, they’re using some version of an issue tree, whether they call it that or not. When someone says: “I don’t know why this is happening,” the issue tree is how one turns that confusion into a structured investigation. It’s the diagnostic tool before the briefing.‍

Variations

1. Issue tree (diagnostic). The trunk is a question: “Why is X happening?” The branches decompose the question into sub-questions. You’re exploring. You don’t know the answer yet. You’re mapping where to look.
2. Hypothesis tree. Same structure. Different starting point. Instead of a question, the trunk is a hypothesis: “Revenue is declining because we’re losing mid-market clients to a cheaper competitor.” The branches then become the evidence you’d need to prove or disprove that hypothesis. Each branch is a test. This is faster than a diagnostic tree because you start with a point of view, but it’s riskier. If your hypothesis is wrong, the whole tree is wasted. Experienced consultants might start with hypothesis trees because their pattern recognition lets them make educated guesses quickly.
3. Decision tree. The trunk is a choice: “Should we enter the European market?” The branches are the factors that influence the decision, and each branch leads to a different outcome. This is closer to scenario planning.

The depth question matters. How many levels deep should you go? The answer is: deep enough that the bottom-level questions are answerable with data or investigation. If your bottom branch is still a big abstract question like “Is there a market problem?”, you haven’t gone deep enough. If it’s “What is our churn rate among manufacturing clients with over 500 employees in the DACH region?” That’s answerable. That’s where you stop.

The prioritization question is where compression lives. A full issue tree for a complex problem might have 40 or 50 bottom-level questions. You can’t investigate all of them. So you have to choose: which branches are most likely to contain the answer? Which ones, if true, would change the decision? Which can be deprioritized? That’s the compression move in this framework: not cutting the branches, but choosing where to focus first.

Issue trees are co-thinking artifacts. It’s a common, team effort of mapping the problem together, making the invisible structure visible.