When to use it
Use Five Whys when a problem keeps recurring, when you're not sure whether you're solving the real issue or just a symptom, or when the team has jumped to a solution before properly diagnosing the cause.
It's particularly effective when you're in The Untangle — something is wrong but you can't quite name it.
How it works in The Studio
Here's how a session works with WAiDE:
Sample output
Here's what a Five Whys chain looks like in practice:
What you get
A clear statement of the root cause, and — where possible — a systemic or behavioural change that addresses it. Often reveals that the true problem is different from what you originally assumed.
Your downloadable report includes the full question chain, WAiDE's coaching observations, a recommended next step, and relevant Wade articles and programs.
Foundation
Developed by Sakichi Toyoda at Toyota Industries in the 1930s. Embedded in the Toyota Production System and widely taught at Harvard Business School. Used by Amazon, GE, McKinsey, and the NHS.
Why it works
The Five Whys works because most organisations are very good at addressing symptoms and very bad at addressing causes. A server goes down — the symptom is fixed, the server is restarted, the monitoring alert is cleared. Six months later, the same server goes down again. The Five Whys forces the question: what made the server unstable in the first place? What process allowed that condition to exist? What incentive or oversight gap meant nobody addressed it?
The technique was developed by Sakichi Toyoda and became a cornerstone of the Toyota Production System — the methodology behind modern lean manufacturing. Its power is in its simplicity. No special training required, no complex frameworks, just disciplined repetition of a single question until you reach something actionable.
The key discipline is resisting the urge to stop at people. "The engineer made a mistake" is never a root cause — it's the beginning of the real question: what system, process, or incentive structure allowed that mistake to have this impact? Root causes live in systems, not individuals.
When to go further than five: if at iteration five you're still describing what happened rather than why the conditions for it existed, keep going. Five is a guide, not a rule.
Frequently asked questions
Why five? What if I find the root cause in three iterations?
Five is a guideline, not a rule. If you've genuinely found a systemic root cause in three iterations, stop. If you're still describing symptoms at five, keep going. The number matters less than reaching a cause you can actually change — one that, if fixed, would prevent the problem from recurring.
What's the most common mistake people make with the Five Whys?
Blaming people instead of systems. 'Why did this fail? Because John made a mistake.' That's not a root cause — it's a symptom. The root cause is the system that allowed John's mistake to have that impact. Stay focused on process, structure, and incentive. People don't cause systemic problems; systems do.
Is Five Whys only useful for problems that have already happened?
Primarily yes — it's a retrospective tool for diagnosing existing failures. For prospective risk analysis (what might go wrong before it happens), use Pre-Mortem or Force Field Analysis instead. The Five Whys needs a real event to analyse.
Can I use Five Whys in a team setting?
Yes, and it's often more effective with a small group (3–5 people) who were involved in or affected by the problem. Different perspectives reach different root causes — someone in operations sees a different 'why' than someone in product. That divergence is valuable data.