5 Whys: Tracing Symptoms to Root Causes in Five Steps

5 Whys is the simplest root-cause analysis technique and often the most effective. You state the problem as a measurable symptom, then ask why it happened. You answer with evidence, then ask why again on that answer. You repeat until a systemic cause appears, typically by the fifth why.

Why it works

Surface fixes treat symptoms. A checkout drop gets a UI tweak. A cloud bill spike gets a budget alert. A stockout gets an emergency reorder. The symptom returns because the cause was never addressed. 5 Whys forces the team past the symptom to the layer where a single fix prevents the whole class of incident.

A real example

At Lorex Technology, checkout conversion rate optimisation dropped 18% over two weeks. The chain:

1. Why did conversion rate optimisation drop? The address step was added to checkout. 2. Why was the address step slow? It called the ERP for address validation. 3. Why was the ERP validation slow? The sync queue was backlogged. 4. Why was the queue backlogged? The batch job ran hourly, not in real time. 5. Why hourly? Legacy scheduling no one had revisited.

The root cause was a batch schedule, not the checkout UI. Moving the sync to real time recovered conversion rate optimisation without a frontend change.

Where to use it

5 Whys works whenever a metric has moved and the cause is unclear: checkout drops, cloud bill spikes, recurring defects, stockouts, and team overload. It is industry-agnostic and works equally well in building an ecommerce ecosystem, manufacturing, and SaaS.

The discipline

Each why must be answered with evidence, not speculation. "I think the queue is slow" is not an answer; "the queue depth metric shows 4,000 pending messages" is. Without evidence, 5 Whys becomes a guessing game that lands on whatever cause is most familiar, not the real one.

The record

Every 5 Whys analysis should produce a durable record: the symptom, the chain, the root cause, and the fix. This record becomes a knowledge base that turns each root-cause fix into a permanent reliability gain. The same incident class is never diagnosed twice.