A software discovery workshop should end with clearer decisions, rather than a longer feature wishlist. Before scheduling one, identify the investment decision it must support: replacing a spreadsheet, integrating two systems, or testing whether a customer portal is worthwhile. A single meeting cannot establish every requirement, but it can expose the questions that determine feasibility.
The GOV.UK discovery guidance starts with understanding the problem, users and constraints before committing to implementation. For a commercial team, that means separating evidence about today's work from preferences about tomorrow's interface.
Bring evidence and the right people
Invite someone who performs the work, someone responsible for its outcome, and someone who understands existing technology and data. A manager's description can differ from the procedure staff actually follow. Include a decision maker who can resolve conflicting priorities, but avoid filling the room with observers who cannot contribute evidence.
Ask participants to bring anonymized examples: a completed order, a failed approval, a monthly report and a support complaint. Record volumes, waiting times and error types where available. Treat uncertain estimates as assumptions with an owner who will verify them later. Do not place personal customer records into a shared workshop board.
Structure a half-day agenda
Use the opening session to agree on a problem statement and the business outcome. Next, map one ordinary transaction from start to finish, including handoffs outside the proposed software. After a break, examine failures and uncommon cases. Reserve the final hour for priorities, constraints and unanswered questions.
Keep an explicit parking list for attractive ideas that do not affect the immediate decision. A mobile app, forecasting model and loyalty scheme may all be interesting, but discussing them together can conceal a much smaller problem with stock reconciliation. The facilitator should ask what changes for the user if each proposed feature exists.
Worked example: a purchase approval process
Imagine a distributor whose purchase requests wait in email. The workshop discovers that managers approve most requests quickly, but finance cannot tell whether two requests refer to the same supplier quotation. The principal problem is duplicate commitments, not slow button clicking.
Map the quotation identifier, requester, budget owner and final purchase order. Add exceptions for an expired quotation, a changed amount after approval and an absent manager. The first release might enforce a unique quotation reference and record approval history. A supplier portal can remain outside scope until the basic process works.
This example also changes measurement. Counting approvals alone would miss the benefit. Track duplicate requests detected, time spent reconciling commitments and unresolved exceptions. Establish the current baseline before assigning an improvement target.
Turn discussion into a reviewable brief
The brief should contain user groups, the workflow map, an initial permission matrix, integration dependencies and the smallest useful release. Include an assumption register with questions, responsible people and due dates. Show which decisions are reversible and which depend on external contracts or data access.
Translate the highest-priority needs into a few user stories. GOV.UK's user-story guidance connects the actor, need and goal with observable acceptance outcomes. Avoid writing dozens of detailed stories before the team has validated the central workflow.
Decide what happens next
Possible outcomes include a prototype, a technical integration test, a short data audit or a decision to keep the current system. Stopping after discovery can be sensible when the expected benefit is small or a required data source is unavailable.
A successful workshop produces evidence sufficient for the next investment decision. It also leaves a clear record of what remains unknown, so an estimate does not quietly turn assumptions into promises.
Primary references
Related reading
Bring your current workflow to our IT consulting service to define a practical discovery brief.