Issue Tree vs. Decision Tree: What's the Difference?
Both are branching diagrams, both look similar on a whiteboard, and the names get used interchangeably often enough to cause real confusion. They do different jobs.
Issue tree: breaks a problem into questions
An issue tree starts with one open-ended question — "why did profit drop?" — and splits it into the sub-questions that, together, explain it. Every branch is a piece of the same question, and the tree's job is to organize understanding, not choices. There's no "pick a branch and follow it" step; you're meant to investigate every branch.
Example: Why did profit drop this quarter? → Revenue down / Cost up → (each split further into its own drivers).
Decision tree: maps choices and outcomes
A decision tree starts with a specific choice and maps out the possible actions and their consequences, often with probabilities or expected values attached. The tree's job is to help you navigate toward one path, not to understand a problem in full.
Example: Should we launch the product now or delay three months? → Launch now (60% chance of strong reception, 40% chance of a rocky launch) / Delay (guaranteed smoother launch, but a competitor may launch first).
Side-by-side
| Issue tree | Decision tree | |
|---|---|---|
| Starts from | An open question | A specific choice |
| Branches represent | Parts of the problem | Possible actions |
| Goal | Full understanding | Choosing one path |
| Typical use | Diagnosis, structuring, case interviews | Risk analysis, discrete choices |
Why the mix-up happens
Both use the same visual language — a root, branches, sub-branches — and both rely on breaking something complex into smaller pieces. The difference is what's being broken down: a problem (issue tree) versus a choice with outcomes (decision tree). It's easy to reach for "decision tree" as the generic term for any branching diagram, but knowing the distinction matters once you're actually building one — a decision tree template won't help you diagnose why revenue dropped, and an issue tree won't help you weigh expected values.
In practice, they're often sequential
A typical flow: build an issue tree to understand why a problem exists, land on the real decision that needs to be made, then (if the decision involves genuine uncertainty and trade-offs) build a decision tree to weigh the specific options. Issue trees ask "what's going on here?"; decision trees ask "given that, what should we do?"
Practice building both
Meceify's canvas works for either — start from an open question and branch outward, or start from a choice and map the outcomes. Build your first tree →
Turn this into a tree
Take what you just read and build it out — no sign-up required, saved automatically in your browser.
Start building for freeFAQ
Can a diagram be both an issue tree and a decision tree?
Not quite, but they're often used together. You typically build an issue tree first to understand a problem, and a decision tree afterward to weigh the specific choice that comes out of it.
Which one do case interviews use?
Case interviews are built almost entirely around issue trees: breaking down an open-ended business problem is the core skill being tested. Decision trees show up occasionally for problems that are explicitly about weighing discrete choices.