The discovery phase that talks you out of building

A prospective client arrives with a solution already decided. They want a mobile app, or a portal, or an internal platform. They have often been thinking about it for months and have a fairly detailed idea of what it should do.

The first job of discovery is to find out what problem that solution was meant to address, because surprisingly often the solution and the problem have drifted apart.

The question that does the work

"What happens today if this does not get built?"

Asked plainly, it produces one of three answers.

Sometimes: a specific, quantified cost. Four people spend two days a month reconciling spreadsheets; errors cost roughly this much per quarter. Excellent — there is a real problem with a real value, and we can size a solution against it.

Sometimes: a vague strategic gesture. We need to be more digital. Competitors have an app. This is not a reason to spend money, and treating it as one is how six-figure projects end up unused.

And sometimes, most usefully: nothing much. The pain that motivated the idea has been quietly solved another way, or the process it targeted has been reorganised, and nobody has revisited the plan.

An example

A logistics client came to us with a specification for a driver management platform. Two vendors had quoted around eighteen months.

Two weeks of interviews established that roughly half the requirements described a depot structure the business had abandoned during a restructure the previous year. Nobody had updated the specification because nobody owned it — it had been written by someone who had since left.

We cut the scope by about forty percent before a line of code was written. The system shipped in five months.

That is not clever consulting. It is just asking current questions about an old document.

What we do when the answer is "do not build it"

We say so, in writing, with the reasoning. Then we usually propose something smaller: a spreadsheet with better structure, a configuration change to a tool they already pay for, a two-week automation rather than a two-quarter platform.

This costs us the larger engagement. It is still the right call, for a reason that is not purely principled: the alternative is building something that gets quietly abandoned, and an abandoned system is a reference we can never use and a client who never comes back.

What discovery produces

Two to four weeks, fixed price and fixed scope, ending with:

• A validated problem statement with agreed success metrics
• A prioritised feature set, including an explicit list of what we are not building
• A clickable prototype of the core journey
• Technical architecture and integration constraints
• A costed estimate accurate to roughly ±15%, with the assumptions written down

The outputs belong to the client. They are deliberately written so any competent team can execute against them, and a fair number of clients take them to competitive tender. We would rather that than win work on the strength of being the only people who understand the plan.

Why the estimate is worth more than the design

An estimate with the assumptions attached can be challenged. One without them is a number someone has to either accept or reject on trust.

When we say five months, we also say: assuming the payment provider's sandbox is available in week two, assuming one nominated decision-maker, assuming the existing customer data is as clean as the sample suggested. If those assumptions break, the forecast changes and everyone can see why.

That is the difference between a plan and a promise. Plans survive contact with reality. Promises just get broken quietly, usually around month four.