Why Discovery Sessions Fail — and How to Run One That Doesn't

The Discovery Session as a Ceremony

Many organisations run Discovery Sessions as a ceremony — a scheduled event that produces a document, reassures the stakeholders that the project has been properly started, and is then filed and not meaningfully consulted again. A ceremonial discovery session costs roughly the same as a genuine one and produces almost none of the value. The difference between the two is not the format or the duration. It is the quality of the questions asked and the willingness to let the answers change what gets built.

The defining characteristic of a genuine discovery process is that it is allowed to produce uncomfortable outputs. If the discovery process only ever confirms the plan that was already in place before it started, it was not a discovery — it was a validation exercise. The most valuable discovery sessions are the ones that result in a significantly different scope than was originally planned. The Agile Manifesto's principle of responding to change applies to discovery outputs as much as it does to software requirements.

The Most Common Failures

In our experience running discovery sessions for 80+ service businesses, these are the patterns that produce poor outputs:

• The brief was written before the session started. When a client comes to a discovery session with a solution already decided, the session becomes negotiation rather than inquiry. The output is a dressed-up version of the original brief.
• The wrong people are in the room. Decision-makers who do not do the operational work, and operators who do not have the authority to change the process, produce a session that generates neither accurate understanding nor actionable decisions.
• The facilitator leads rather than follows. A facilitator who brings hypotheses into the room and tests them is doing the wrong kind of work. The job is to create conditions for the people who live the problem to describe it accurately — not to confirm the facilitator's model of it.
• The output is descriptive rather than prescriptive. A discovery output that describes the current state without specifying the desired future state and the gap between them is incomplete. "Here is how things work now" is only useful if it leads to "here is what we will change, and why."

The Questions That Actually Matter

The questions that produce the most value in a discovery session are the ones about failure, not about process. "Walk me through what happens when this breaks" produces more insight than "walk me through how this is supposed to work." The designed process is documented somewhere. The failure modes are known only to the people who have lived them.

Other questions worth asking in any discovery session: "What would you stop doing if you could?" (reveals hidden costs), "Who else is affected when this goes wrong?" (reveals hidden dependencies), "What have you already tried?" (prevents re-proposing solutions that have already failed), and "What does a good week look like?" (anchors the solution in aspiration rather than just problem-fixing).

Facilitating Without Leading

The facilitator's job is to create the conditions for clarity, not to supply it. This means asking questions rather than making statements, summarising what was said rather than interpreting it, and explicitly distinguishing between "what the participants said" and "what the facilitator thinks it means." These distinctions are harder to maintain than they sound — the natural instinct is to fill silence with hypothesis.

From Insights to a Scoped Brief

The gap between a successful discovery session and a useful brief is where most discovery processes fail. The session produces a rich record of insights, observations, and requirements. Converting that into a document that a development team can build from requires a separate synthesis step — usually done with fewer people and more time than the session itself.

The synthesis step should produce three things: a problem statement that everyone involved would sign off as accurate, a solution scope with explicit boundaries (including what is out of scope), and a set of success criteria that can be evaluated without ambiguity. The last of these is the hardest and the most valuable. Success criteria that depend on subjective judgment are not criteria — they are deferred arguments.

What Happens After the Session

The brief is only the beginning. A discovery output that is filed and not revisited is a sunk cost. The brief should be a living document that is consulted at every significant project decision point — when scope changes are proposed, when priorities shift, when the project is running over time or budget. It is the record of what was decided, and why, and should be used as such.

If you are considering running a structured discovery process for your next project, talk to us about how we approach it. We have run this process in 15+ industries with teams of 3 to 300 people. The format adapts; the discipline does not.