Issue tree: definition, example and method

An issue tree is a hierarchical picture of a question. The client's question sits at the root. Each level splits it into sub-questions that together cover it entirely without overlapping, in other words in a MECE way. You go down until you reach questions that can be answered with a yes, a no or a number.

The tool comes from the practice of consulting firms, where it is used to divide work across a team as much as to think. It has no established inventor, and you will also see it called a logic tree or a question tree.

It comes in two versions, which do not answer the same question.

• The diagnostic tree answers "why?". Why sales are falling, why lead times are getting longer. Its branches are possible causes.
• The solution tree answers "how?". How to gain ten points of margin, how to reduce absenteeism. Its branches are levers for action.

Mixing them up is a classic mistake: suggesting solutions when the cause has not been found yet.

A driver tree breaks a number into measurable factors linked by a formula, whereas an issue tree breaks a question into sub-questions linked by logic. The first is calculated, the second is argued.

The profit tree is a driver tree: profit = revenue - costs, no debate possible. "Should we launch this offer?" calls for an issue tree: do customers want it, can we produce it, will it be profitable? These branches do not add up, they all need to be true.

In the FrameLab course, these are two of the five reasoning building blocks, alongside segmentation, process mapping and business mental models. Most cases need two at once: a driver tree to locate the problem in the numbers, then an issue tree to look for its cause.

The tree below is a diagnostic tree for an online store whose revenue is falling. The first level comes from a formula, which guarantees that no cause is forgotten. The second level uses a segmentation, chosen because it matches different teams and different causes: you do not act on paid traffic and free traffic in the same way.

Three levels are almost always enough in an interview. Beyond that, the tree becomes unreadable out loud and you lose the interviewer.

Here is the prompt. A DIY retailer's website used to make €2M in sales a month. For three months it has only made €1.7M, 15% less. Management wants to know why.

Lay out the tree. Sales = visits x conversion rate x average basket. You announce the three branches and say that you will first spot which one moved before looking for the cause.

First level. You ask for the three numbers before and after.

Visits and basket are stable. The whole drop comes from conversion, which goes from 2.0% to 1.7%. Two branches out of three are closed with one question.

Second level. You segment conversion. Among the possible splits, by product type, by customer type, by device, you choose device and say why: a sudden, recent drop suggests a technical change, which rarely affects every screen in the same way. The interviewer gives the numbers. Half of visits are on mobile. On desktop, conversion stayed at 2.5%. On mobile, it fell from 1.5% to 0.9%.

Third level. The problem is now small: what changed on mobile three months ago? You offer two hypotheses, a change to the checkout flow or slower pages. The interviewer confirms the first: the new mobile flow requires creating an account before paying.

Recommendation. The €300,000 monthly drop comes from a single step of the mobile checkout. Guest checkout should be restored, and mobile conversion measured over two weeks to confirm the return to 1.5%.

The tree breaks when the first split is wrong. Everything below inherits it. For a company whose delivery times are getting longer, a first level of "internal causes, external causes" is logically complete and leads nowhere. A first level that follows the steps from order to delivery shows straight away where time is lost. The FrameLab course devotes a whole case to this comparison.

It also breaks when you try to explore everything. A full three-level tree easily has twenty leaves, and the time for a case is limited. The tree gives you the map, not the route. Without prioritisation, and therefore without a leading hypothesis, you walk the branches in order and time runs out before you reach the right one.

Third limit: the branches are not truly independent. In the example, conversion and basket are linked, since a painful checkout discourages small orders first. A tree sorts, it does not model interactions.

Finally, a tree learned by heart is no longer a tree. If your structure for "sales are falling" is identical for a DIY website, an airline and a law firm, you are reciting a framework dressed up as a tree, and it shows from the second branch.

Start from the question, rephrased as one sentence ending with a question mark. Then choose the first split by asking yourself what the problem is made of.

• A number has moved. Write the formula that produces it, in the client's words. You get a complete first level without effort.
• A flow has seized up. Walk through its steps in order and look for the one that is stuck.
• A decision has to be made. List the conditions that all need to be true for the answer to be yes.
• The problem may be concentrated somewhere. Segment, by customer, by product, by channel or by region.

Next, check your tree with three questions. Does it answer the question asked directly? Is it MECE on the first level? Does it fit in two or three levels that can be said out loud?

Finally, say where you start and why. That is what turns an inventory into reasoning. To practise, take a real interview case, hide the rest of the prompt and give yourself one minute to lay out the tree. The interview questions offer short prompts that suit the exercise well.

The average waiting time in a hospital's emergency department went from two to four hours in a year. Build a two-level diagnostic tree, then say which branch you would open first.