5 Whys Examples: 6 Worked Root Cause Analyses You Can Apply Today

The 5 Whys technique is one of the fastest ways to move from a visible problem to its root cause -- but most 5 whys examples online stop at vague answers like "lack of training" or "communication breakdown" without showing how to push past those dead ends to find something you can actually fix.

A useful 5 Whys analysis, as ASQ's quality methodology resources describe, has three properties: each answer is specific and verifiable, the final root cause is systemic rather than individual, and the corrective action prevents recurrence rather than patching the symptom. The difference between a 5 Whys that changes nothing and one that eliminates a class of failures comes down to discipline at every level of questioning.

After applying the 5 Whys across 60+ transformation, operational improvement, and incident review engagements, we have found that the technique works best for problems with a single dominant causal chain and fails predictably when teams accept vague answers or skip data verification. This guide walks through six worked examples spanning software, customer experience, manufacturing, project management, sales, and safety -- then covers methodology, comparison to other root cause tools, and the mistakes that derail most analyses. For the broader framework context, see our Strategic Frameworks Guide.

How the 5 Whys Technique Works#

Toyota engineer Taiichi Ohno developed the 5 Whys as part of the Toyota Production System in the 1950s, as documented in his book Toyota Production System: Beyond Large-Scale Production. The method is deliberately simple: state the problem, then ask "why did this happen?" repeatedly until you reach a root cause that is actionable and systemic.

The process:

1. Define the problem in specific, measurable terms (not "things went wrong" but "deployment to production failed at 2:14 AM on January 15th")
2. Ask why the problem occurred. Write down the answer
3. Ask why that answer is true. Write down the next answer
4. Repeat until you reach a cause you can address with a systemic fix
5. Verify each answer with data, not assumptions
6. Define corrective action that prevents recurrence

The number five is a guideline. Some chains resolve in three levels; others need seven. The stopping rule is: can you take a concrete action at this level that would prevent the problem from recurring? If yes, you have found your root cause.

5 Whys Example 1: Software Deployment Failure#

Problem: A production deployment caused 47 minutes of downtime for 12,000 users on January 15th.

Root cause: No periodic review process for database operational runbooks as system scale changes.

Corrective action: Implement quarterly runbook reviews triggered by data volume thresholds (10M, 50M, 100M rows), and add a pre-deployment check that flags migrations touching tables above 5M rows for manual review.

5 Whys Example 2: Customer Complaint Spike#

Problem: Customer complaints increased 340% in the first two weeks of March compared to February.

Root cause: The billing batch process lacks a post-run reconciliation check that verifies all accounts were processed.

Corrective action: Add a reconciliation step that compares the count and IDs of processed accounts against the master list, with automatic alerting when the two do not match. Apply retroactive corrections to the 2,200 affected accounts.

5 Whys Example 3: Manufacturing Defect#

Problem: A bearing assembly line produced 1,400 defective units (3.2% defect rate vs. 0.5% target) during the week of February 10th.

Root cause: Maintenance alerts are assigned to individuals rather than role-based queues, creating single points of failure when personnel are unavailable.

Corrective action: Migrate maintenance scheduling alerts to role-based queues with 24-hour escalation to a backup if the primary assignee does not acknowledge. Add automatic machine lockout when a critical consumable exceeds 110% of its replacement interval.

5 Whys Example 4: Missed Project Deadline#

Problem: A client deliverable due April 30th was delivered on May 18th, 18 days late.

Root cause: The project kickoff checklist does not differentiate between engagement types that require methodology alignment with client teams and those that do not.

Corrective action: Add an engagement classification step to the kickoff process. For engagements involving financial modeling, forecasting, or integration with client systems, require a dedicated methodology alignment session with the relevant client team before work begins.

5 Whys Example 5: Declining Sales#

Problem: Q1 sales of the enterprise plan declined 22% year-over-year despite a 15% increase in qualified leads.

Root cause: The product prioritization model underweights competitive intelligence from the sales team relative to feature requests from existing customers.

Corrective action: Revise the prioritization scoring model to include a competitive threat multiplier based on win/loss data. Reactivate the self-service trial project with a target launch within 90 days. Establish a monthly feedback loop between sales and product using structured win/loss analysis.

