Knowledge · Strategy & Planning

Logic Tree · Issue Tree

Logic Tree / Issue Tree

📂Strategy & Planning⏱2 min read📊Practical🔗5 related

What is a logic tree?

In one line
A core tool of consulting-style problem solving: break one problem down step by step, like the branches of a tree, to structure causes and solutions without gaps.
Bring this topic in-house📚 Related course💬 Message us
⚡ Summary in 3 lines
  • Break a problem down into MECE branches
  • Three types: Why (cause), How (solution), and What (concept)
  • It is done only when leaf branches become 'hypotheses to verify'

The moment you bring out a logic tree, the nature of the meeting changes. Ask 'Why aren’t sales rising?' as an open question, and each attendee describes what they see from their own department. The claims sit at different levels, so there is no way to judge who is right. Once the problem is split into branches, one question remains — which branch do we check with numbers first? The conversation shifts from rebutting each other’s experience to assigning an owner and data to each branch. That is the change this tool actually creates.

There are two main ways to decompose a problem. Splitting by formula, such as revenue = visitors × conversion rate × average order value, structurally prevents overlaps and gaps, and every leaf gets a number right away, which makes it strong for tracing causes. Splitting by structure, such as customer journey, value chain or the 4Ps, attaches numbers later but widens the range of alternatives. Use the formula type to narrow down causes and the structure type to spread out alternatives — that is the standard combination in practice. The moment you mix the two criteria within one level, the branches are bound to overlap.

Size has limits too. Beyond 3 levels and 10–15 leaf nodes, it becomes hard to assign an owner and data to each branch, and the tree usually ends up as a picture on the wall. A fishbone diagram lays out candidate causes broadly, and a mind map helps with divergent thinking; a logic tree differs in that it turns leaf nodes into units of verification. That is why each leaf must end as a statement that can be judged true or false, not a noun.

The most common mistake in practice is treating MECE as a contest of completeness. Teams spend a two-day workshop on the diagram alone, trying to split everything without gaps, and finish without anyone checking which branch the numbers actually broke down on. Leaf nodes that end in unmeasurable words are also common. Branches like 'weak organizational culture' or 'lack of employee motivation' can be neither verified nor refuted, so they end up as report decoration. Borrow someone else's standard tree and fill in the boxes without your own numbers, and you get dozens of action items that never get done all at once.

Courses That Cover This Term · Finance & Strategy
Recommended courses · Recommended instructors · Quick quote
🧮 Mini quote · Based on instructor fees
About KRW 1.2 million (≈ US$900)2-hour talk · up to 20 people · Korean
Get a quote for these requirements →
💡 In plain English
It works like inspecting a house with a fault: instead of worrying about the whole house, you divide it into electrical, plumbing, and structure, then flip the breakers one at a time to narrow down the problem.
Why it matters in practice
In problem-solving and planning training, it is the core exercise that turns the abstract goal of 'structuring your thinking' into a tangible deliverable.
Origin and sources

Strategy consulting firms such as McKinsey developed it into a standard problem-solving procedure, applying Barbara Minto’s Pyramid Principle and the MECE concept to problem decomposition. It is used in several variants, such as issue trees and hypothesis-driven trees.

Source · Barbara Minto, “The Minto Pyramid Principle”
An example

Consider a hypothetical case: Company A, an industrial-parts manufacturer with 260 employees and KRW 84 billion (≈ US$62,846,000) in annual revenue. Over the last six months its on-time delivery rate fell from 92% to 78%, and two major clients sent late-delivery penalty notices. Sales blamed production, and production blamed sales for overcommitting on orders. The team was already on its fourth round of the same countermeasure meeting.

  1. At the first meeting, the head of production said, "It’s because our equipment is over 10 years old." Before anyone discussed causes, the facilitator proposed they first break down which process the 412 delays had stalled in.
  2. Sorting the past six months of delays into five branches — order receipt, material receiving, machining, assembly and shipping — showed that material receiving accounted for 198 cases (48%), as many as the other four combined.
  3. When they split material receiving again into order delays, supplier delivery misses, and inspection backlog, the backlog came to 118 items, and the quality team lead admitted, "Two inspectors handle 60 items a day."
  4. They turned that leaf into the hypothesis 'Orders waiting for inspection 3+ days are concentrated in two items from specific suppliers' and assigned a purchasing associate to analyze two weeks of receiving logs.
  5. Verification showed those two items made up 71% of waiting cases. After supplier self-inspection certificates replaced incoming inspection, on-time delivery rose from 78% to 91% in three months, and monthly delays fell from 69 to 24.
Related terms
Training linked to this term
📚Planning Skills ProgramNanum Consulting corporate training · In-person or onlineSee course →
Need in-house training on this topic?
Get a curriculum and quote tailored to your needs right away.
Ask About Training
Last updated 13 Sep 2026 · Reviewed by John Kim

FAQ

The purpose is similar, but the form and use differ. A fishbone is strong for having a team lay out candidate causes together; a logic tree is strong for pinpointing causes by attaching numbers through formula or stage breakdowns.
The standard is 'actionable.' If you can decide what to do from the end of a branch, that is enough. Trees usually stop at the third or fourth level.
Use them in order. Identify the cause with a Why tree, then put that cause at the top and lay out solutions with a How tree.
If branches overlap, you analyze the same cause twice; if something is missing, you never see the real cause at all. Omissions are the bigger risk.