PRODUCTIVITYOngoing practice

Five Whys Root Cause Analysis

Ask 'why' five times to find the human problem behind every technical failure

Problem it solves

low productivity

Best for

People looking to apply Five Whys Root Cause Analysis in their work and life

Not ideal for

Those seeking quick fixes without sustained effort or reflection

Overview

Why this framework exists

The Five Whys is an adaptive problem-solving technique borrowed from the Toyota Production System and adapted for startups. When a problem occurs, you ask 'why' five times in succession, with each answer forming the basis of the next question. This process consistently reveals that the root cause of seemingly technical problems is a human or process failure, often related to inadequate training, unclear procedures, or missing safeguards.

The critical adaptation for startups is the principle of making proportional investments at each level of the analysis. Instead of choosing between a full-blown preventive system or doing nothing, Five Whys enables incremental investment. At each of the five levels, make a small corrective action proportional to the severity of the symptom. Over time, these small investments accumulate into robust processes that evolved organically from real problems rather than being designed theoretically.

Five Whys also serves as a natural speed regulator for startups. When a team moves too fast and causes quality problems, the resulting Five Whys analysis forces investment in prevention that temporarily slows development. As those preventive investments pay off, the team naturally speeds up again. This creates a self-correcting system that automatically finds the optimal pace of development without top-down dictation.

Core principles

5 total
  1. Apparent technical failures almost always trace back to human or process failures if you ask why enough times.
  2. Proportional investment at each level of root cause is more sustainable than binary all-or-nothing fixes.
  3. Solving problems at their root rather than their surface prevents the same failure from returning in a different costume.
  4. The pace of iteration self-regulates naturally when every quality failure triggers a small preventive investment.
  5. A culture that investigates failures honestly produces better processes than one that assigns blame and moves on.

Steps

5 steps
  1. Appoint a Five Whys Master
    Designate someone with sufficient authority and respect to facilitate Five Whys sessions. This person is responsible for keeping sessions focused, ensuring the right people are in the room, and preventing the process from devolving into blame.
  2. Gather Everyone Affected in the Room
    Every person connected to the problem must be present: whoever discovered it, whoever tried to fix it, whoever worked on the relevant subsystems, and any senior managers who were involved in escalation. Whoever is absent tends to become the target of blame.
  3. Ask 'Why' Five Times Starting from the Symptom
    Begin with the observable problem and ask why it occurred. Take the answer and ask why again. Repeat five times. Each level moves from symptoms toward root causes, typically progressing from technical issues to process gaps to training deficiencies.
  4. Make Proportional Investments at Each Level
    For each of the five answers, make a small corrective investment proportional to the problem. At the symptom level, this might be a quick fix. At the root cause level, it might be updating a training document or adding a checklist. Avoid over-investing: make the smallest change that addresses the problem.
  5. Start Small and Expand Organically
    Begin applying Five Whys to new problems as they arise rather than trying to fix all historical issues at once. Start with a narrow scope and a single team. As the team builds trust with the process, expand to adjacent teams and broader problem areas.

Examples

1 cases
IMVU's Organic Training Program

When a new version of IMVU's product disabled a customer feature, the Five Whys analysis traced the root cause through five levels: the feature broke because of a bad technical change, which happened because the engineer did not know about the dependency, because there was no checklist of critical dependencies, because no training program existed, because the company had never invested in formal onboarding. The proportional investment at each level was small but cumulative.

OutcomeOver time, repeated Five Whys sessions organically built a training program so effective that new engineers were productive on their first day. The program was never designed from the top down; it emerged naturally from the process of making proportional investments to prevent recurring problems. New hires even routinely made changes to production code on day one.

Common mistakes

3 traps
Turning Five Whys into Five Blames
The most common failure mode is using the analysis to assign blame to individuals rather than identifying systemic process failures. When someone makes a mistake, the question should be 'why was it so easy for this mistake to happen?' not 'who made this mistake?' The mantra should be: if a mistake happens, shame on us for making it so easy to make.
Starting with all your historical baggage
Teams are tempted to use Five Whys to fix every long-standing problem at once. This is overwhelming and leads to early abandonment. Start with new problems only. Historical issues will naturally surface through the analysis of new incidents.
Excluding key people from the session
When busy senior managers or key engineers skip Five Whys sessions, two things happen: the analysis is less accurate because institutional knowledge is missing, and the absent people become scapegoats. Everyone connected to the problem must participate.

Origin story

How this framework came to be

The Five Whys is an adaptive problem-solving technique borrowed from the Toyota Production System and adapted for startups. When a problem occurs, you ask 'why' five times in succession, with each answer forming the basis of the next question. This process consistently reveals that the root cause of seemingly technical problems is a human or process failure, often related to inadequate training, unclear procedures, or missing safeguards.

The critical adaptation for startups is the principle of

Source

Traced to primary
Source · BOOK
The Lean Startup
Eric Ries · 2011
Open source →

Related frameworks

Browse all Productivity →