How to Structure a Consulting Case: The Issue Tree Method

Before you learn how to build one, understand what you're actually building.

Imagine you're a firefighter arriving at a building fire. You don't run in randomly and start spraying water. You size up the building first: which floors are burning, where the exits are, where people might be trapped. That 30-second assessment is your structure. It tells you where to put resources and in what order.

A case structure is the same thing. It's a quick assessment (before any analysis) of what the problem space looks like. Which areas could be causing this? Which areas can we rule out immediately? Where is the highest-leverage place to dig first? The structure doesn't answer the question. It maps the territory so your analysis doesn't waste time in the wrong rooms.

Without it, you're the firefighter running blind. With it, you're the one who finds the problem in half the time.

An issue tree is the visual tool consultants use to build and communicate structure. Here's how to think about it.

You're a detective who just walked into a crime scene. You don't dust every surface. You start with three questions: motive, means, opportunity. Each of those breaks into sub-questions. Motive breaks into who benefits from this outcome, and who had a grievance. Means breaks into who had access, and who had the skill. You work down the tree, eliminating branches as evidence rules them out.

An issue tree does exactly this for a business problem. The root is the client's question: "Why is our profit falling?" The first level of branches is the MECE breakdown of possible causes: revenue problem, cost problem, or both. Revenue then breaks into price and volume. Volume breaks into customer count and purchase frequency. Each branch is a hypothesis. You eliminate the ones the data rules out and go deep on the ones it supports.

The tree keeps you from running in circles. Every question you ask maps to a node. If a question doesn't map to any node, you either add the node or you drop the question, because it means you're investigating something outside the problem space.

The interviewer gives you the prompt. You ask one clarifying question to confirm the objective. Then you say: "Can I have a minute to structure my thoughts?" Here's what happens in that minute.

Step 1: Write the client's question at the top of your page. Not the situation. The question. "Should Peloton cut prices?" not "Peloton's subscriber growth is slowing."

Step 2: Draw three to four Level 1 branches. These are the major MECE categories of the answer space. For a profitability case: Revenue and Cost. For a market entry case: Market attractiveness, Competitive advantage, and Go-to-market. Don't invent a new framework for every case. A small set of reliable Level 1 structures covers 80% of cases.

Step 3: Add one level of detail under each branch. Revenue breaks into Price and Volume. Volume breaks into New customers and Retention. This second level is what proves to the interviewer you know the domain, not just the template.

Step 4: State a hypothesis. Before you start asking for data, commit to a working theory. "My hypothesis is the problem is on the cost side, specifically fixed costs that haven't scaled down with lower demand, but I want to validate with revenue data first." This is what separates hypothesis-driven analysts from data-gatherers.

Practice this on the Peloton case, a classic profitability problem where the branching structure between hardware, subscription, and content costs reveals exactly which lever matters most.

Knowing the method isn't enough. These four mistakes appear in almost every first draft.

Mistake 1: Starting with a named framework instead of the problem. "I'll use the 4 Ps" is not a structure. It's a template. Frameworks are inputs, not outputs. Your structure should come from the client's specific question, not from a memorized list.

Mistake 2: Level 1 branches that aren't MECE. "Revenue, Costs, and Gross Margin" has overlap. Gross margin includes revenue. If a data point could fit in two branches, your structure is broken before analysis begins.

Mistake 3: Too many branches. Three to four Level 1 branches is the limit. More than four and you've described the problem instead of structured it. If you have six branches, two of them should be merged or cut.

Mistake 4: Skipping the hypothesis. A structure without a hypothesis is just a list. The hypothesis is what makes the tree a tool. It tells you which branch to investigate first and what outcome would change your mind.

Case structure is a muscle. You build it by doing, not by reading about it.

Exercise 1: Structure a news headline. Pick any business story and build a Level 1 issue tree for the problem it describes. "Starbucks traffic is down 8% YoY." Draw the tree before reading the article. Then check how close you were.

Exercise 2: Force yourself to a hypothesis. After you draw any structure, write one sentence starting with "My hypothesis is..." before you're allowed to ask for data. If you can't form a hypothesis, your structure isn't specific enough.

Exercise 3: Practice on a case that pushes back. The best way to test a structure is to use it under pressure, with a case that has real data, dead ends, and turns that punish weak initial structure. That's what realistic case practice builds.