The decision
Discovery is useful when it changes a decision. Its output should explain who does the work, which problem matters and what evidence will establish a successful outcome. A collection of meeting notes cannot replace agreed boundaries.
A worked example
Imagine a distributor replacing emailed quote requests. Follow one ordinary request and one with an unavailable item. Record the requester, approver, price owner, response deadline and correction path. Compare what staff say with a redacted real example; disagreements reveal requirements that a feature list misses.
Trace a decision from request to consequence
During observation, ask the person doing the work to show the last awkward case they handled. Replace personal details before sharing it. Capture the starting evidence, the judgement made, the next recipient and what would happen if nobody acted. In the quote-request example, a missing supplier price may be less important than uncertainty over who can promise a delivery date. Mark that as a decision requiring an owner rather than immediately proposing another screen. This keeps discovery focused on the work that must become reliable, including work currently carried by memory or informal relationships.
Leave with artefacts another team can use
A useful discovery pack contains a workflow with exception branches, a vocabulary for important records, access rules, sample inputs, acceptance examples and a list of external dependencies. Keep a decision log showing what was chosen, why and what evidence would reopen it. An estimate should refer to those artefacts rather than rely on the memory of the workshop participants. Give unresolved items an owner and a next action; “to be confirmed” without either is not a managed uncertainty. The pack should remain understandable when the person who commissioned it is absent.
Define the stopping point before the workshops
Discovery has diminishing value when the same conversation repeats without producing new evidence. Set completion around a decision: the team can explain the proposed workflow, demonstrate the most uncertain interaction, identify technical blockers and describe an acceptable first release. Record a reason to stop or change direction if an essential assumption fails. Ask a person who did not attend the workshops to read the pack and describe what will be delivered. Their misunderstandings expose gaps cheaply. This review does not remove uncertainty; it makes the remaining uncertainty visible enough to price, test or deliberately accept.
Alternatives worth weighing
Interviews explain intent, observation reveals workarounds, and a prototype tests whether a proposed interaction makes sense. Use a technical experiment only for an unresolved feasibility question. Each activity should answer a named uncertainty rather than fill a prescribed workshop schedule.
Where the plan breaks
Avoid declaring every stakeholder request equally necessary. Separate legal or contractual constraints, operational needs and preferences, then assign each an owner. If records cannot be shared, use representative synthetic examples without pretending they prove production data quality.
Before you commission the work
Ask what will change after discovery: a go/no-go decision, an estimate range, a workflow or an integration choice. Request a decision log, unresolved questions and testable acceptance examples. These make the next custom software discussion concrete.