The 5 whys: get from the symptom to a cause you can fix
Run this method in IdeaHone
Creates a space with the entities and scoring criteria of this method, ready for your next session.
Customers cancel in the first month. The obvious fix is a discount, a reminder email, a better welcome screen. Each one treats the symptom, and a month later the numbers look the same. The 5 whys is the oldest tool for getting underneath: ask why the problem happens, then ask why about the answer, and keep going until you reach something the team can change. It comes from Toyota, where Sakichi Toyoda and later Taiichi Ohno made it a habit on the factory floor.
How it works
You start with the problem as it shows itself, the symptom, not your guess at the cause. You ask why it happens and write one answer. Then you ask why about that answer, not about the original problem. Each answer becomes the next problem. Five is a rule of thumb, not a target: sometimes the cause is three levels down, sometimes seven.
A short example:
- Customers cancel in the first month. Why? They never finish the setup.
- Why? The setup asks for data they do not have at hand.
- Why? The import needs an administrator, and the person who signed up is rarely one.
- Why? The import was built for the first enterprise customer, who had an IT team.
The fourth answer is something the team can change: let any member import, and ask for the administrator only for the steps that need one. A discount would never have found it.
Running it as a team
- Write the problem as a symptom. "Customers cancel in the first month", not "our onboarding is bad". A cause in the problem statement ends the search before it starts.
- Ask why and write one answer per line. Use facts where you have them. When the room disagrees, the disagreement is information: write both answers.
- Follow each branch separately. Two answers to one why are two chains. Do not merge them into one vague sentence; ask why down each branch.
- Stop at a cause you can act on. Stop when the answer is something the team can change, or when it is outside your control (the weather, a law). Going further past that point only gets more abstract.
- Mark the root causes. One chain may end in one root cause, a branched chain in two or three.
- Give each root cause one action and an owner. The action changes the cause, not the symptom. Write when you will look at the problem again to see if it moved.
If you start from a Fishbone diagram, take one cause from the fish and use it as the problem. The Fishbone spreads the search wide, the 5 whys takes one cause deep.
Where the 5 whys goes wrong
- The chain ends at a person. "Why? Because Anna forgot." Ask why once more: why could one person forgetting cause the failure? The answer is almost always a process, and processes can be fixed without blame.
- One chain for a problem with several causes. Real problems rarely have one cause. When two answers are both true, follow both. The method allows branches; a forced single chain hides half the picture.
- Guesses presented as facts. An answer nobody can check is a hypothesis. Mark it as such, and check it before acting on it, for example with an assumption map.
- Stopping at the first comfortable answer. "Why? Because we lack resources" is where many chains stop, because nobody wants to ask the next question. Ask it.
The 5 whys works for problems with a chain of causes you can trace. For problems where many factors interact, such as culture, market shifts or several teams pulling in different directions, it oversimplifies. Use it as a first look there, not as the analysis.
Run the workshop. IdeaHone keeps the record.
While you facilitate, IdeaHone turns what is said into ideas, questions and decisions on a shared board, with who said it. Nobody writes the minutes afterwards.
What is the 5 whys method?
A root cause technique from the Toyota Production System: you ask why a problem happens, then why about the answer, and repeat until you reach a cause the team can act on, usually after about five steps.
Do you always have to ask why five times?
No. Five is a rule of thumb. Stop when the answer is something you can change or something outside your control; that can be after three steps or after seven.
What if there is more than one answer to a why?
Write both and follow each one separately. Each answer starts its own chain, and a problem can end with two or three root causes.
How is the 5 whys related to the Fishbone diagram?
The Fishbone (Ishikawa) diagram collects possible causes broadly, sorted into categories. The 5 whys follows one cause in depth. Teams often use the Fishbone first and then run the 5 whys on its most likely causes.
