What a Discovery Workshop Should Produce

The most valuable output is a record of the decisions taken and — critically — the options rejected and why.

A summary of discussion is nearly worthless three months later. A decision log is what stops the same question being reopened every few weeks, which is one of the largest hidden costs in product work.

Each entry should state the decision, the alternatives considered, the reasoning, and what would justify revisiting it. That last field matters: it converts "we decided X" into "we decided X because Y, and if Y changes, reopen it", which is how a decision stays useful as circumstances change.

The practical test: could a competent team that was not in the room build this?

That requires:

• Roles and permissions — who exists and what each can do.
• Core entities and relationships — the data model in plain language.
• Screens with all their states, including empty, loading, error, and unauthorised.
• Business rules written explicitly, including the awkward edge cases someone raised and everyone remembers differently.
• Integrations, with behaviour defined for when each is unavailable.

A backlog of one-line tickets is not a specification. It is a list of things to figure out later, which is precisely what discovery was supposed to prevent.

Every project has unknowns. Discovery does not remove them; it names them and proposes how each gets resolved.

A useful register separates the types, because they need different treatment:

• Technical unknowns — can this integration do what we assume? Resolved by a time-boxed spike, scheduled explicitly.
• Product unknowns — will users do this at all? Resolved by testing with real people, not by building more.
• Commercial unknowns — is the unit economics viable? Resolved by modelling before committing to the build.
• Regulatory unknowns — resolved by getting an answer before the shape of the product depends on a guess.

Each risk needs an owner and a date. A register without those is a list of worries.

The plan should describe milestones that each produce something you can look at, in an order where the riskiest assumptions are tested earliest.

Two properties distinguish a good plan from a Gantt chart:

• Each milestone stands alone. If the engagement stopped after milestone two, you would have something coherent rather than a half-built system.
• Risk is front-loaded. The thing most likely to be wrong is validated first, while changing course is still cheap.

We consolidate milestones inside a single project rather than splitting them into separate engagements, because the sequencing is the point — each stage builds on the identities, rules, and structures the previous one established.

Signals worth checking before committing:

• The agenda names artifacts, not activities. "Data model and permissions" rather than "ideation session".
• They ask for access to real users or real data beforehand. A discovery run entirely on internal assumptions produces internal assumptions.
• Engineers are in the room, not only strategists. Feasibility questions need someone who will build it.
• They push back on your brief. A discovery that agrees with everything you arrived with has not done its job.
• The output is usable elsewhere. If the specification is only actionable by them, that is a commercial arrangement rather than a deliverable.

Occasionally discovery concludes that the product should not be built as described — the problem is not big enough, the economics do not work, or a much smaller intervention would achieve the outcome.

That is a successful discovery. It is also the one nobody wants to hear, and it is why discovery should be scoped and priced independently of the build. If the same people are paid only when a build follows, the incentive runs the wrong way, and everyone in the room knows it.

The cheapest project is the one you correctly decided not to start.