Five Whys Stops Working at Why Number Two

When five whys does not work, and what to do instead: one incident from a published returns case, three honest why chains, three different recommendations.

Numbers in this note carry source tags ([POLICY], [THREADS n=10], [MINE]). What the tags mean.

The case under this piece is the returns case published on this site: returns and refunds at a mid-size online retailer, built from the published returns policy, its help centre articles, ten public complaint threads I picked myself [THREADS n=10] and a walk through the published journey as far as it goes without placing a real order [WALKTHROUGH]. No client, no engagement, not one interview. That matters here more than usual, because a case built entirely from outside cannot quietly repair a broken why chain with something somebody told me in a corridor. Every link below either has a tag against it or is marked as a wall.

Five Whys assumes each answer has exactly one parent. The first answer usually has three, and the technique gives you nowhere to put the other two, so by question number two you are no longer asking about the incident. You are asking about the branch you happened to pick, and everything after that inherits the choice.

In short

• The chain does not break because you stopped at four or went on to six. It breaks at the first link where two or more answers are equally true and nothing in the method tells you to write that down.
• Run the chain three times from the same incident, once from each direction somebody would naturally take it, and compare the endpoints. Three different endpoints is the normal result, not a sign that you did it badly.
• Most chains end on a condition rather than an event: something that was true of every case that day, including the ones that went fine. Conditions are fixed by design decisions, not by more questions.
• Stop at the first link nothing public can answer. Log it as an open question with an owner, a date and a fallback. The alternative is inventing link five to reach the number.

Where does the chain actually fork?

Here is the incident, stated the way it appears in the case: a damaged-delivery case reached a state where nobody owned it and no clock was running, and the only thing that moved it again was the customer chasing it.

Three people would take that incident in three different directions, and all three are reading the same document. Below is each chain, run to its natural end. A link with a tag is a link somebody else can check. A link with no tag is one I worked out from the model, and a link marked "wall" is one nothing public answers, which is where that chain stops.

Three chains, three endpoints, one incident. None of them is wrong. Chain B ends on a rule that does not exist today and had to be proposed, which is why it carries my name in the register rather than the company's. Chain C ends on a decision about the channel, not on anything that happened in this case: the spoken description of the damage is not something a second agent can read, and that was true before the parcel was sent. Chain A ends on a wall at link three, and the useful thing about it is that the chain found a hole no other artifact in the pack had noticed: the register carries six open questions and not one of them asks who decides what counts as enough evidence.

That last one is the argument for running the chain more than once. The branch that ends in a wall is the branch that produced something new.

Why does the branch you take decide the recommendation?

Because the method rewards whoever asks first. Link one has three true answers, you write down the one that came to mind, and every question after that is a question about that answer rather than about the incident. By link three the other two branches are not rejected, they are invisible, and the chain reads as though it could not have gone anywhere else.

The published case settles this in a way I did not plan. The proposed process changes exactly two things: evidence is collected before a human sees the case, and the parked branch gets a named owner with a clock on it. Two changes, arrived at separately, both kept after review. If a single root cause had been sitting under that incident, one change would have been enough and the second would have been padding. It was not padding. Each change closes a different chain, and the reviewer who read the process model first objected that the original as-is showed only the path where things go well, which is what put the parked branch on the model at all.

So the honest reading is that this incident has at least two causes that a design has to answer, plus a third question nobody can answer from outside. A technique whose output is one sentence with the word "therefore" in front of it cannot represent that.

Cause or condition, which is the distinction that does the work

Look again at where Chains B and C end. Neither endpoint is an event. No owner exists on the parked branch, and no self-service form exists on the store front. Both were true on the day the case stalled, and both were equally true on every day that a case did not stall.

That is a condition, and the test for it takes one question. Was this also true of the cases that came out fine? If the answer is yes, you have found something that lets the failure happen rather than something that made it happen, and no further why will convert one into the other. Conditions get closed by a design decision, an owner and a date. Events get closed by an investigation.

Chains that end on a condition are the useful ones, and the method gives you no signal that you have crossed from one kind of thing to the other. On the wall in Chain A the same test says something different again: an unknown is neither, and the only correct move is to write it down as unknown.

The branch sheet

This is what I keep instead of a chain. Same ten minutes, one more column, and the column that earns the page is the last one.

Read the right-hand column on its own and you have the two chains you did not run, written down where they can be picked up later instead of lost. Read the fifth column on its own and you have a list of things that would falsify your own conclusion, which is the difference between a chain you can defend and a chain you happen to believe.

