Issue Tree

A tree isn't just one kind

It's tempting to lump everything under "tree," but the issue tree that decomposes points, the Why tree that traces causes, the How tree that exhausts solutions, and the investigation tree that gathers facts are different in both purpose and how they're written. Mix them and your thinking stalls.

• ─Issue tree: decompose points (questions answerable Yes/No)
• ─Why tree: trace causes by repeatedly asking "why?"
• ─How tree: exhaustively expand solutions
• ─Investigation tree: gather facts and fill it in

The 3 steps of building an issue tree

Build in the order: define the problem → layer the "why?" → ground it in facts.

• ─Step 1: Define the problem ("what" / "what's happening" / "why it's a problem" + numbers and facts)
• ─Step 2: Dig down 2–3 layers of "why?" (constantly check that no solution has crept in)
• ─Step 3: Ground it in facts (put "X times a month," "X hours," "X%" on each node)

MECE checklist

Questions to ask when checking the elements lined up at the same layer.

Easy-to-use templates for MECE decomposition

Think up axes from scratch and you'll get stuck. Apply one of these templates instead. Cost-related → by expense item; process-related → by flow order; org-related → by department; unclear → "people, things, money, information."

Conversion table for grounding in facts

Convert vague expressions from discovery notes into facts.

Priority matrix

Place items in four quadrants by importance (impact of solving) × urgency (how fast it worsens if left alone).

Write the leaves as "questions"

It's easy to confuse this with logic trees in general, but in the strategic-thinking style, the leaves of an issue tree are always written as "questions." End them as descriptions of phenomena and no flow of hypothesis testing rides on them.

• ─✗ "Change in sales channels" — a description of a phenomenon (thinking stops)
• ─○ "How are sales channels changing?" — a point (hypothesis testing runs)
• ─The leaves of a Why tree are "facts (root causes)," the leaves of a How tree are "moves." Don't mix them

Emphasis (the 8:2 rule)

Once you start drawing a tree, you'll want to dig every branch equally deep. That's a time thief. Consciously separate "branches to dig" from "branches not to dig," and pour your time into the branches with the biggest impact. Placing the important axis to the left / top is also about adding visual emphasis.

Turn the unknown into executable tasks with an "investigation tree"

Even after MECE decomposition, "don't know" comes up — that's normal. There are two anti-patterns: writing "don't know" and deleting it from the tree (no one follows up), and writing "investigate further" and stopping (what / who / when is unclear). The investigation tree turns "don't know" into an executable task.

• ─Always start from an "initial hypothesis." One to three, on a hunch (rough is fine)
• ─Don't start the investigation from a blank slate (the No.1 reason "we learned a lot" never leads to a conclusion)
• ─Don't aim for 100 points in one shot; build up — 50 today, 60 tomorrow, 90 a week later
• ─Make the hypothesis judgeable as YES/NO (so a single fact can evolve it)