Five Why5 Whys is a problem-analysis technique that seeks to identify the underlying causes of a problem by repeatedly asking, “Why did this happen?” The method became widely known through the Toyota Production System and is now used in manufacturing quality management, business process improvement, IT incident analysis, and service operations.
The basic procedure is simple. When a problem occurs, identify a possible reason and then ask why that reason occurred. By repeating this process, the analyst attempts to uncover conditions and mechanisms behind the initially observed problem.
However, asking “why” five times does not guarantee that the true cause will be discovered. 5 Whys is not a method that automatically identifies root causes. It is a thinking technique for developing and examining causal hypotheses.
Origins and Basic Principles
The origins of 5 Whys are associated with Sakichi Toyoda’s approach to problem-solving, and the technique was emphasized by Taiichi Ohno in the development of the Toyota Production System.
Ohno explained that simply correcting the immediate cause of a machine failure may not prevent the problem from recurring.
For example, if a machine stops because a fuse has blown, replacing the fuse restores operation. However, if the fuse blew because of an overload caused by insufficient lubrication of a bearing, replacing the fuse alone will not prevent another failure.
Further investigation may reveal a defective lubrication pump, followed by a deeper question about why that defect occurred.
This illustrates the difference between correcting an immediate malfunction and addressing the conditions that caused it.
The purpose of 5 Whys is to investigate these conditions and identify opportunities to prevent recurrence.
Although the method is called “5 Whys,” exactly five questions are not required. Some problems may be sufficiently understood after three questions, while others require substantially more investigation.
The Basic 5 Whys Procedure
1. Define the Problem Clearly
Begin by describing what happened.
Vague statements such as “Quality is poor,” “Customer service is slow,” or “Sales have declined” may refer to many different situations and possible causes.
Whenever possible, record the observed event, location, date, frequency, quantity, and deviation from normal conditions.
For example, instead of writing “Customer service is too slow,” define the problem as:
“During the current month, 20 customer inquiries received their first response more than 24 hours after submission, exceeding the company’s response-time target.”
These figures are hypothetical and are used only to illustrate the method.
It is also important to avoid including an assumed cause in the initial problem statement.
“Responses were delayed because employees were careless” introduces a causal explanation before it has been investigated.
2. Ask the First “Why?”
Consider the immediate causes that might explain the observed problem.
For example:
Why were the initial customer responses delayed?
A possible answer is:
“Because the inquiries were not assigned to responsible employees promptly.”
However, this answer is still a hypothesis.
The analyst must examine whether the assignment was actually delayed, using records such as ticket histories, timestamps, or system logs.
3. Continue Asking “Why?”
Next, ask why the assignment was delayed.
For example:
“Because the automatic routing system did not assign the inquiries correctly.”
Why did the routing system fail?
“Because the product name required for routing was missing.”
Why was the product name missing?
“Because the inquiry form did not require users to enter it.”
Why had the form not been updated?
“Because changes to the routing system had not been reflected in the form specifications.”
At each stage, it is essential to distinguish confirmed facts from assumptions.
A coherent sequence of answers is not necessarily a verified causal explanation.
4. Follow Multiple Causal Paths When Necessary
A question may have more than one plausible answer.
For example, delayed customer responses might result from slow assignment, but they could also result from excessive workload after assignment.
Selecting only one explanation may conceal other important contributing factors.
When several causes are plausible, create separate branches and investigate each one.
Although 5 Whys is often illustrated as a single chain, real problems frequently involve multiple causal pathways.
5. Verify the Proposed Causes
Repeated questioning does not establish that a cause has been identified correctly.
Suppose the analysis suggests that the inquiry form was incorrectly configured.
The analyst should examine the form specifications, change histories, actual submissions, and routing behavior.
It may also be useful to trace the proposed causal chain in the opposite direction:
“The product name was missing, which prevented automatic routing, which delayed assignment, which delayed the initial response.”
Does the available evidence support each relationship?
If not, the explanation must be revised.
6. Implement Corrective Actions and Check the Results
Once important causes have been sufficiently supported by evidence, develop corrective actions.
Possible actions might include making certain form fields mandatory, notifying staff when automatic routing fails, or monitoring inquiries that remain unassigned.
After implementation, examine whether the frequency of the original problem has decreased.
If the problem persists, reconsider the causal hypotheses and the effectiveness of the corrective actions.
Practical Example — Investigating Delayed Customer Responses
The following example illustrates a possible application of 5 Whys to delayed customer inquiries. It is hypothetical and does not describe a verified incident.
| Stage | Question | Hypothetical Answer |
|---|---|---|
| Why 1 | Why was the initial response delayed? | Assignment to a responsible employee was delayed |
| Why 2 | Why was assignment delayed? | Automatic routing did not function correctly |
| Why 3 | Why did automatic routing fail? | The required product name was missing |
| Why 4 | Why was the product name missing? | The inquiry form treated it as an optional field |
| Why 5 | Why was it optional? | The form specification was not updated when the routing system changed |
If supported by actual evidence, this analysis would suggest that correcting the inquiry form and routing process may be more effective than simply instructing employees to respond faster.
However, other contributing causes may exist.
Even correctly assigned inquiries may remain unanswered because employees are overloaded. Staffing levels during holidays or evenings may also be insufficient.
Therefore, this sequence alone does not demonstrate that the problem has been fully explained.
What Is a Root Cause?
The term root cause usually refers to an important underlying cause whose correction is expected to prevent or substantially reduce recurrence.
However, how far should a causal investigation proceed before a cause is considered fundamental?
Suppose an inquiry form was not updated because there was no formal procedure for checking the effects of system changes.
Why was such a procedure missing?
Perhaps responsibilities between development and operations teams were unclear.
Why were those responsibilities unclear?
The investigation might eventually reach organizational structures, management policies, or budget allocation.
Causal inquiry can continue almost indefinitely.
For practical purposes, a root cause is therefore better understood as a sufficiently important and actionable cause within the defined scope of the investigation, rather than an absolute starting point from which every event ultimately originates.
Nevertheless, analysts should not ignore major systemic causes merely because they are difficult to address.
The appropriate depth of investigation depends on the severity, recurrence, and consequences of the problem.
Strengths of 5 Whys
The first advantage of 5 Whys is its simplicity. It does not require specialized mathematical knowledge or software.
Second, it encourages analysts to distinguish visible symptoms from the conditions that produce them. This can help organizations move beyond temporary corrective measures.
Third, it makes causal hypotheses explicit. Participants can explain why a particular corrective action has been proposed and which suspected cause it is intended to address.
Fourth, it is compatible with direct observation and practical knowledge from employees who work with the affected process.
By examining what actually happens at the site of the problem, analysts may discover conditions that would be difficult to identify through abstract discussion alone.
Limitations — Repeatedly Asking “Why?” Does Not Guarantee the Truth
Despite its popularity, 5 Whys has several important limitations.
It Can Oversimplify Problems into a Single Causal Chain
Real-world problems often arise from combinations of multiple factors.
For example, product defects may involve material properties, equipment conditions, operating procedures, temperature, and process design.
These factors may interact with one another.
A single chain of five questions can obscure the broader causal structure, especially when the analyst follows only one selected explanation.
Results Depend on the Analyst’s Assumptions
Different analysts may reach different conclusions about the same problem.
A manager may focus on inadequate training, an operator may emphasize the complexity of the work procedure, and a software developer may identify limitations in the system interface.
These explanations are not necessarily mutually exclusive.
Each participant may recognize a different aspect of the problem.
The challenge is to examine the available evidence rather than accept whichever explanation is most familiar or convenient.
It Can Produce Plausible but Unsupported Stories
When people are repeatedly asked why something happened, they tend to construct explanations.
However, a logically coherent story is not necessarily a factual account.
For example, saying that an inspection was missed because an employee lacked motivation is an interpretation of someone’s psychological state, not necessarily an observed fact.
If such assumptions are accepted without verification, the analysis may produce a convincing narrative with little evidential support.
It Can Encourage Blaming Individuals
Some investigations stop at explanations such as “The employee was careless” or “The operator failed to follow the procedure.”
Yet human behavior may be influenced by workload, equipment design, unclear instructions, inadequate information, organizational pressure, or conflicting objectives.
When human error is identified, it is often necessary to investigate the conditions that made the error more likely.
It Does Not Scientifically Verify Causation
5 Whys is a questioning technique for generating causal explanations.
It is not a statistical or experimental method for demonstrating causal relationships.
When multiple interacting factors are involved, additional methods such as designed experiments, fault analysis, statistical modeling, or simulation may be required.
In a 2017 paper published in BMJ Quality & Safety, Alan J. Card criticized the widespread use of 5 Whys in healthcare safety investigations despite limited evidence of its effectiveness and warned against its tendency to focus on a single causal pathway.
The implication is not that 5 Whys should never be used.
Rather, developing an explanation and verifying that explanation are different activities.
Combining 5 Whys with Other Analytical Methods
5 Whys can be combined with other methods to address more complex problems.
| Method | Main Purpose | Relationship to 5 Whys |
|---|---|---|
| Fishbone Diagram (Ishikawa Diagram) | Identify a broad range of possible causes | Investigate individual branches in greater depth |
| Fault Tree Analysis (FTA) | Analyze combinations of conditions that can produce failures | Examine multiple causal pathways |
| Failure Mode and Effects Analysis (FMEA) | Identify failure modes and assess their effects and risks | Investigate causes of specific failures |
| Design of Experiments (DOE) | Test relationships between factors and outcomes | Verify causal hypotheses |
| Multivariate Analysis | Analyze relationships among multiple variables | Investigate patterns beyond a single causal chain |
| Systems Thinking | Examine interactions, feedback, and systemic structures | Expand the analysis to broader relationships |
For example, a team may first use a fishbone diagram to identify possible causes and then apply 5 Whys to investigate selected causes.
However, combining two qualitative techniques does not automatically establish causality.
Observations, measurements, and appropriate testing are still necessary.
5 Whys and Abductive Reasoning
From the perspective of logic, 5 Whys is closely related to abductive reasoning, or inference to a possible explanation.
When we observe a phenomenon and ask why it occurred, we are developing a hypothesis that could explain it.
For example:
“The automatic routing system failed.”
One possible explanation is:
“The required product name was missing.”
But other explanations may also exist, such as a server malfunction or an incorrect routing rule.
The answer generated by a “why” question is therefore not necessarily a deductive conclusion that must follow from the observed facts.
Several explanations may be compatible with the same observation.
The task is to compare alternative hypotheses and determine which are supported by evidence.
Understanding this distinction helps prevent the mistaken belief that asking “why” five times necessarily reveals the correct answer.
5 Whys in the AI Era — From Generating Explanations to Testing Causes
5 Whys is an attractive candidate for LLM-assisted analysis.
Given a written problem description, an LLM can propose possible causes and repeatedly generate follow-up questions.
However, this introduces a significant risk.
An LLM can produce a coherent causal narrative even when it has no access to the actual evidence surrounding an incident.
Simply asking an AI system to “perform a 5 Whys analysis” may therefore result in the generation of a plausible causal story rather than an investigation of actual causes.
A more useful approach is to define separate roles for AI-assisted hypothesis generation and evidence-based verification.
Generate Multiple Candidate Causes
Instead of producing a single answer to each question, AI can propose several possible causes.
For each candidate, it can identify what additional observations or records would be needed to evaluate the explanation.
Track Supporting Evidence
Each causal hypothesis can be associated with relevant evidence, such as system logs, inspection records, interviews, or measurements.
The system should clearly distinguish between observations and AI-generated assumptions.
Represent Causal Relationships as a Structure
Rather than limiting the analysis to a single sequence, a system can represent multiple causes and their relationships in a branching diagram or causal network.
Each relationship can be recorded as a hypothesis requiring verification.
Propose Methods of Verification
For each candidate cause, AI may suggest appropriate observations, comparisons, measurements, or experiments.
This moves the system beyond generating explanations toward supporting actual investigation.
Track Corrective Actions and Outcomes
Corrective actions can be linked to the causes they are intended to address.
After implementation, the results can be recorded and evaluated.
If the problem recurs, the original causal explanation can be reconsidered.
In this way, the traditional 5 Whys technique could evolve into a structured analytical process that manages hypotheses, evidence, causal relationships, corrective actions, and observed outcomes.
5 Whys in ThinkNavi
ThinkNavi presents 5 Whys as a foundational technique for investigating the causes of problems.
A possible implementation in ThinkNavi Free would provide a manual workspace for recording problem descriptions, successive “why” questions, candidate causes, supporting evidence, and corrective actions.
Support for multiple causal branches and the ability to trace explanations back to the original problem would also be useful.
An LLM-powered edition could extend these functions by generating alternative causal hypotheses, suggesting additional investigations, organizing causal relationships, identifying missing evidence or contradictions, and comparing corrective actions.
These are potential future capabilities, not descriptions of functions currently available.
The objective is not merely to digitize the traditional five-question procedure.
By connecting causal hypotheses with observations, records, and experimental results, the method could become part of a more comprehensive analytical environment.
The real value of 5 Whys is not asking “why” exactly five times. It is refusing to stop at the first convenient explanation and continuing to investigate the conditions underlying a problem.
Related Topics
- Find and Frame Problems
- Fishbone Diagram (Ishikawa Diagram)
- Abduction | Reasoning Toward Explanations
- Foundations of Logic — Concepts, Propositions, and Inference
- Critical Thinking | Examining Claims and Evidence
- Systems Thinking | Interdependence and Change Over Time
- Bayesian Networks | Reason with Conditional Probabilities
- Design Thinking | Exploring Problems Around People
- The KJ Method | Building Meaningful Structures from Fragmented Information
References and Further Reading
Alan J. Card, “The Problem with ‘5 Whys’,” BMJ Quality & Safety, 26(8), 2017, pp. 671–677.s repeatedly asks why an observed problem occurred, aiming to move beyond immediate symptoms. Despite its name, it is not a law that exactly five questions will reveal a single root cause.
Taiichi Ohno, Toyota Production System: Beyond Large-Scale Production, Productivity Press, 1988.
Lean Enterprise Institute — 5 Whys
Lean Enterprise Institute — How Many Whys Should I Ask?
American Society for Quality — Five Whys and Five Hows
Institute for Healthcare Improvement — 5 Whys: Finding the Root Cause
Start with something observable
“Customers are unhappy” is harder to examine than “Complaints about late deliveries increased during the last month.” As soon as an answer becomes speculative, gather records or check what happened in practice.
Preserve branching causes
Following one chain can hide interacting factors such as equipment, staffing, demand, and organizational rules. Keep multiple candidate explanations in view and consider a systems-oriented diagram when feedback matters.
Do not assume the last answer is the root cause
Before labeling the final statement a fundamental cause, ask whether the proposed intervention changes outcomes and whether the same failure could recur under different conditions. Repeated questions cannot replace investigation.