When trying to understand why something happened, a common tool is the Five Whys. It's very simple - ask why something happened, and then keep on asking why, until you get the root reason.
- Why did the cat escape? The door was left open.
- Why was the door left open? Someone left in a hurry and didn't check it.
- Why didn't they check it? The door doesn't close properly, so checking it takes an extra step people skip.
- Why doesn't the door close properly? The latch is worn and doesn't catch unless you push it firmly.
- Why is the latch worn? It's over ten years old and has never been replaced.
Five questions in, and we've gone from 'the cat escaped' to 'the latch needs replacing' - a concrete, fixable root cause, rather than just telling people to 'be more careful', which never actually works for long.
Where it comes from
The technique was developed at Toyota by Sakichi Toyoda, and became a core part of the Toyota Production System. On a factory floor, it's tempting to fix the symptom you can see and move on. A machine jams, so you reset it and get back to work. The Five Whys forces you to keep going past that first, obvious answer until you reach something you can actually fix for good.
Symptoms vs root causes
The whole point of the technique is separating symptoms from root causes. A symptom is what you notice: the cat got out, the website went down, the deadline was missed. A root cause is the underlying condition that, left unaddressed, will keep producing that symptom again and again. It's easy to stop at the first or second why, because that answer already feels like an explanation. But 'the door was left open' is still just another symptom, one level down. Only by continuing to ask do you get somewhere near the actual cause.
Five is a guideline, not a rule
Don't take the number five too literally. Some problems reveal their root cause after three whys, others need seven or eight. The name just captures the general idea: keep asking until further whys stop revealing anything new and useful, and you've reached something you can genuinely act on.
Where a simple chain breaks down
The classic Five Whys assumes a single chain of cause and effect, one answer leading neatly to the next. In practice, real problems are rarely that tidy. A missed deadline might trace back to three separate causes at once: unclear requirements, an overloaded team, and a dependency that arrived late. Forcing that into one straight line either oversimplifies the problem, or tempts you to pick just one thread and ignore the rest.
This is where a concept map is valuable. Instead of a single chain, you can branch a 'why' into multiple answers where more than one cause applies, attach evidence or notes to any node, and keep the whole analysis visible at once rather than buried in a document. It also makes it much easier to bring a team into the process, since everyone can see the reasoning laid out and add their own branches where they think something's missing, rather than relying on one person's chain of questions.
Fundamentally, problem solving is about asking questions, which leads us to greater understanding.