The Discovery Call: The Questions That Decide a Project
Most failed projects were lost in the first conversation, not the last one. By the time a deployment is struggling — the architecture fighting the requirements, the stakeholders disappointed, the scope quietly mutated into something nobody agreed to — the cause is almost always a discovery call that did not dig deep enough months earlier. The technical work usually was not the problem. The understanding underneath it was, and understanding is the entire job of discovery.
I have come to treat the discovery call as the highest-leverage hour in any engagement. Get it right and the rest of the project is largely execution. Get it wrong and no amount of clever engineering downstream will save you, because you will be building the right thing’s evil twin with great precision.
The expensive mistakes are not made in the build. They are made in the first conversation, where the wrong assumption gets baked in so quietly that nobody notices until it has set like concrete.
Discovery is not requirements gathering
The first reframe is that discovery is not a form-filling exercise where you collect a list of requirements and read them back. A requirements list tells you what people think they want. Discovery is about understanding why they want it, what problem it is really meant to solve, and what is actually true about their situation underneath the stated ask. Those are different things, and the gap between them is where projects die.
People are very good at describing solutions and very bad at describing problems. They will tell you they need a specific technology, a particular feature, a named product — because they have already, in their heads, leapt from their problem to a solution, and what they hand you is the solution. The job of discovery is to walk that backwards: past the solution they have proposed, to the problem they are actually trying to solve, because very often the proposed solution is wrong even though the problem is real. If you build what they asked for without understanding why, you will deliver exactly what was specified and entirely miss what was needed.
The questions that earn their place
A handful of questions do most of the work, and they are deliberately about why and what really, not what technology.
“What does success look like, specifically?” Not “what do you want to deploy” but “how will you know this worked?” The answers are revealing. Vague success criteria — “make it better”, “modernise the estate” — are a warning that nobody has agreed what they are actually buying, and a project with no shared definition of done cannot be finished, only abandoned. Pin this down early or inherit the argument later.
“What happens if we do nothing?” This finds the real driver. A genuine, urgent pain produces a sharp answer — a cost, a risk, a deadline, a fire. A waffly answer means the project is a nice-to-have wearing a priority’s clothing, and it will lose its funding and its stakeholders’ attention the moment something genuinely urgent appears. Knowing which one you are in changes how you scope and how hard you push.
“Who is actually affected, and have you spoken to them?” The stakeholders in the room are rarely the people who will live with the result. The decision is often made by people who will never use the thing, for people who were never asked. Surfacing the affected-but-absent early prevents the late, expensive discovery that the design everyone signed off makes the actual users’ jobs worse.
“What have you already tried?” This is the question that respects their intelligence and saves you from proposing what already failed. There is almost always history — a previous attempt, a tool they bought and abandoned, an approach that did not take. Understanding what did not work, and why, is worth more than any greenfield assumption, and walking in as though the problem is brand new tells them you have not listened.
Listening for what is not said
The other half of discovery is not in the questions at all. It is in hearing the things people do not say directly — the hesitation when you raise budget, the stakeholder who goes quiet when a particular system is mentioned, the constraint that gets mentioned once and waved away. These are the signals that the official story and the real story differ, and the real story is the one that determines the project’s fate.
The discipline is resisting the urge to fill silences and to start solving. The moment you begin proposing, you stop learning, and discovery is for learning. I have trained myself to ask the question, then actually stop talking, because the most important thing the other person says is frequently the thing they add after the pause, once they realise I am genuinely waiting rather than queuing up my pitch.
Why this connects to everything else
Discovery is where I learn whether a project is the kind of thing I can build well — and increasingly, whether the knowledge and tools I already have make it something I can assemble from validated pieces rather than invent from scratch. A good discovery call does not just scope the work; it tells me which of the problems I have already solved this one resembles, and that recognition is half the value I bring. The compounding I care about across the whole of my work starts here, in understanding the problem well enough to know what it is like.
It also sets the honesty of the whole engagement. If discovery establishes a shared, specific understanding of the problem and what success means, then every later conversation has a foundation to stand on. If it does not, every later conversation is really an argument about the thing nobody pinned down at the start, conducted in the more expensive currency of build time.
The hour that pays for itself
I have stopped thinking of the discovery call as the preamble to the real work and started treating it as the real work, or at least the part that decides whether the real work succeeds. An hour of genuine understanding at the start saves weeks of building the wrong thing well. The questions are not clever and the technique is not complicated. It is mostly the discipline to ask why instead of what, to walk a proposed solution back to its actual problem, and to stay quiet long enough to hear the thing that was not in the brief.
Every project I have seen go wrong, I can trace back to a question I did not ask at the beginning. So I ask them now, deliberately, every time — because the cheapest place to fix a misunderstanding is in the first conversation, and the most expensive place is everywhere else.