There was a week a few years back where I started getting a steady stream of customer complaints about not being able to log in to a self-service portal I was responsible for. Passwords weren’t working. Accounts seemed locked. The support queue was filling up.

My first instinct, honestly, was to do what most of us do: throw a fix at the most obvious symptom. Maybe beef up the password reset flow, or add clearer error messages. Ship something, calm the noise, move on.

But I’d recently been reading Eric Ries’ The Lean Startup, and there was a chapter on a framework called the 5 Whys that lodged itself in my brain at exactly the right moment. I decided to actually use it. What I found surprised me, and the fix turned out to be nothing like what I’d originally assumed.

The problem with fixing the obvious thing

Here’s the uncomfortable truth most tech leaders already know but don’t always act on: the thing that’s visibly broken is rarely the actual problem. It’s the symptom. It’s what happens when something deeper goes wrong and eventually makes itself known at the surface.

We patch the symptom, ship it, and then three months later, the same issue is back wearing slightly different clothes. Or we fix one leak and discover two more.

The 5 Whys framework gives you a structured way to resist that instinct. Instead of asking “what do we fix?”, it asks you to slow down and ask “why is this happening?” repeatedly, until you’ve peeled back enough layers to find the real source.

A hundred years old, and still relevant

The technique was developed by Sakichi Toyoda, founder of Toyota, back in the 1930s as part of what would become the Toyota Production System. His insight was elegantly simple: “By repeating why five times, the nature of the problem as well as its solution becomes clear.”

It’s worth sitting with that for a moment. A manufacturing methodology from pre-war Japan is now being taught in every startup playbook, every agile retrospective guide, every incident management runbook in tech. The reason it has endured is that it works, and the core principle translates perfectly to software.

Eric Ries picked it up and brought it into the modern startup context in The Lean Startup. His framing is particularly useful for tech teams: the 5 Whys lets you connect technical problems to human and process causes, and make proportionate investments in prevention at every level of the chain. Crucially, it also removes the blame game. You’re not asking “who caused this?” You’re asking “what caused this?”

How I actually used it

Back to my login problem. Here’s how the 5 Whys played out:

Why can’t customers access their accounts? We were seeing a spike in password reset emails, which meant customers were struggling with their existing passwords.

Why were so many password resets being triggered? The reset attempts were failing. Not the logins themselves, but the reset process. Customers were requesting a reset link and then getting an “invalid token” error when they tried to use it.

Why were tokens coming back invalid? The password reset emails were arriving late. Sometimes 10-15 minutes after the customer had requested them.

Why were the emails slow? Because customers were clicking “Resend” multiple times while waiting. Impatiently, understandably. Each resend request was hitting the queue and piling up behind the original.

Why does that cause the token to be invalid? Here’s the kicker: every time a customer clicked Resend, our system generated a new token and invalidated the previous one. So by the time that first email finally arrived, its token was already dead. The customer clicked the link, got an error, and assumed something was broken. Which, to be fair, it was.

The actual fix had nothing to do with password reset UI, or error messaging, or login flows. It was a simple rate-limit on token refresh: if a customer clicks Resend more than twice within five minutes, we reuse the existing valid token instead of generating a new one. That was it. A small change deep in the backend, and the complaint volume dropped to nearly zero within days.

How to actually run a 5 Whys session

The mechanics are simple, but there are a few things that make the difference between a useful session and a frustrating one.

Start with a clear, specific problem statement. “The app is slow” is not a problem statement. “Password reset failure rate increased by 40% over the last two weeks” is a problem statement. The more precise you are upfront, the more useful the chain of whys becomes.

Ask why, not who. The moment you frame a why as a question about who caused it rather than what caused it, you’ve left root cause analysis and entered blame territory. Keep it systemic.

Follow the evidence, not your gut. Each “why” should be answered with something you can verify, not something you assume. If you don’t have data for a step, go get it before moving on.

Stop when you reach something actionable and addressable. You don’t always need exactly five iterations. Sometimes it’s three. Sometimes it’s six. The number is a guide, not a rule.

Involve the people closest to the work. The engineer who built the password reset flow will know things about token generation that no one else does. Bring them in. This is a collaborative exercise, not an interrogation.

The proportionate response principle

One of Ries’ key additions to the Toyota framing is the idea of proportionate investment. At each level of the why chain, you have an opportunity to make a small, targeted improvement. You don’t have to (and usually shouldn’t) try to solve everything at once.

In my case: we could have invested in better email delivery infrastructure (addressing step 3), or improved the UI to set better expectations about wait times (step 2), or added better error messaging for expired tokens (step 1). All of those would have been legitimate improvements. But the root cause fix, the token rate-limit, was the smallest change with the highest impact.

By repeating why five times, the nature of the problem as well as its solution becomes clear. — Sakichi Toyoda

That’s the goal: find the intervention point where a small, precise fix prevents the whole chain from occurring in the first place.

When your next problem shows up

And it will show up. That’s not pessimism, it’s just the nature of running complex systems with real users.

When it does, before you reach for the obvious solution, before you spin up a task force or schedule an emergency sprint, try asking why five times. Write it down. Each “why” on a new line. Be honest about what you actually know versus what you’re assuming.

You might be surprised how often the real problem isn’t what you think it is.

---

Eric Ries covers the 5 Whys in depth in The Lean Startup (Crown Business, 2011). The American Society for Quality has a good reference guide at asq.org/quality-resources/five-whys.