The Five Whys is a root cause analysis technique developed within the Toyota Production System and introduced by Sakichi Toyoda. It is disarmingly simple: ask 'why?' five times in succession, with each answer becoming the input for the next question. The process drills past the presenting symptom of a problem to its underlying cause, which is almost always different from the surface-level explanation and far more important to address. It is one of the fastest and most accessible tools for moving from problem description to problem understanding.
What It Is
The Five Whys technique involves taking a clearly stated problem and repeatedly asking why it occurs, using each answer to formulate the next why question. Five iterations is a rule of thumb: some problems require three, others require seven. The process ends when the team reaches a root cause that is actionable, meaning it is something that can actually be changed rather than an immutable fact of the world. The output is a causal chain from symptom to root cause that makes explicit the assumptions underlying the current approach to the problem.
How to Run It
State the problem clearly and concisely in a single sentence. Ask the team 'why does this happen?' and capture all plausible answers. For each answer, ask 'why?' again and repeat. Use a facilitator to keep the chain focused and to challenge answers that skip logical steps or jump to conclusions. Where multiple possible causes exist at any level, branch the chain to explore each one. After reaching the root cause or causes, discuss which are most tractable and most important to address. Use the causal chain to inform the problem framing and subsequent design work.
When to Use It
Five Whys is most valuable during problem framing and synthesis when the team needs to understand the causes of a pain point or failure before designing a response. It is also useful in retrospectives when a project has not gone as expected and the team needs to understand why. In service design, it is particularly effective for understanding why a specific touchpoint consistently fails, helping teams distinguish between user interface problems, process problems, and organisational problems.
Tips for Success
Avoid single-cause thinking. Real problems often have multiple contributing causes, and a Five Whys exercise that converges too quickly on one answer is probably missing important complexity. Challenge each answer with the question: 'Is this always true, or just sometimes?' Use the Five Whys alongside other synthesis tools rather than in isolation: it is a powerful complement to affinity diagrams and insight statements. Document the full causal chain, not just the final root cause, so that the reasoning is available for stakeholders to review and challenge.