The tag column is the one people skip, and here it is the one that hurts. One link of the five carries evidence, one is an open question, and the three in between are mine: I read them off my own process model rather than out of a source anybody else can open. That chain produced a requirement and a proposed rule. It is still the honest version, because the alternative was not a better-sourced chain, it was the same chain with the middle presented as fact. Labelling an inference as an inference is check 17 on the scorecard, and it costs one word per row.

The blank version

Copy this. Fill the tag column at the same time as the answer, never afterwards, because afterwards you will remember every answer as better sourced than it was.

Incident, in one sentence: __ Stopped because: ☐ reached a condition with an owner ☐ reached a wall ☐ ran out of evidence Branches parked, with owner and date: __

Three rules for filling it in. Two links in a row marked as yours means the chain has left the evidence and what follows is your model of the process. That is allowed, and the parked branch in this case got onto the model exactly that way, but it has to be visible, because those are the links somebody can knock over without leaving the room. If column five is empty for a link, you cannot yet tell whether that link is true, so it is not a finding. And if column six is empty for link one, you have not run a chain, you have written down the first thing you thought of and asked why about it four times.

Where do you stop asking?

Not at five. Five is a number in the name, not a property of any process, and in the chains above the honest stopping points fell at three, five and five.

Stop at the first link you can only mark as unknown. Then do the thing the method does not include: turn that link into an open question with an owner and a date, which is check 05 on the scorecard, plus a fallback for when the date passes, which the scorecard does not ask for and the returns case carries anyway. An unowned question does not stay a question. It gets quietly promoted to an assumption somewhere between the workshop and the build, and nobody notices until it is expensive.

The returns case carries six open questions and every one has a fallback written next to it, because an open question without a fallback is a wish with a due date attached. The one that matters most is the measurement: how many cases actually stall today, and for how long. Until that number exists, all three chains above are descriptions of a failure mode whose size nobody knows, and the case says so in the same line where the count appears. Four of ten threads I selected myself is a count of ten threads, on every page where it appears, which is check 10.

There is a quieter reason to stop early. Every link past the evidence is a link somebody can argue with in a room where you are not present, and it will be the weakest one they quote. A three-link chain that ends in an honest unknown survives a hostile reading. A five-link chain whose last two links are guesses presented as findings does not, and the three good links go down with them.

When is it still worth the ten minutes?

More often than this piece makes it sound.

Five Whys is fast, costs nothing, and needs no preparation, which makes it the right opening move in a room where people are still describing the symptom to each other. It works properly when three things hold: one actor, one run of the process, and an answer at every step that somebody present can check on the spot. Picture the simplest possible version of that: a machine stops, the wrong part was fitted, that part was sitting in the wrong bin, the bins were relabelled last week. Four links, one actor, every one of them verifiable by walking to the bin. That chain is fine and a branch sheet on top of it would be overhead.

It also earns its keep as a boundary finder. Run it once, quickly, and watch where the answers change from "here is the document that says so" to "well, what usually happens is". That switch is the edge of what anybody in the room actually knows, and finding it in ten minutes is worth more than the chain you were nominally building.

What it cannot do is carry a process with more than one actor, an exception path and a decision that changes hands. For that shape, the model is the tool and the chain is a warm-up for drawing it.

Where to start

Take the last root cause you wrote down and try to falsify link two. Not link five, which is where the argument usually happens. Link two, where the chain narrowed to one answer for the first time, and where you can still remember what the other answers were.

Then put the branches you did not take somewhere they survive the week, with the same three columns as an open question: owner, date, and what happens if the date passes.

If the process you are working on has an exception path, as-is before to-be is the piece on drawing the branch where work stops, and the parked branch in this case is the one both Chain B and Chain C are really about. If your chain ended on a link only a person inside the business can settle, the eight questions in a first stakeholder interview is how that becomes an agenda rather than a note. If it ended on an unowned rule, the stakeholder map that survives contact with the project is where the owner column belongs.

Then run the artifacts through the scorecard: twenty-five yes-or-no checks, free, no email address asked for, and checks 05, 10 and 17 are the three this habit answers to. The worked case and the six blank templates are in the Proof Pack.

The chains above are the ones I could run from outside, and Chain A stops at a wall I cannot get past without access to the company. That is the price of a case anybody can check, and it is also the clearest demonstration I have of the point: the method gave me three answers, and the only reason you can tell which of them are load-bearing is that every link carries a tag saying where it came from.

All field notes · The portfolio guide · More in The Case File