Software buyer preparation
What Happens During a Software Discovery Workshop?
A software discovery workshop helps the business and development team agree what problem is worth solving, what is known and what needs investigation. Its useful output is a clearer decision and a practical next step, not an automatic commitment to build.
Use the workshop to resolve a decision
Before inviting people, state the decision the session must support. You might need to decide whether to build, what the first release should achieve or which integration uncertainty to test. These require different evidence from a meeting intended only to gather feature requests.
GOV.UK discovery guidance emphasises understanding the problem, users and constraints before committing to a service. A private software workshop can use that principle without adopting a government delivery process.
A workshop is one activity within discovery. It cannot establish every user need or prove an integration merely through discussion. Agree any interviews, observation or technical checks needed afterwards.
Bring the people who know the work
Include someone who performs the task, someone accountable for its outcome and the people who can explain relevant systems and decision rules. Add support, security or specialist reviewers where the proposed work warrants their input. A sponsor's view alone may miss the exceptions handled by staff every day.
Prepare a sanitised example of a normal task and one that failed. Bring current forms, status definitions, known constraints and a list of unresolved questions. Do not include production credentials or unnecessary personal data in a shared workshop pack.
Use the portal brief for a customer-facing project or the integration preparation guide for a system connection. Unknowns are useful inputs when clearly labelled.
Walk through the work before drawing the solution
- Confirm the problem: describe the user, task and observable consequence of the friction.
- Map the current journey: follow information, decisions, handovers and corrections.
- Examine exceptions: identify delays, missing data, denied actions and unowned failures.
- Explore options: consider process changes, existing products and a focused custom build.
- Select a first outcome: define the smallest complete result worth testing or delivering.
- Assign next actions: name the evidence, owner and decision each follow-up must support.
This is a suggested agenda, not a fixed LCR package or duration. Adapt the session to the uncertainty and the people who need to resolve it.
Leave with decisions and evidence gaps
Expect a concise record of the problem, workflow, options, first-release boundary, assumptions and dependencies. For each unanswered question, record who will investigate it and how the answer could change the decision. Keep disagreements visible instead of writing a falsely unanimous summary.
Hypothetical example: a team asks for a reporting dashboard. Mapping the work reveals that staff spend their time correcting inconsistent source records. The next step becomes testing a controlled data intake process, not building more charts. The workshop identifies that possibility; the follow-up evidence must establish whether it is the right intervention.
Distinguish an illustrative screen from an agreed requirement, and an estimate from a committed delivery plan. Use the prototype and MVP comparison to decide whether the next investment should test an assumption or serve real users.
Decide whether to build, investigate, simplify or stop
A useful discovery outcome can be a narrower scope, a technical experiment, an existing product or a decision not to proceed. It should explain why the next step is justified and what evidence would cause the team to reconsider.
Ask the team to estimate only at the level the evidence supports. Unresolved system access, business rules or approval responsibilities can affect both price and duration. AI-assisted research or note preparation may help, but generated summaries still need participant review and must not convert assumptions into facts.
If a build is justified, turn the agreed boundary into the project scope. If you are still selecting a team, use the development partner guide. Discuss the proposed session and expected outputs with LCR before assuming a specific discovery service is included.
Sources and review date
Primary guidance reviewed on 9 September 2026 is linked beside the claims it supports. Checklists and examples are planning aids, not measured research or client results. Examples are hypothetical. Confirm delivery scope, estimates and any specialist-review needs with the responsible team.
Questions
Frequently asked questions
Is a discovery workshop the same as a full discovery phase?
No. The workshop brings people and evidence together; further user research, technical checks or specialist reviews may still be needed.
Will we receive a fixed price immediately afterwards?
Not necessarily. The usefulness of an estimate depends on the remaining uncertainty. Agree what can be estimated and which questions need evidence first.
Prepare a useful conversation
Bring the task and the unanswered questions.
Discuss the current workflow, source systems and first useful outcome with LCR Technologies.