Root Cause Analysis: 5 Whys vs. Issue Trees (and When to Use Each)

Root cause analysis is the process of identifying the underlying reason a problem exists, rather than just addressing its symptoms. When done correctly, it reveals what to fix so the problem doesn't recur. Without it, teams waste cycles treating surface-level issues while the real cause persists.

The distinction between a symptom and a cause is critical. A symptom is what you observe: revenue is down, churn is up, bugs keep shipping. A cause is why it's happening: the sales team lacks qualified leads, onboarding fails to show value, code reviews skip edge cases. Hypothesis-driven problem solving depends on finding the true cause—otherwise you're testing the wrong hypotheses.

Two methods dominate root cause analysis: the 5 Whys and issue trees. The 5 Whys drills down a single causal chain until you hit bedrock. Issue trees split a problem into mutually exclusive, collectively exhaustive (MECE) branches and investigate each. Both work. The right choice depends on your problem's structure.

The 5 Whys is simple: state the problem, ask 'why?' and answer. Then ask 'why?' again, using the previous answer as input. Repeat until you reach a cause you can act on—usually within five iterations, though the number isn't sacred.

To run a 5 Whys, follow these steps: (1) Write down the specific problem you're investigating. (2) Ask why that problem occurs and write a clear, factual answer. (3) Take that answer and ask why again. (4) Continue until you reach an actionable root cause—something you can change. (5) Verify the chain by reading it backwards: 'Because X, therefore Y' should hold at each step.

The 5 Whys works best when the problem has a single dominant cause. It's fast—you can run one in ten minutes. But if the problem has multiple independent causes, the 5 Whys can mislead you by following just one branch while ignoring others.

An issue tree is a visual breakdown of a problem into its component parts. Each branch represents a distinct potential cause, and together the branches cover all possibilities—this is the MECE principle (mutually exclusive, collectively exhaustive). You then investigate each branch to find where the root cause actually lives.

MECE means no overlaps and no gaps. 'Customer churn increased' might split into: (a) customers are leaving during onboarding, (b) customers are leaving after onboarding but before value realization, (c) customers are leaving after value realization. These three phases are distinct (mutually exclusive) and cover the entire customer journey (collectively exhaustive).

Issue trees take more setup time than the 5 Whys, but they prevent you from missing causes. When you're unsure whether the problem has one root cause or several, or when the stakes are high enough to warrant thoroughness, an issue tree is the right tool. For more on building them, see how to turn an issue tree into a workplan.

Use the 5 Whys when the problem is narrow, the cause is likely singular, and you need a fast answer. A production server crashed—why? A specific customer complaint—why did it happen? These are good 5 Whys problems. The method excels when speed matters more than completeness.

Use an issue tree when the problem is broad, could have multiple independent causes, or when acting on the wrong cause would be costly. 'Why did Q3 revenue miss target?' almost certainly has multiple causes—pricing, volume, mix, churn—and needs an issue tree to diagnose properly. So does any problem where you're allocating significant resources to the fix.

A practical test: if you can imagine a simple chain of causation, try the 5 Whys first. If you immediately think 'it could be this OR that,' build an issue tree. You can also start with the 5 Whys and escalate to an issue tree if you discover the problem is more complex than expected.

Consider a SaaS company whose monthly churn rose from 3% to 5%—a 67% increase that will significantly impact annual revenue. Let's apply both methods.

5 Whys approach: Why did churn rise? Because more customers canceled in their first 90 days. Why? Because they didn't reach their activation milestone. Why? Because the onboarding emails had low open rates. Why? Because they were sent at the wrong time of day for our customer base. Why? Because we used a default send time instead of localizing to customer time zones. Root cause: email timing. Fix: localize send times. This chain found one cause, but is it the only one?

Issue tree approach: Churn increase splits into (a) onboarding-stage churn (0–90 days) and (b) post-onboarding churn (90+ days). Data shows onboarding churn rose from 4% to 7% (contributing +1.5pp to overall churn), while post-onboarding churn rose from 2.5% to 3.5% (contributing +0.5pp). Onboarding churn decomposes further: (a1) customers who never logged in after signup (+0.8pp), (a2) customers who logged in but didn't complete setup (+0.5pp), (a3) customers who completed setup but didn't activate (+0.2pp). Post-onboarding churn decomposes into: (b1) price-sensitive customers (+0.3pp) and (b2) customers who found alternatives (+0.2pp). Now you see the full picture: email timing (part of a1) is real, but the biggest driver is customers who never logged in at all—a different problem requiring a different fix.

The issue tree revealed that email timing is only part of the story. The largest opportunity is customers who never logged in, which might stem from signup friction, unclear value proposition, or lead quality. A decision matrix can help prioritize which causes to address first based on impact and effort.

Why is it called the '5 Whys' if the number isn't always five? The name comes from Toyota's production system, where five iterations typically reached bedrock. In practice, you might need three or seven—the point is to keep asking until you hit a cause you can change. Stop when further 'whys' yield circular answers or factors outside your control.

Can I combine the 5 Whys with an issue tree? Yes, and it's often effective. Use the issue tree to identify the main branches, then run a 5 Whys drill-down on the most promising branch. This combines the breadth of an issue tree with the depth of the 5 Whys.

How do I know if I've found the real root cause? A true root cause has two properties: (1) fixing it would prevent the problem from recurring, and (2) it's within your power to fix. If your 'root cause' is 'the economy is bad,' you haven't gone deep enough—ask why the economy affects you more than competitors.

What tools can help with root cause analysis? Any tool that lets you structure thinking visually helps: whiteboards, diagramming apps, or specialized problem-solving workspaces. Razn is a workspace for building issue trees and answer-first documents; use it when a problem has several possible causes and you need to split them MECE and test them systematically.

Start by defining the problem precisely—vague problems yield vague causes. Decide whether the problem likely has one cause (use 5 Whys) or multiple (use an issue tree). Gather data to validate each step of your chain or each branch of your tree. Quantify where possible so you can prioritize. Verify your root cause by checking whether fixing it would actually prevent recurrence.

Root cause analysis is a skill that improves with practice. The next time something goes wrong—a missed target, a customer complaint, a process failure—resist the urge to jump to solutions. Spend ten minutes finding the real cause first. The fix will be more effective, and you'll stop solving the same problem twice.