Issue Tree Builder: From One Question to Testable Branches

The whiteboard at kickoff

Picture a project kickoff. Someone writes “Why are margins down?” on the whiteboard. Ten minutes later there are eight branches: pricing, mix, procurement, labor, the new plant, competitors, currency, other. Each gets an owner, mostly by who happens to be in the room. Six weeks later there are eight decks and no answer, because the branches overlapped and nobody had said what they expected to find.

This builder takes you through ten fields: the question, who acts on it, the kind of tree, the whole you are splitting, the branches, the cut, the overlaps, your working hypothesis, the analyses that test it and the result that would kill it. Checks flag the usual mistakes as you type. You leave with a one-page tree plan to paste into a kickoff note.

An issue tree is finished when it tells you which analysis to do first and what result would prove you wrong. Anything less is a table of contents for work nobody finishes.

A tree that cannot tell you what to do first is a table of contents.

Three trees for three questions

Issue trees, also called logic trees, break one question into smaller ones until each can be answered with a piece of analysis. Charles Conn, a former McKinsey partner, and Robert McLean, a McKinsey director emeritus, built their book Bulletproof Problem Solving around “a highly visual, logic-tree method” ¹. The shape of the tree depends on the question.

For how to test a split for gaps and overlaps, see MECE, with real work examples. For why a working answer belongs at the top of the tree from day one, see hypothesis-driven problem solving.

What the checks catch

The checks are our rules of thumb, drawn from the mistakes that most often sink a tree. They warn; they never block, because you may have a reason.

• A topic instead of a question. “Margin issues” cannot be answered. The question field wants a question mark.
• Work verbs in the question. “Analyze,” “review” and “understand” describe effort, not what the decision maker needs to know.
• No owner or date. A tree with nobody waiting for the answer expands forever.
• An undefined whole. A split can only be exhaustive against something exact: “a $6 million revenue decline in 2025,” not “revenue.”
• Too many branches, or two axes at one level. “Region and customer size” in one level puts every customer in two branches.
• A hypothesis too vague to be wrong, such as “a combination of factors.”
• More than five analyses at the start, which usually means the hypothesis is not ruling anything out.
• A kill result with no number. Without a threshold, any result can be read as support.

Barbara Minto describes good thinking as grouping similar facts and then “drawing an insight from having seen the similarity” ². Her course warns that “There are three reasons” is not an appropriate insight ³. Branches are the groups. The hypothesis is the insight, and the tree is not done until you have written one.

A worked tree

Notice what the tree does not contain: a branch for competitors or the economy. Those are reasons a component might have moved, so they live one level down, under the branch they act on. Put them at the top and the same lost point of margin gets counted twice.

Where trees go wrong at scale

On a large team, the tree quietly becomes the org chart. Each branch is a workstream with a lead and a deck, and no lead wants to report that their branch did not matter. The fix is the kill result, written before any data arrives and reviewed at the first checkpoint: branches that fail it close, and their people move.

The fair objection is that a hypothesis at the top biases the team toward finding it. It can. The remedy is not to drop the hypothesis but to make it easy to lose, with a numeric threshold everyone agreed in advance. A team with no hypothesis is not neutral; it just analyzes everything at the same depth and runs out of time.

Trees also struggle when causes feed each other, such as service cuts that raise churn that forces more service cuts. A tree splits; a loop needs a map. Use the tree to size each part of the loop, not to explain it.

Write the tree so it can lose. A tree that could never prove you wrong was never testing anything.

Questions

What is an issue tree?

An issue tree, or logic tree, breaks one question into smaller questions until each can be answered by a specific analysis. A good one splits a defined whole into branches that do not overlap and leave nothing out, carries a working hypothesis, and says which analysis to run first and what result would prove the hypothesis wrong.

What is the difference between an issue tree and a hypothesis tree?

A diagnostic or solution issue tree splits a question into its parts or levers. A hypothesis tree starts from a proposed answer and splits it into the conditions that must all hold for it to be true. Many teams draw the first to see the problem and switch to the second once they have a working answer.

How many branches should an issue tree have?

Two to five at each level is a practical range, and that range is a rule of thumb, not a standard. More than five at the first level usually means two different dimensions are mixed in one level, or detail from lower levels has floated up. Fix the cut rather than adding branches.

Where to go next

• MECE, With Real Work Examples
• How Strategists Think: Hypothesis-Driven Problem Solving
• The Pyramid Principle for Strategists
• Root-Cause Tree (5 Whys)
• Root Cause Analysis Strategy