A client said something to me recently that I haven't been able to shake. We were three months into a website rebuild for a mid-sized professional services firm - good people, ambitious leadership, the works - when the project lead turned to me and said, "I wish we'd spent more time at the start figuring out what we actually needed."
Three months in. Budget half gone. And they were only just realising they'd been building the wrong thing.
It's a scenario I've seen play out more times than I'd care to admit, across consulting firms, SaaS businesses, legal practices and financial services companies. And the root cause is almost always the same: the discovery phase was either rushed, skipped entirely or treated as a box-ticking exercise before the 'real work' began.
So I want to make the case for doing discovery properly. Not because it's a neat process we like to follow (although it is), but because it's the single most effective way to stop a digital project going sideways before it's even started.
Do you? I'm not so sure.
This is the most common objection I hear from senior leaders when we suggest a structured discovery phase. And I get it - you've been living with the problem for months, maybe years. You've had countless internal conversations. You've probably even written a brief.
But here's the thing: knowing you have a problem and correctly diagnosing that problem are two very different things. A firm might come to us saying, "We need a new website." And they're not wrong - the current site is slow, dated and embarrassing when clients ask for it. But the website is often a symptom, not the disease. Underneath, there might be a content strategy that doesn't exist, a CRM that's not connected to anything, an internal team with no clear ownership of the digital estate, or a set of user journeys that were last mapped out when David Cameron was still Prime Minister.
Discovery is how you get beneath the surface. It's how you move from "we think the problem is X" to "the evidence tells us the problem is actually Y, and here's what we should do about it."
I should be clear about what I mean by discovery, because the term gets thrown around a lot - often to describe something far less rigorous than it should be.
A proper discovery phase is a structured, collaborative process that brings together the key people from both sides - your team and ours - to align on what you're building, who you're building it for and why. It's not a single meeting. It's not a questionnaire. And it's definitely not your agency presenting a mood board and asking if you prefer blue or green.
Depending on the complexity of the project, discovery might include:
None of this is glamorous. There are no shiny prototypes or exciting visual concepts at this stage. And that, I think, is part of the problem - discovery doesn't feel like progress to people who are itching to see something tangible. But it is progress, and it's the kind that prevents you from wasting six months and a significant chunk of budget building the wrong thing.
Let me put some numbers around this, because the financial argument for discovery is actually quite stark.
Research from the Systems Sciences Institute at IBM found that fixing a defect after delivery is roughly six times more expensive than catching it during the design phase and up to fifteen times more expensive than identifying it during requirements gathering. That's not a rounding error - it's the difference between a project that comes in on budget and one that spirals.
And that's just the hard costs. The soft costs - the internal frustration, the loss of momentum, the team that was energised at kick-off but is now going through the motions because the goalposts keep moving - those are harder to quantify but equally damaging.
I worked with a financial services firm a couple of years ago that had already been through one failed website rebuild before they came to us. The first agency had jumped straight into design, produced something that looked lovely but didn't address any of the firm's actual business challenges, and the whole thing was quietly shelved six months later. The cost? North of six figures, plus the opportunity cost of a year spent going nowhere.
When we started the project again, we spent the first four weeks on discovery. Proper discovery - workshops, user interviews, technical audits, stakeholder alignment sessions. It felt slow at the time (the CEO told me as much). But when we moved into design and build, we moved fast and with confidence, because everyone knew what we were building and, more importantly, why.
This is the second most common objection, and it's understandable. When you've finally got budget approval and internal buy-in for a project, the last thing you want to hear is that you need to spend four to six weeks asking questions before anyone writes a line of code.
But discovery doesn't slow projects down. It speeds them up - it just front-loads the effort.
Without discovery, projects tend to start fast and then grind to a halt as ambiguity, misalignment and unforeseen complications pile up. You end up in endless rounds of revisions because the brief was never clear enough. You end up rebuilding features because nobody asked the right questions about user needs. You end up in tense conversations about scope because what was 'assumed' by one party was never actually agreed by the other.
Put another way: discovery is the planning stage that prevents poor performance later. That's not a groundbreaking insight - it's common sense. But it's remarkable how often it gets sacrificed in the rush to show momentum.
There's another benefit to discovery that rarely gets talked about: it's where the working relationship between client and agency actually forms.
In my experience, the projects that go well are the ones where there's genuine trust between both sides. Not blind faith - real, earned trust based on mutual respect, shared understanding and honest communication. And that trust doesn't materialise from a statement of work or a contract. It comes from sitting in a room together (or on a call, depending on geography), wrestling with hard questions and being honest about what you know and what you don't.
Discovery is the phase where your team gets to see how we think, how we challenge assumptions and how we handle complexity. And it's where we get to understand your business, your culture and the political dynamics that will inevitably shape the project (every organisation has them, and pretending otherwise is naive).
By the time we move into design and build, we're not strangers anymore. We're a team that's already been through something together, and that makes everything that follows smoother, faster and more productive.
Every project is different, but there are a few principles that consistently separate effective discovery from the perfunctory kind:
It involves the right people. Discovery is not something that should be delegated entirely to the most junior person on the client side. You need decision-makers in the room - people who understand the business strategy, the commercial pressures and the politics. That doesn't mean the CEO needs to be in every session, but if the people in the room don't have the authority to make decisions, you'll end up revisiting everything later.
It's structured but not rigid. Good discovery follows a clear framework but leaves room for the unexpected. Some of the most valuable insights I've seen emerge from tangential conversations that wouldn't have happened in a more prescriptive process.
It produces something tangible. At the end of discovery, you should have a clear, shared document that everyone can refer back to - objectives, user personas, technical requirements, site architecture, success metrics. Not a hundred-page tome that nobody reads, but a focused, actionable reference point that keeps the project on track.
It's honest. Sometimes discovery reveals things people don't want to hear. Maybe the budget isn't sufficient for the scope. Maybe the internal team doesn't have the capacity to support the project. Maybe the brand positioning needs work before a new website will make any difference. Good discovery surfaces these truths early, when they can still be addressed without derailing the whole thing.
I appreciate that none of this is particularly revolutionary. "Plan before you build" is hardly a radical proposition. And yet, time and again, I see firms investing significant sums in digital projects without spending the time upfront to make sure they're investing in the right things.
If you're about to embark on a digital project - whether it's a new website, a platform migration, a customer portal or something else entirely - ask yourself this: could I clearly articulate, right now, what this project needs to achieve, who it needs to serve and how we'll know if it's worked?
If the answer is yes, and you have the evidence to back it up, brilliant. Crack on.
If the answer is anything less than a confident yes, you probably need discovery more than you think.
