A Plan With Nothing Logged Is Not Momentum

I rebuilt a client's demand plan around buyer journeys instead of disconnected activities, and it is the best version of that artefact I have made. Fifty-five activities across seventeen channels and six buyer stages. A daily activity surface with role targets and named owners. Three hundred and forty-three planned touches in the first push.

Every row read Not logged. The weekly checklist read 0 of 22.

The plan was a week old. Nothing in it had happened yet, and I had been describing it to myself — and nearly to the client's leadership — as progress.

Three numbers that were not what they looked like

Underneath the journey model, the arithmetic had three separate problems, and they are the generalisable part.

Matched is not qualified. A title search across a prospect database returned around twelve hundred people holding the right job title. When I checked a national subset by hand, roughly one in six was at a company that could plausibly buy this product at all. The rest were at firms in adjacent trades, consultancies, suppliers to suppliers. The headline number was real and the implied audience was about a sixth of it.

Clusters overlap, so they do not add. I had grouped the capability portfolio into five or six buyer clusters and summed their audiences into a total. The same engineering director sits in three of those clusters. Addition was the wrong operation and I performed it anyway, because the sum is the number that makes the plan look fundable.

The counting instrument has a language problem. Two of the largest target markets use local-language job titles that an English title search simply does not see. So the audience is overstated in one region and understated in two others, in opposite directions, by unknown amounts. A number wrong in a known direction is useful. A number wrong in two directions at once is not a number.

Add to that a model whose later-year targets did not follow from its earlier ones — broken formulas, not broken reasoning — and a cost-per-click assumption of fifty cents carried across every paid channel, which for a narrow technical audience is optimistic by a multiple I would rather not guess at.

The constraint I had not checked

The thing that should have stopped me first was the one I found last. The plan required about seventy-four outbound contacts a week from a team with capacity for roughly fifty.

That is not a stretch target. It is a plan with a twenty-four-contact-per-week deficit written into it, which means the plan fails in week one and keeps failing quietly — and because the shortfall is distributed across owners, nobody experiences it as a failure. Each person is simply a bit behind.

So the honest summary of the artefact: a coherent, well-structured, internally inconsistent plan to do more work than exists, aimed at an audience about a sixth the stated size, priced on an assumption nobody tested, with no actuals in it anywhere.

The check, before presenting any demand plan

Five questions, in this order, because they get progressively harder to answer and the cheap ones kill plans fastest:

1. Is this audience qualified or merely matched? Hand-check a sample. One in six changes a plan; one in six discovered after launch ends one. 2. Do the segments overlap? If yes, the total is not the sum, and say so on the slide. 3. Does the capacity exist? Required contacts per week against available hours per week. If the first is bigger, the plan is already a miss. 4. Which single number in here is an actual? If the answer is none, it is a hypothesis document. That is fine — label it. 5. Do the years agree with each other? A model assembled across sessions needs one pass whose only job is checking the sections against each other.

The pricing version of the same error

The same fortnight, on a different deal, I priced a deployment by adding a margin to my estimated delivery cost and presented the result as a market price.

A cost-plus price is a statement about me. It encodes my salary assumptions, my delivery estimate and my margin preference, and contains exactly zero information about whether anyone will pay it. I then built a returns case on top of it, which compounds a guess into a forecast. The test I keep not running, because it is slower and more exposing than a spreadsheet: time-track one real delivery, and ask one real buyer what they currently spend on the problem.

Both errors — the audience sum and the cost-plus price — have the same shape. I generated a number I controlled and treated it as a number the market had given me.

Where this goes wrong

A plan nobody has logged against is still better than no plan. The planning is what surfaced the capacity gap in the first place; a vaguer document would have hidden it. I do not want to conclude that building the plan was the mistake, because it wasn't — presenting it as traction was.

Demanding actuals before momentum can also stall a launch. There is a version of this discipline where nothing may be presented until it has been proven, and that version never gets the resources that make the proving possible. The resolution is labelling, not withholding: planned and logged in separate columns, with the logged column allowed to be empty and visibly so.

And the uncomfortable one: "get the owners to log their activity" is a people problem I keep trying to solve with a better interface. I have now built the logging surface twice. The gap is not a missing feature; it is that logging is work with no reward attached for the person doing it, and no dashboard fixes that. Until somebody's week visibly goes better because they logged, the column stays empty — and a third interface will not change it.

The line worth keeping: the only number in a demand plan that is not a guess is the one somebody logged.