The Problem Statement

Where A3s die

Most A3s don't fail at countermeasures. They fail in the first section, before anyone has created a fishbone or chosen a metric, because the problem explained at the top wasn't a problem. It was a solution someone had already decided on, written in a way that made it look like a problem.

Once that becomes the problem statement, everything downstream is honest work aimed at the wrong target. The team will investigate. They'll gather data. They'll implement changes, but nothing will change, because the thing they fixed wasn't the thing that was broken.

I've watched it happen often enough that I now spend more time on that first box than on anything else on the page.

The tool crib

An engineering team at a heavy industrial firm came to me and said: we need a tool booking system.

It's a reasonable request. They were sharing expensive tools, only a few of each, across a whole engineering group. A booking system is a normal thing to want.

So I asked them the only question I ever open with.

"Why — explain to me what's happening."

Not "what's the problem." That invites the solution back. "Explain what's happening" asks for the scene, and the scene is where the actual problem lives.

Here's what came back. Tools got borrowed and never went home at the end of shift. So the next engineer who needed one would walk the factory asking who had it. That search cost 10 to 15 minutes, three or four times a day. Sometimes the tool never turned up at all, so there were fewer tools in circulation, so the search got longer. And the business had stopped replacing them — they were buying too many replacements already.

They kept coming back to the booking system. So I asked the second question.

"Explain the problem that you're trying to solve, so I understand why you think a booking system will solve the problem."

That one matters more than it looks. I could have said "that's a solution, not a problem" — and I'd have been right, and the conversation would have been over. Nobody responds well to being corrected in front of their team or otherwise. This version takes their idea seriously and resets the frame at the same time. It says: I'm assuming you have a good reason, tell me what it is.

Then the anchor:

"What's the impact to the business?"

Twelve minutes, three or four times a day, is about 45 minutes a day of engineers walking around a factory asking who's got the tool they need. Over a year that's the best part of a month of one engineer's time — on top of a replacement bill big enough that the company had already stopped buying.

"We need a booking system" contains none of that.

What was actually going on

Put the pieces in order and there's a loop.

Tools don't come back. Replacements cost too much. The business stops buying. Fewer tools in circulation. Getting one is harder. So engineers hold onto the one they've got, just in case. So more tools are out of the crib at end of shift. So more go missing.

A booking system sits completely outside that loop. It tells you who had the tool last. It doesn't make anyone bring it back, and it does nothing about the hoarding, which was the behaviour actually driving the shortage.

That's the whole reason the first box matters. You cannot see that loop from "we need a tool booking system." You can only see it from the scene.

How it ended

They locked the tools away and the manager became the gatekeeper.

The searching stopped, so on the numbers it worked. But I'd be overselling it to call that a root cause fix. It's a control. It worked by removing the choice, not by changing why tools weren't coming back. If the manager left, or got busy, or went on leave, most of it would come back.

I'm including it because the point of this isn't that I solved the tool crib. It's that the problem they arrived with — a booking system — would have cost real money and fixed nothing, and the only thing standing between those two outcomes was about ten minutes of asking.

The questions

In the order I actually use them.

1. "Why — explain to me what's happening."

The opener, always. It asks for the scene rather than a diagnosis. You're listening for a sequence of events, not a cause.

One note on timing: only ask "when did this start" if something genuinely changed. On a chronic condition — a crib that's been leaking tools since the day it opened — you'll get "it's always been like this," which sounds like an answer and isn't.

2. "Explain the problem you're trying to solve, so I understand why you're suggesting that."

Use this when they keep steering back to their solution. It's a reframe that doesn't cost anyone face.

3. "What's the business impact?"

Forces a number, or exposes that nobody has one. Both results are useful. If nobody can answer it, you've learned that nobody owns the measure — and that's usually a bigger finding than the one you came in for.

4. "Where does it happen — and where doesn't it?"

Every shift or one shift. Every tool or the expensive ones. The "doesn't" half is the one people forget, and it's where the comparison lives. Is the problem actually common.

5. "What's already been tried?"

This is where the resistance is buried. If something has been tried and failed, your countermeasure will be measured against it whether you like it or not.

6. "Who's closest to it?"

The person reporting a problem is rarely the person living with it. In the crib story the request came from the team; the cost showed up on shifts the manager never worked.

Reading the answers

The answers matter less than what the shape of the answer tells you.

"We don't have the data."
Usually means nobody owns the measure. That's a finding, not an obstacle and often the first thing worth fixing.

"Everyone knows it's X."
You've been handed a conclusion. Ask who disagrees. If nobody does, ask again in private.

"It's always been like this."
Either a chronic condition — fine, stop asking about timing and start asking about volume or a change so gradual nobody logged it. Ask what it looked like two years ago and see whether the answer is different.

They keep returning to their solution.
They're not being difficult. They've usually thought about this longer than you have and they're attached to the answer. Question 2 exists for exactly this.

A cost you didn't ask about.
Listen for it. In the crib story the replacement spend came from them, not from me. It was sitting inside the answer to question 1, described as background. The second cost is usually already in what they've told you. You just have to hear it as a cost.

What goes in the box

Four things. Not a definition — a test. If any of the four is missing, you don't have a problem statement yet. You have a complaint or a proposal.

The crib, written properly

Shared engineering tools are not returned to the crib at end of shift. Engineers searching for tools lose 10–15 minutes on 3–4 jobs per day — around 45 minutes a day across the group. Tool loss has driven replacement spend high enough that the business has stopped approving new purchases, reducing the tools in circulation further. Source: engineering team estimate, cross-checked against purchase records.

Same situation. No solution in it. And now the hoarding is visible, which it never was in "we need a tool booking system."

You don't need to be clever in that first conversation. You need to be deliberate.