The most expensive mistake in product development isn’t the wrong feature. It’s the right solution to the wrong problem.

You probably recognise it. A team spends weeks optimising a checkout flow: new copy, A/B tests, a redesigned button, a discount pop-up timed to the millisecond. Conversion barely moves. So they try again. A new variant. A new incentive. A new hypothesis. And somewhere in that cycle, the question of why it still isn’t working quietly stops being asked. Not because the team is lazy. But because the answer, if you followed the method all the way through, might point somewhere uncomfortable.

That’s what most explanations of the 5 Whys leave out: it isn’t a problem-solving method. It’s a confrontation with what an organisation would rather not know.

Every time a team stops at the third why, they haven’t run out of ideas. They’re protecting an assumption. Maybe it’s a decision made two years ago by someone who left the company long since. Maybe it’s a KPI that rewards the wrong behaviour. Whatever it is, the third why sits close enough to the answer to feel like progress, and far enough from the real one to leave the root cause intact.

Five times. No more.

You take a problem and ask “why”, not once, not twice, but five times in a row. Each answer becomes the next question. Toyota’s classic example is almost embarrassingly simple.

Why did the robot stop? A fuse blew. The circuit was overloaded. Why? The bearings seized because they weren’t sufficiently lubricated. Why? The oil pump wasn’t circulating enough oil. Why? The pump’s intake was clogged with metal shavings. Why? There was no filter on the pump.

The fix wasn’t replacing the fuse. It was installing a filter. Fuses are cheap. Clogged pumps keep coming back.

Closer to home: an e-commerce team sees 60% of users drop off on the payment page. First reflex: wrong button colour, unclear copy, confusing layout. But then, five times why.

Why are users dropping off? They don’t finish the form. Why? They stop when they’re asked to create an account. Why? Because creating an account is mandatory at that point. Why? Because marketing wants the data for retargeting. Why has nobody ever questioned this? Because it’s always been that way, and nobody saw it as a design decision.

The root cause isn’t a UX problem. It’s an assumption about who the product actually exists for. And that’s what makes it so hard to solve: it isn’t in the design, it’s in the structure of the organisation itself.

Then the most common objection, and it’s more interesting than it looks: “Different people asking the same five questions end up at different root causes.” True. And that’s exactly the point. If two people follow the same chain and arrive somewhere different, that divergence is the fifth why. It shows your team doesn’t yet share an understanding of the problem. That isn’t a failure of the method. That’s the method working.

The second objection is fair too: that the 5 Whys falls short on complex systemic problems. The method was designed for mechanical cause and effect. If the fifth why points at an organisational culture, or at a decision nobody owns any more, you need more than a chain of questions. But it still gets you further than “let’s try a different CTA.”

The limits of the method are real. But there’s an attitude that makes it powerful anyway, and that attitude is older than Toyota.

Go and see for yourself

In 1847, a Viennese physician saw something nobody wanted to see. Ignaz Semmelweis worked on a maternity ward where doctors performed autopsies in the morning and went on to deliveries afterwards. Deaths from puerperal fever there were dramatically higher than on the ward run by midwives. The difference was visible, measurable, and sitting in plain sight.

Semmelweis didn’t theorise from a meeting room. He went and looked. He compared wards, recorded deaths, spoke with nurses. His conclusion: doctors were carrying something on their hands out of the autopsy room. Washing hands with a chlorine solution would save lives. He was right. When the measure was introduced, mortality fell sharply.

The medical establishment rejected him anyway. Because his fifth why pointed straight at the doctors themselves. And that was an answer the institution would rather not reach.

Semmelweis did nothing other than what the best problem-solvers always do. He went to the place where the problem lived and looked at it directly. Toyota later gave that a name. Genchi Genbutsu: go and see for yourself. Don’t make decisions based on what someone two floors up thinks is happening. Go to the floor. Or, if you build digital products, spend a day sitting next to someone on the support desk. Not reading the tickets. Hearing the conversations. The exact words, the exact frustration, the exact moment someone gives up.

Jeff Bezos reportedly forwarded customer complaints to the team involved with a single character in the subject line: ?

That question mark was Genchi Genbutsu. Go and see what this person went through. Don’t summarise it. Don’t rationalise it. See it.

Why do we stop at the third why?

Semmelweis was rejected. The checkout team optimised the button. The pattern is the same.

We stop asking because the answer we have is comfortable enough. Not for lack of commitment. Not because the question is too hard. But because the next why might point somewhere that changes something we’d rather not change. The fifth why tends to implicate something or someone the current system depends on, and that feels like risk even when the evidence says otherwise.

The irony: the bigger the problem, the more likely it is that the fifth why leads somewhere uncomfortable. The problems that keep coming back are often the ones where the real cause was quietly found once, by someone who decided at the time that it was too complicated to raise.

You don’t stop at the third why because you’ve run out of questions. You stop because the next answer costs something.

That isn’t an accusation. It’s a diagnosis. And the 5 Whys is at its most valuable precisely at the moment you decide the diagnosis is worth making.

How you actually use it

There are two versions of the 5 Whys, and knowing which one to reach for makes a difference.

The solo version takes ten minutes, before a meeting. Write the problem at the top of a page. Ask why. Write the answer. Ask why again. Follow the chain as far as it goes. No template, no team, no facilitator. Just you, a problem, and the willingness to keep going past the answer that feels good.

This version is underrated. For design questions like why this interaction is confusing, why this pattern keeps failing, why the user keeps doing something you didn’t design, the solo version is often enough on its own. It won’t give you organisational change, but it stops you spending three weeks fixing the wrong layer.

The team version is more structured and more powerful for problems that cross departmental lines. Bring together the people closest to the problem. Not the people who manage it, but the people who watch it happen. Agree on a clear, unambiguous problem statement before anyone asks a first why. A facilitator keeps the group on one chain at a time; otherwise the conversation fragments into five parallel theories and you end up with a map of every possible cause instead of the actual one.

The team version reveals something the solo version can’t: the moment two people give a different answer to the same why. That gap is often exactly where the real work is. It’s the distance between what different parts of the organisation believe to be true about the same situation.

In practice, five is a suggestion. Some problems reveal themselves at three. Others need seven. The point is that you didn’t stop because the answer was convenient.

The question you can’t delegate

Ask AI why your checkout conversion is low. Within seconds you’ll get a well-structured list: mandatory account creation, too many form fields, an unclear CTA, unexpected shipping costs. All reasonable. All worth investigating.

And none of them the specific blind spot in your organisation that only you can see. The decision made in a boardroom three years ago. The KPI quietly rewarding the wrong behaviour. The assumption that was once true and became load-bearing before anyone noticed.

AI works from patterns. It gives you the answer that applies to most cases. The 5 Whys, followed honestly, gives you the answer that applies to your case. It’s the answer your organisation’s self-protection has kept out of view.

That isn’t an argument against AI. It’s an argument for knowing what you’re actually asking it.

The more interesting move: if you understand the 5 Whys as an attitude, a trained refusal to accept the comfortable answer, you can build that into how you work with AI. Not “give me the root cause.” But: “This is the answer I have. Now ask me why. Then ask me why again.” You stay at the wheel. AI becomes the assistant that runs your critical instinct at speed.

But why, actually? The question that silences the room doesn’t get easier when you can generate ten answers in three seconds. If anything it gets harder, because there are now ten plausible places to stop.

The next time you’re working on a problem and it feels like you already know what it is: ask yourself whether that’s the answer, or the answer you’d most like to find.

That question isn’t in your analytics. It isn’t something a tool asks on your behalf.

It’s the only question only you can ask. Five times. Or as often as it takes to be honest.