The Discovery Phase is a con
Author
David Johnson
Date Published

Slide one is always the same.
A double-diamond diagram. Clean. Symmetrical. The kind of thing that looks like it was designed by someone who folds a lot of laundry. On the left: Discover. Diverge. On the right: Define. Deliver. In the middle, at the pinch point where the two diamonds meet, a word that is doing enormous amounts of heavy lifting: Insight.
The agency presents this to you with the confidence of people who have presented it many times before, which they have. They talk about empathy. They talk about assumptions. They talk about the importance of not jumping to solutions before you've properly understood the problem. They are right about all of this, technically. They are also charging you between £15,000 and £40,000 for four to six weeks of work that will produce a document you have already, functionally, written yourself.
You just didn't know it yet. You will by week three.
We know this because we wrote those decks. Sat in those rooms. Facilitated those workshops where the sticky notes went up in clusters and were photographed on someone's iPhone and never looked at again. We were good at it. We were charming and organised and we used the right words and we sent the report on time, with an executive summary and a set of "key themes" that, if you'd asked anyone in the client organisation six weeks earlier, they could have listed from memory in about four minutes.
This is not a confession we make lightly. But it's the one worth making.
Here is what a discovery phase is supposed to be.
A structured process of research and synthesis, conducted before any build work begins, designed to surface the actual problem rather than the assumed one. User interviews. Stakeholder mapping. Technical landscape review. The goal is to arrive at a definition of the problem that is specific enough to be solved, and to make sure you're solving the right one. This is genuinely valuable. This is not what most discovery phases are.
Most discovery phases are a revenue bridge.
The agency has won the work. The work is to build something. A platform, a service, a website, a system. But they can't start building yet, because the requirements aren't defined, and besides, the team isn't fully assembled, and there's a notice period to work through, and the subcontractor who's doing the frontend is finishing another project first. So they need something to do. Something billable. Something that looks like progress.
Enter: Discovery.
Four to six weeks. A lead consultant, maybe a designer, a researcher if you're lucky. A series of workshops with your team, which your team attends while also doing their actual jobs, which means the workshops run long and the actions never quite get followed up, but the notes are thorough and the Miro board is very colourful. Interviews with users, six to ten of them, which is not enough to be statistically significant but is enough to be presented as "qualitative insight." A synthesis session. A readout. A report.
The report lands in your inbox as a PDF, forty to sixty slides, with a cover that has your logo on it and theirs, side by side, which is meant to signal partnership but mostly signals that they had a good template. It contains: themes you already knew, phrased in language you wouldn't have used. A persona or two, composite humans assembled from the interviews, with names like "Service Manager Sarah" and a list of frustrations that could describe approximately any person working in any mid-sized organisation in the country. A "How Might We" question that reframes your original brief in slightly more open-ended terms. A set of recommendations that point, with the inevitability of a compass finding north, toward the thing the agency already knew they were going to build when they walked in the door.
And then, this is the part that should make you put the PDF down and go for a walk, a proposal for Design and Build.
We want to be precise here, because precision matters and vagueness is how this industry protects itself.
We are not saying discovery is worthless. We are saying that most discovery phases, as sold and delivered by most agencies to most clients, are not actually discovery. They are the performance of discovery. They are the ritual without the substance. The difference is this: real discovery changes what you build. It surfaces something you didn't know, reframes the problem in a way that changes the solution, produces a recommendation that is genuinely surprising to someone in the room.
Ask yourself, honestly: did the discovery phase you paid for change anything? Or did it confirm what everyone walked in believing, in a format that was easier to present to your board?
If the answer is the second one (and we would bet, quietly, that it usually is) then what you paid for was not research. It was legitimacy. A paper trail. A process that, if anyone later asks why you built what you built, gives you something to point to. This is not nothing. Organisations need paper trails. Procurement requires evidence of due diligence. We understand.
But let's not call it discovery. Let's not dress it up in empathy maps and double diamonds and pretend it's something it isn't.
The actual problem with the discovery phase, the structural problem, is that it is sold as independent and delivered as anything but.
An agency that has already scoped a build, that has a commercial interest in a particular solution, cannot conduct unbiased discovery into whether that solution is correct. The incentive is not to find the truth. The incentive is to find the truth that supports the next statement of work. This is not malice. This is gravity. It pulls without anyone deciding to pull.
The researchers are not corrupt. The consultants are not lying. They are human beings operating inside a commercial structure that rewards particular outcomes, and they are, largely unconsciously, finding what they are looking for. The themes that make it into the report are the ones that support the direction. The user quotes that get highlighted are the ones that resonate with what the team already believes. The recommendations that don't appear are the ones that would unsettle the project, the timeline, the budget, the relationship.
This is how you get a forty-slide deck that validates everything you walked in knowing, delivered with the confidence of a spiritual revelation.
So what does good look like. Because there is a version of this that works.
It is shorter. Two weeks, not six. It involves fewer workshops and more direct observation. Watching people actually do the thing, in the environment where they do it, rather than asking them to describe it in a room with a facilitator and a Miro board. It produces fewer slides and a clearer output: here is the problem we are solving, here is the evidence, here is what we recommend and why, here is what we explicitly decided not to do and why.
It is conducted by someone with no commercial interest in the answer. Or, if it's conducted by the delivery team, which is sometimes right, because the people building the thing should understand the problem. It is conducted with enough honesty and enough structure to surface the inconvenient findings, not just the convenient ones.
And it is willing to say: build nothing. Not yet. Not until this is clearer. Not until you've tested the assumption that a new system is actually what's needed, rather than a fixed process, or a trained team, or a decision that someone with authority has been avoiding making for two years.
That recommendation, build nothing, is the one you will never get from an agency that has already quoted you for the build.
In the past, we built a lot of things that shouldn't have been built. We wrote a lot of decks that told clients what they wanted to hear, in language that sounded rigorous, with a timeline attached. We were good at it. The projects launched. Some of them worked. Some of them are still running, which is its own kind of success. Some of them are not.
What we do now is different. We find out what's actually wrong before we recommend what to build. Sometimes the answer is uncomfortable. Sometimes it's cheaper than expected. Sometimes it's not a digital solution at all.
We do not find this commercially convenient. We find it the only way we can work without lying to people.
If you've got a discovery report sitting on a server somewhere, polished, thorough, slightly expensive, completely ignored, and you're not entirely sure the project that followed it was the right project, we'd be happy to have that conversation.
It won't take six weeks.
Holo Foundry works with SMEs and public sector organisations who want to understand the problem before they pay to solve it. We've been inside the agencies. We know how the decks get written.

Most organisations implement Agile ceremonies without Agile culture. Here's how to tell the difference and why the retrospective is always the giveaway

Good enough isn't lazy, it's a definition. Here's how to set it before the build starts, hold it when the pressure arrives, and stop letting the revision cycle destroy the value of the thing you're building.