5 Whys Example 6: Employee Safety Incident#

Problem: A warehouse worker sustained a hand injury from a conveyor belt mechanism on March 8th.

Root cause: The facility modification approval process does not include a mandatory safety controls review when equipment layouts change.

Corrective action: Add a safety controls review as a mandatory gate in the facility modification approval process. Install additional e-stops within 3 meters of all identified jam-prone sections. Conduct a retroactive safety review of all line extensions completed in the past 24 months.

When to Stop Asking Why#

There is no magic number. Stop when you reach an answer that meets all three criteria:

1. Actionable: You can design a specific fix for this cause
2. Systemic: The fix addresses a process, system, or policy gap -- not an individual's mistake
3. Within your control: You have the authority or influence to implement the change

If your final answer is "human error" or "bad communication," you have not gone deep enough. Those are symptoms. The root cause is whatever systemic gap allowed human error to propagate unchecked.

Handling Branching: When One Why Has Multiple Answers#

Sometimes a "why" has two or more valid answers. When this happens:

1. Document both branches. Write each answer as a separate chain
2. Follow each chain independently to its own root cause
3. Prioritize by impact. If one branch explains 80% of the problem and the other explains 20%, address the dominant chain first
4. Know when to switch tools. If you find more than three independent branches at a single level, the problem is multi-causal and a fishbone diagram or fault tree analysis will organize the complexity better than parallel 5 Whys chains

Validating Your Answers#

Each answer in the chain should pass a verification test:

If an answer fails any check, rewrite it before proceeding. Garbage in at level 2 means garbage out at level 5.

5 Whys vs Fishbone Diagram vs Fault Tree Analysis#

Choosing the right root cause analysis tool depends on problem complexity, available time, and how many independent causes you expect.

When to use each:

• 5 Whys: An incident happened, you need to find the root cause quickly, and the problem likely has one dominant causal chain. Use for post-mortems, customer complaints, and process failures
• Fishbone diagram: A problem has multiple contributing factors and you need to brainstorm across categories (people, process, equipment, materials, environment, measurement). See our fishbone diagram examples for worked cases
• Fault tree analysis: The failure is safety-critical, high-cost, or regulatory, and you need to model combinations of causes with probabilities. Common in aerospace, nuclear, and pharmaceutical industries

For more on root cause analysis methodology, see our root cause analysis examples and downloadable Root Cause Analysis Template.

Common 5 Whys Mistakes#

Stopping too early. The most frequent failure. "The server crashed" is not a root cause -- it is a proximate cause. Push until you find the process or system gap that allowed the failure to happen.

Asking leading questions. "Why didn't the team follow the process?" presumes the team was at fault. Ask "Why did this outcome occur?" and let the evidence point to the cause.

Accepting vague answers. "Lack of communication" and "insufficient training" are not root causes. They are categories. Which specific communication failed? What specific knowledge was missing? Vague answers produce vague corrective actions.

Not verifying with data. Every answer in the chain should be confirmable. If you cannot point to a log, a record, a metric, or a direct observation, the answer is a hypothesis, not a finding. Treat it as such.

Blaming individuals instead of systems. "John forgot to run the check" is never the root cause. Why was the check dependent on John's memory? Where was the automated reminder, the checklist, the peer review? Systems fail; people operate within systems.

Skipping the corrective action. A 5 Whys analysis without a defined corrective action is just a story. Every completed chain should end with a specific, assigned, time-bound fix.

Building 5 Whys Into Your Process#

The 5 Whys works best as a routine practice, not a one-time exercise. Teams that run it consistently after incidents, missed targets, and customer escalations build a library of root causes that reveals systemic patterns over time. If the same category of root cause appears across three or more analyses -- for example, missing escalation paths or outdated runbooks -- that pattern itself becomes the problem to solve.

For visual presentation of root cause analyses in stakeholder reviews, the Root Cause Analysis Template provides a structured layout. For a broader toolkit of problem-solving and decision-making methods, see our Strategic Frameworks Guide and Decision Tree Examples.