There is a category of project failure that does not appear in post-mortems. The designs were good. The sprint went well. The product shipped on time. And yet six months later, the metrics have not moved, because the problem that was solved was not the problem that needed solving. Discovery exists to prevent this. It does not always succeed.

The brief as hypothesis

Every project brief contains a hypothesis about the problem. Sometimes it is explicit. More often it is embedded in the framing of the solution: a request for “a better onboarding flow” assumes that onboarding is the problem; “a redesign of the dashboard” assumes that the dashboard is what users are struggling with. The first job of a discovery phase is to treat the brief as a hypothesis and design a process that could falsify it.

This is not a comfortable position to occupy. Stakeholders who have invested weeks in writing a brief do not welcome the suggestion that its premise may be incorrect. The discovery phase has to earn the right to reframe, and that takes time that is not in the original estimate.

The discovery phase has to earn the right to reframe. On stakeholder trust in research

What discovery actually costs

The cost of discovery is not the research itself. The cost is the delay it imposes on the delivery timeline and the uncertainty it introduces into a plan that stakeholders have already committed to. Both of these are real costs, and dismissing them as “resistance to process” misses the point. The question is not whether discovery is worth doing but whether it is worth doing at the scale the problem requires.

A two-week discovery phase is rarely sufficient for a problem that has been present in an organisation for three years. The problem did not survive that long because it was overlooked. It survived because it is load-bearing in ways that a two-week engagement will not fully expose. This is the structural issue: the complexity of the problem is inversely proportional to how willing anyone is to spend time understanding it.

---

On presenting incomplete findings

Discovery findings are almost never complete when the project timeline requires them to be. The choice between “wait until we know more” and “present what we have” is a recurring one, and there is no general answer. What matters is that the degree of confidence is communicated explicitly and that the recommendations are calibrated to the evidence that exists, not the evidence that was hoped for.

A note on timing

The right moment to raise the discovery timeline question is not at the start of the project. It is before the brief is written. If discovery is built into the project scope from the outset, it does not need to be justified after the fact. The constraint is that this requires the design team to be involved in scoping conversations, which is not standard practice in most organisations and has to be established deliberately.

What I have learned from fourteen years of practice is that the projects where discovery was given adequate time are the ones where the outcomes were genuinely different from what the brief anticipated. That difference is not always visible in the metrics. But it is always visible in the quality of the problem that was solved.