Free tool · no signup · nothing leaves your browser
Find the Root Cause of Any Problem
Ask “Why?” five times to dig beneath symptoms and uncover the real issue. Based on the Toyota Production System — used by Lean and Six Sigma teams worldwide.
Step-by-step guidedNo data collectedExport as PNGWorks offline
Describe your problem
Start with a specific, observable symptom. What is happening? When? How often? What is the impact?
How to write a good problem statement?
A good problem statement is the foundation of the entire analysis. If you define it poorly, the whole causal chain will go in the wrong direction.
Try to include:
- What exactly is happening (observable symptom)
- When it started or when it occurs
- Where — in which process, product, or team
- How often — one-time, recurring, constant
- What is the impact — on customers, revenue, team
Good examples:
- "Since March, customer support response time has increased from 2h to 8h."
- "In the last quarter, 15% of orders are shipped with a delay exceeding 48h."
- "Bounce rate on the pricing page jumped to 78% after the latest redesign."
Avoid: "We have a quality problem" (too vague), "John doesn't do his job" (blame), "We need to hire more people" (solution).
Why does this problem occur?
How to answer this step?
Your causal chain
From symptom to root cause.
Related resources
How to implement corrective actions?
The causal chain is only half the battle. Now you need to plan concrete actions.
- Define the action — what exactly needs to change in the process, system, or tool?
- Assign an owner — who is responsible for implementation?
- Set a deadline — when should the change be ready?
- Define a success metric — how will you know it worked?
- Plan verification — check after 2-4 weeks whether the problem has disappeared.
Remember: the corrective action should eliminate the root cause, not the symptom. If your action addresses the symptom — go back to the analysis.
What is the 5 Whys root cause analysis method?
The 5 Whys is a root cause analysis (RCA) technique developed by Sakichi Toyoda, founder of Toyota Industries. It became a cornerstone of the Toyota Production System (TPS) and Lean Manufacturing philosophy. Today it is used worldwide by Lean Six Sigma practitioners, Agile coaches, quality engineers, and product managers to drill down from visible symptoms to systemic root causes.
How to do a 5 Whys analysis step by step
When a problem arises, you repeatedly ask "why?" to move from a visible symptom to a hidden root cause. Each answer becomes the basis for the next question. Start by defining a specific, observable problem. Then ask "why does this happen?" and write down the direct cause. Repeat the process for each answer until you reach a systemic cause that can be eliminated through a lasting process change. The entire analysis typically takes 15 to 30 minutes.
When to use the 5 Whys method
The method works best for operational problems with a fairly linear causal chain: equipment failures, process delays, quality defects, customer complaints, IT incidents, conversion drops, and recurring issues. It is commonly applied in manufacturing, software development, healthcare, project management, and continuous improvement initiatives.
5 Whys examples
A classic example from Toyota: "The machine stopped" → Why? "The fuse blew due to overload" → Why? "The bearing was not lubricated" → Why? "The lubrication pump was not working" → Why? "The pump shaft was worn" → Why? "There was no preventive maintenance schedule." Root cause: missing preventive maintenance process.
5 Whys vs. Fishbone (Ishikawa) diagram
The 5 Whys follows one causal path in depth, while a Fishbone diagram maps many potential causes across categories (people, process, tools, materials, environment) simultaneously. Teams often use them together: the Fishbone to brainstorm candidate causes, then 5 Whys to investigate the most promising branches in depth.
Frequently asked questions
Do I always have to ask exactly 5 questions?
No. The number 5 is a guideline, not a hard rule. The root cause may reveal itself after 3 questions, or it might take 7 or more. The key is reaching a systemic cause that you can address with a concrete action.
How do I tell a symptom from a cause?
A symptom is something you observe — e.g. "customers are leaving," "the server keeps crashing." A cause answers "why is this happening?" Simple test: if you eliminate this cause, will the problem disappear? If not — dig deeper, it's still a symptom.
Why shouldn't I point to people as the cause?
Blaming individuals ends the analysis too early and leads to ineffective solutions (e.g. "retrain John"). Instead of "John forgot to send the report," ask: "why does the process allow someone to forget?" Maybe there's no automated reminder, checklist, or system in place.
Can I run the analysis alone?
Yes, but group workshops (3-5 people close to the process) yield better results. Different perspectives help avoid blind spots and biases. You can use this tool both for individual analysis and for leading a team workshop on screen.
What if one "why" has multiple answers?
This is common! In that case, pick the cause with the greatest impact on the problem. You can also run a separate 5 Whys analysis for each branch. For complex problems with many causes, consider using a fishbone (Ishikawa) diagram.
How do I know I've reached the root cause?
A root cause has several characteristics: (1) it concerns a process or system, not a person, (2) it's specific and verifiable, (3) eliminating it should prevent the problem from recurring, (4) asking another "why?" leads to answers beyond your control or too generic. If your answer is "that's just how physics works" — step back one level.
How is 5 Whys different from an Ishikawa diagram?
5 Whys follows a single causal path in depth — from symptom to root. An Ishikawa (fishbone) diagram maps many potential causes simultaneously across categories (people, process, tools, materials, environment). They're often used together: Ishikawa to identify candidates, then 5 Whys to investigate the most important branches.
Where is the 5 Whys method used?
Anywhere recurring problems appear: manufacturing (Lean, Six Sigma), IT (incident postmortems, Agile retrospectives), customer service (complaint analysis), logistics (delays), marketing (conversion drops), HR (employee turnover), and even in personal life.
What are the most common mistakes in a 5 Whys analysis?
Top pitfalls: (1) too vague a problem description at the start, (2) blaming people instead of examining the process, (3) stopping too early at symptoms, (4) skipping several levels at once, (5) proposing solutions instead of searching for causes, (6) not verifying whether the found cause actually explains the problem.
Does 5 Whys work for strategic problems?
The method works best for operational problems with a fairly linear causal chain. For complex strategic issues (e.g. "why are we losing market share"), the chain quickly branches out and 5 Whys may be too simplistic. In those cases, consider fault tree analysis, causal loop diagrams, or systems thinking.
How do I get the team engaged in the analysis?
Run a workshop: gather 3-5 people who know the process from the inside. Appoint a facilitator who asks questions and enforces the rules. Write answers on a whiteboard. Give everyone a voice — the most valuable insights often come from frontline workers. At the end, agree on a corrective action and assign an owner.
Does this tool store my data?
No. Everything happens in your browser — no data is sent to any server. You can download a screenshot of your results, but the tool itself does not store any information after you close the page.
Related resources
Fourteen in-depth articles on the 5 Whys method — industry-specific guides, facilitation technique, common mistakes, and the Toyota origin.