5 Key Takeaways
- A recurring problem is evidence that the real cause was never fixed, only the symptom was.
- The 5 Whys works by repeatedly asking why until you reach a process or system failure, not a person or a one-off event.
- Five is a guide, not a rule. Stop when you reach a cause you can actually act on.
- The method loses its value on complex problems with several causes happening at once.
- You know you’ve found the root cause when fixing it stops the problem recurring, not when the questioning runs out.
Summary
A business problem and its root cause are rarely the same thing. The problem is what you can see. The root cause is what allowed it to happen. The 5 Whys is a simple technique, developed inside Toyota’s manufacturing operations, that helps business owners move past the obvious explanation by repeatedly asking why until they reach a cause they can actually fix. It works well on single-chain operational problems. It struggles when several factors are contributing at once. The real test is whether the fix stops the problem coming back, not whether you asked exactly five questions.
Introduction
Most business owners are good at fixing what’s in front of them.
A supplier delivers late, so we chase the order. A customer complains, so we apologise and sort it. A project runs over budget, so we tighten the next quote.
Each fix feels reasonable at the time.
Then it happens again.
Not always in exactly the same way. The late delivery becomes a wrong delivery. The complaint moves to a different department. The over-budget project turns into a missed deadline instead.
On the surface these look like separate incidents.
Underneath, they’re often the same failure showing up in a new disguise.
A problem that keeps returning is telling us something specific. We fixed the symptom, not the cause. And until the cause is addressed, the business keeps spending time, money and management attention on the same issue.
This is where root cause analysis becomes useful, and specifically a simple version of it called the 5 Whys. It costs nothing. It needs no software. It can be run in one team conversation.
What is the difference between a business problem and its root cause?
A problem is the symptom, the thing we can see. A root cause is the process, system or decision failure that allowed it to happen, and that will keep causing it until something changes.
Both look identical in the moment. Both involve action. Both make the immediate issue go away.
The difference only shows up over time.
Take a late client delivery. The symptom-level response is to apologise, expedite the order and update the customer. That’s necessary. It isn’t a solution. If the real cause is that nobody owns stock checks before a job is confirmed, the next delivery will be late too, possibly for a different customer.
The business hasn’t got any more reliable. It’s just had another version of the same problem.
This is why recurring issues deserve more attention than isolated ones. A one-off mistake might genuinely be a one-off. A problem that keeps returning, in slightly different forms, is almost always a sign that something structural hasn’t been fixed. This is the same thinking behind separating symptoms from root causes at a whole-business level, rather than just at the level of a single incident.
Why does this matter commercially?
Every repeat occurrence carries a cost:
- Owner and team time spent firefighting instead of planning
- Customer trust eroded a little further each time
- The same conversation happening again, often with more frustration than the last
The discipline of root cause analysis is built around this exact distinction: finding the underlying cause of a problem rather than treating its symptoms. That’s the useful question to ask about any recurring problem: if I fix what’s in front of me right now, will this still happen in three months? If yes, we’re still looking at a symptom rather than the underlying cause..
How do SMEs use the 5 Whys to investigate recurring problems?
The 5 Whys traces a problem back to its real cause by asking why it happened, repeatedly, using each answer to prompt the next question, until we reach something rooted in a process or system rather than a person or a one-off event.
Sakichi Toyoda originated the technique. It was later embedded into the Toyota Production System, and is widely described in quality-management literature as a foundation of Toyota’s approach to problem-solving. It has since spread well beyond manufacturing, into healthcare, logistics and professional services, as a recognised quality-management technique that needs no specialist training to run.
The process:
- State the problem clearly and specifically. Not “deliveries are a mess,” but “the order for [customer] shipped two days late on Tuesday.”
- Ask why it happened, and answer factually.
- Take that answer and ask why again.
- Keep going until the answer points to something the business controls.
- Stop when you reach a cause you can act on, and agree what changes.
A short worked example:
- Problem: A client order shipped two days late.
- Why? The item wasn’t in stock when picked.
- Why? The stock system showed it as available.
- Why? Stock levels hadn’t been updated after the previous order.
- Why? Updating stock after dispatch isn’t part of anyone’s defined role.
- Why? There’s no formal handover step between the warehouse and stock records.
The first answer looks like the whole story. A business that stops there chases this one order and moves on. By the fifth question, the real issue has surfaced: a missing handover step, not a warehouse mistake. Fix that, and the failure stops recurring across other orders too.
Two things matter in how the questioning runs:
- Focus on the process, not the person. Blaming an individual rarely produces a fix that survives them being distracted or leaving.
- Five is a guide, not a rule. Some problems resolve in three questions. Others need seven or eight. What matters is reaching an actionable cause, not hitting a number.
It’s worth being clear about where this method runs out of road. The 5 Whys works well on problems with one dominant causal chain, a missed delivery, a recurring quality issue, a specific complaint. It’s less reliable on complex problems with several causes happening at once. A major service failure involving your team, a supplier and a system outage together isn’t a five-whys problem. That needs a broader look at several causes in parallel, and often benefits from specialist implementation through the Expert Partner Network where the fix sits outside internal capability.
How do you know whether you have found the real cause before deciding what to fix?
We’ve reached the real cause when the answer points to something the business controls, and fixing it would prevent the problem recurring in a different form, not just stop today’s instance.
Two checks help here.
Check ownership. If the final answer in the chain is “someone made a mistake” or “the supplier let us down,” we haven’t reached the root cause. We’ve reached a symptom described differently. People make mistakes. Suppliers occasionally underperform. A resilient process accounts for that rather than depending on nobody ever slipping up.
Check recurrence. Before implementing a fix, ask: if this exact cause were removed, could the problem still happen in a different form? If yes, stop one layer too early and keep going. In the delivery example, telling the warehouse team to “be more careful” wouldn’t have prevented the next occurrence. A formal handover step does.
Not every chain that reaches five questions has genuinely reached the root cause. Equally, a chain that stops at three isn’t automatically shallow. The test isn’t the count. It’s whether implementing the answer actually changes the pattern going forward.
If two people looking at the same problem arrive at different final causes, that’s usually a sign the issue has more than one contributing factor and deserves a broader look, rather than forcing a single chain to explain everything.
An outside perspective genuinely helps here. It’s easy for a session to stall on the fourth question because the honest answer implicates a decision the owner made, or because the group settles for a comfortable answer rather than an accurate one. A facilitator without a stake in the answer, whether a colleague from a different part of the business or, for CH4B members, a Strategic Business Partner working through priorities with a CH4B member, keeps the conversation focused on process rather than blame. This is the same reasoning behind when a recurring problem needs outside facilitation rather than staying entirely internal.
The same instinct sits behind the Business Growth Scorecard at a whole-business level: separating what’s visible from what’s actually driving it, so effort goes into the priority that genuinely moves the business forward.
Conclusion
A symptom fixed is a problem postponed. A root cause fixed is a problem solved.
The practical priority isn’t a new system or a new tool. It’s picking one problem in your business that keeps recurring, running the questioning properly with whoever’s closest to it, and testing the answer against one thing: would this fix actually stop it happening again, or just make today’s version go away?
If the answer holds up, you’ve found something worth acting on. If it doesn’t, keep asking why. For a broader look at where recurring pressure is coming from in the first place, our guide to diagnosing what’s really blocking growth and our further diagnostic tools and guides are useful next steps.
FAQs
Does the 5 Whys always take exactly five questions?
No. Five is a guide, not a rule. Some problems reach an actionable cause after three questions. Others need more. The right number is whatever it takes to reach a cause you can act on.
Can the 5 Whys be used when several people or departments are involved?
Yes, with careful facilitation. Have one person lead the questioning and keep it focused on process rather than individuals, since a group discussion can easily drift towards blame.
What if two people give different answers to the same why?
That usually signals more than one contributing factor. A broader tool that maps several causes at once, such as a fishbone diagram, is likely more useful than forcing a single chain to cover everything.
Is the 5 Whys a substitute for reviewing overall business performance?
No. It’s built for a specific, recurring incident. Understanding which parts of the whole business need attention first is a broader exercise, closer to what the Business Growth Scorecard is built for.
How do we stop a session turning into blame?
Keep every question framed around the process: what allowed this to happen, not who caused it. If an answer names a person, ask one more why to find what let that happen in the first place.
