If the Plan Is a Document, You Bought a Document

There's a particular calm that follows a good strategy presentation. The analysis holds up. The sequencing makes sense. Someone says, with real relief, that this is exactly the clarity the team needed.

Then the room empties, the work keeps arriving in the same shape, handled by the same people in the same way, and the document goes into a shared drive under a filename ending in v3.

Nothing has visibly gone wrong, which is what makes this hard to spot. The thinking may have been excellent. The question is what the thinking was allowed to turn into.

If the only thing you can show at the end of thinking about AI is a document, the business hasn't changed. That isn't a complaint about quality. A shorter, cheaper, more actionable document is still a document. What matters is what kind of object you're holding when the work is over.

Agreement is cheap. Contact is where you learn.

A plan is easy to agree with. Nodding at a recommendation costs nobody anything. No data has to be clean for a slide to be persuasive, and no colleague has to change how they work for a phase diagram to look sensible.

So a plan can be internally perfect and still rest on guesses that careful reading won't expose:

• Is the data as tidy as the assessment assumed?
• Will the person whose job this touches actually use the new thing, or keep their own spreadsheet beside it?
• Is the step everyone agreed to automate really the step that hurts?

Only contact with the real work answers those. A document can put off that contact until after the invoice.

A working thing is the opposite. It has to survive a real person, on a real morning, with real data. That isn't a drawback of building early. It's the whole reason to do it.

The plan and the first working thing should be the same object

This is narrower than it sounds. It isn't "stop planning", and it isn't "move fast and find out". It's a point about where the thinking should end up.

Thinking about AI in your business is necessary: where the hours go, what the data really looks like, what people will happily use. All of that has to happen. The question is what it hands over at the end.

• If it hands over a description of a change, you've bought a description.
• If it hands over something a named person uses, the thinking lives inside that thing, and everything learned while making it is now knowledge rather than assumption.

If you find yourself summarising this as "plans should be more actionable", that's a weaker idea. It accepts that a document was the right output and only asks for a better one.

Three questions that tell you what shape a purchase is

Next time something is proposed, by an outside firm, by your own team or by you, put it through three questions first.

1. What will exist at the end of this that doesn't exist now? If every answer is something you read (a roadmap, a readiness assessment, a capability map, a business case), the output is a document. A list of recommendations doesn't exist in your business. It exists about it.

2. Whose work changes, and from when? Name a person and a date. Not a department or a workstream: the person who will open the thing. If you can't fill in both, the proposal hasn't touched anybody's week yet, and you can't judge it.

3. What could this be wrong about, and when would we find out? Every serious piece of work has a guess at its centre. A working thing tests its guess quickly, often by going wrong in a specific, useful way. A document tests its guess only when something is finally built against it, which may be months later.

None of these needs a committee. You can run all three on a proposal today.

What to ask for instead

You don't have to refuse the thinking. You move the finish line.

Hypothetical example: a regular task where someone turns a pile of supplier emails into the stock spreadsheet that everyone half-trusts.

• The document-shaped response is reasonable and recognisable: an integration proposal, a data quality workstream, a vendor shortlist, a phased rollout with the messy part in phase three. Every page is defensible, and someone is still reading emails by hand.
• The change-shaped response is smaller. After a short first build, that person opens something that has already read the emails and filled in the rows, and they spend their time checking and correcting instead of typing. That's the whole first delivery.

Look at what it gives you beyond the time saved:

• You learn that some suppliers format their numbers in a way nobody mentioned.
• You see where the corrections cluster, which tells you exactly where to spend the next round of work.
• You find out whether the person trusts it, because you watch whether they check every row.

None of that was available from the plan. The corrections are the plan. Any roadmap you write afterwards is worth more, because it's written from experience rather than expectation.

"But some changes are too big for that"

Some are: a warehouse move, a regulated process, a system a lot of people rely on. The test still holds, because it's about the artefact, not the ambition. The first delivery can be a thin slice that runs: one supplier, one branch, one form. The slice is still the plan. It's just a plan you can watch working.

And if nobody can describe what the first working thing would be, that's useful information too. It means the problem isn't understood well enough yet. Another document won't fix that. Sit with the person doing the work and watch it for a while. The first working thing usually becomes obvious once the problem becomes real.

This week

Take whatever you were about to commission and write three lines on it:

• What exists at the end.
• Whose work changes, and from when.
• What it could be wrong about, and when you'd know.

If the first line is only a document, don't cancel the work. Change what it delivers. Make the first working thing the deliverable, and let the written material be the record of having built it. Pick the problem that costs your team its most irritating hours, and get something real in front of the person who lives with it.

If that step matters and you'd rather not take the first swing at it alone, The Catalyst is where that conversation starts.

Either way, the test is the same. When the work is finished, can you point at something that works?