Why we don't skip to the build

"We already know what the problem is. Can you just build it?"

It is a fair question and it is usually asked by competent people under real time pressure. They are not wrong that they know something. They are wrong about what they know.

What gets escalated is not what is broken

The thing that reaches a decision-maker is the thing that became visible. It is almost never the thing that caused it.

A finance team asks for automated invoice matching because reconciliation is taking four days. Sit with them and you find the four days are spent chasing purchase orders that were raised after delivery, because the procurement flow allows it and one large supplier exploits it. Automate the matching and you get a faster system that produces the same exceptions, now with less visibility into why.

We have made this exact mistake ourselves, which is where the stage came from.

The first stage is cheap and the fourth is not

The cost of being wrong about the problem rises sharply with how much has been built on top of the misunderstanding.

• Wrong in Develop: you rewrite a document. Days.
• Wrong in Build: you throw away code nobody depended on. Weeks.
• Wrong in Scale: you migrate live data and retrain the people using it. Months, and someone's quarter.
• Wrong in Grow: it is now your client's problem, in production, and you are not there. This one does not have a unit.

Develop is two to four weeks. It is not a tax on the build. It is the cheapest place left to be wrong.

What Develop actually produces

Not a research report. A decision, in writing, that the client could act on without us:

• What is actually happening, written from watching it rather than from the process documentation.
• Where the operation leaks, in order of cost, with the evidence for the ordering.
• What the smallest system that changes the outcome would be.
• What it would take, and — the part that earns trust — whether it is worth it.

Some of the engagements we are proudest of ended at that document, because the honest answer was that the build was not worth doing. Those clients come back.

Why not skip it when the client is right?

Sometimes they are. Perhaps one in five times, the problem as stated turns out to be the problem as found.

But you cannot tell which case you are in without doing the work, and the cost is asymmetric. Four unnecessary weeks against a build aimed at the wrong target is not a close call.

The part that is really being asked

Under the question is usually a different one: can you go faster?

Yes — but by narrowing the build, not by removing the stage that tells you what to narrow it to. Shipping the smallest system that changes the outcome, running on real data in week one, is much faster than a well-specified build of the wrong thing. It just does not feel faster in the first fortnight, which is why the pressure to skip Develop is at its highest exactly when skipping it is most expensive.