Most "discovery phases" are a con.
Not all of them. But enough that if you're sitting there thinking discovery is just a way to start the meter running before you've committed to anything, I'm not going to tell you you're wrong. You're probably drawing on direct experience. Someone charged you £30k for a six-week exercise that produced a deck confirming what you already knew, conveniently recommending the platform they happened to specialise in. I've seen that playbook so many times it makes my teeth itch.
So let's start there. Your scepticism is earned. And if the only version of discovery you've encountered is the one where an agency reverse-engineers an investigation to justify a conclusion they'd already reached, I'd be sceptical too.
But I need to push back - because the fact that discovery is often done badly doesn't mean the thing itself is a bad idea. It means most of the industry has got lazy with it. And the cost of writing it off entirely is real.
At its core, discovery is a structured investigation to understand the problem your organisation is actually trying to solve before anyone commits to a solution.
That's it. That's the whole thing.
It's not a requirements-gathering exercise - that assumes the problem is already understood and just needs specifying. It's not a rubber stamp for an approach someone's already decided on. And it's not an extended onboarding period for a team that should have done their homework before the engagement started.
A proper discovery produces four things. A clear problem statement that you recognise as accurate and the delivery team can use to make decisions. An evidence base showing the investigation was actually conducted rather than assumed - interview summaries, data reviewed, assumptions tested. Prioritised recommendations with explicit trade-offs - not just "here's what you should do" but "here are three options, here's what each costs and risks, here's our recommendation, and here's why." And enough specificity that the findings can be used to brief a board, select a partner, or scope a delivery programme without needing another phase to make them actionable.
If what you received at the end of your last discovery didn't look like that, you didn't have a discovery. You had a sales exercise with a fancier name.
I was talking to the COO of a mid-sized accountancy firm a few months ago. They'd just come out of a website rebuild that went 70% over budget and took twice as long as planned. When we dug into it, the root cause was completely predictable: they'd started the build without properly understanding what the project was supposed to solve. The brief said "new website." The actual problem - which nobody surfaced until sprint four - was that the enquiry-to-onboarding handoff was broken, and no amount of visual redesign was going to fix it.
By the time they figured that out, the governance structure, the team, the commercial relationship - everything was optimised for executing the original brief. Pivoting mid-delivery meant scope changes, renegotiation, a very awkward steering group meeting, and about £180k of work that needed rethinking. A two-week discovery phase would have cost them a fraction of that.
The mechanism is boringly straightforward: if you don't understand the problem before you start building the solution, you'll discover the real problem mid-delivery. And fixing things mid-delivery is always - always - more expensive than getting clarity upfront. The projects that go wrong aren't usually the ones with the wrong technology or the wrong team. They're the ones that answered the wrong question.
"But we already know what the problem is. We just need someone to build it."
Maybe. But in roughly two-thirds of the engagements we've taken on at Distinction over the past decade, the problem the client described in the initial brief turned out to be a symptom of something else. Not because they were wrong - because they were seeing the problem from the inside, where it's genuinely hard to separate cause from effect. Nobody in the room has the distance to see the full picture. That's not a criticism. It's just what it's like to be inside a business.
Here's the bit that might feel a little uncomfortable, but I'd rather be honest about it.
Discovery is a two-way process. And I've seen perfectly good discovery exercises produce mediocre results because the client treated them as something that happened to them rather than with them.
What does that mean in practice? Key stakeholders need to be genuinely available - not delegating to someone two levels down who can't speak to the real constraints. Documentation needs to be shared without filtering. The stuff that's politically sensitive or a bit embarrassing - the previous project that failed, the budget that got cut, the internal disagreement about priorities - that's usually where the most useful insights live.
And - this is the big one - you need to be willing to be surprised.
The most valuable thing a discovery produces is almost always something the client didn't expect. A constraint that changes the options. A finding that shifts the priority. An insight about the problem that rewrites the brief. A client who uses discovery to validate a decision they've already made will get a more expensive version of the same outcome they'd have had without it.
I remember one engagement where the managing partner had already decided they needed a new CRM. Two days into discovery, it became clear the CRM was fine - the problem was that nobody had configured the reporting properly, and the sales team had quietly built a shadow system in spreadsheets because the dashboards were useless. The fix cost about a tenth of what a new CRM would have. But if we'd been told "just scope the CRM migration," that's what would have happened. And everyone would have been very pleased with the project right up until the moment they realised the spreadsheets were still there.
You can apply these tests to any discovery proposal from any partner - not just us.
Do you understand your problem better than you did before? If you come out of a discovery phase with the same understanding of the problem you went in with, the investigation wasn't investigative. It was performative. You should feel like someone turned a light on in a room you'd been navigating by feel.
Did the recommendations surprise you at least once? If everything was exactly what you expected, the discovery confirmed rather than discovered. That doesn't mean the recommendations should be wildly left-field - but there should be at least one moment where you think "huh, I hadn't seen it that way." If there isn't, you probably paid for validation, not insight.
Can you explain the core problem statement to a colleague who wasn't involved? If you can't - if the findings are locked in a 90-page document that requires the agency to walk someone through it - then the discovery didn't produce clarity. It produced complexity. A good discovery simplifies. It gives you a story you can tell your board, your partners, your steering group, in plain language, without needing the consultants in the room.
Those three tests aren't complicated. But they're diagnostic. A discovery that passes all three was worth the investment. One that fails any of them should prompt some hard questions.
Now - I don't want to leave you with the impression that discovery only matters for massive transformation programmes. It matters for any digital investment where the problem isn't fully understood before the solution is chosen, which, if I'm being honest, is most of them. The scale should be proportionate, though. A £50k website refresh doesn't need an eight-week discovery. It might need a focused two-week assessment. A £500k platform migration with regulatory implications? That warrants something more substantial. The question isn't "should we do discovery?" It's "what's the right depth of investigation for the risk we're carrying?"
And look - discovery doesn't eliminate risk. Projects that had excellent discovery phases still encounter unexpected problems. What changes is the ratio of expected to unexpected. You go into delivery with your eyes open, your brief tested, your board aligned. The surprises that remain are manageable ones, not the kind that blow up the programme.
If you want to understand what a properly structured discovery brief looks like - what it asks, what it produces, and what standard it should be held to - download a sample discovery brief template here. It's designed to be vendor-neutral, so you can use it to evaluate any discovery proposal, not just ours. Frankly, if it helps you get better discovery work from someone else, that's fine by me. The industry needs to raise its game on this.
And if you're trying to decide whether a discovery phase makes sense for your specific situation, a 30-minute conversation will give you a direct answer without any commitment on either side. Sometimes the honest answer is "you probably don't need one." I'd rather tell you that upfront than charge you for something that won't change the outcome.