The short answer: discovery must end in a decision, not a deck
A software discovery phase should establish whether a valuable, feasible, and operable problem is worth solving now. It needs evidence about the users, current workflow, cost or consequence, constraints, solution options, riskiest assumptions, and the smallest complete release. Its final output is a clear decision: build, narrow, test, configure or buy, delay, or stop.
Do not measure discovery by workshops held or documents created. Measure it by the important uncertainty removed and the commitment the team can responsibly make next. A polished backlog built on untested assumptions is still uncertainty wearing estimates.
Evidence
Observed work, needs, constraints, and value.
Decision
Build, narrow, test, buy, delay, or stop.
Commitment
One release boundary with owners and proof.
Before starting, name the decision and the evidence gap
“Discover the new platform” is too broad. Write the decision the sponsor expects to make: for example, “Should we replace the manual supplier-onboarding workflow, and what is the smallest release worth funding?” Then list what would change that decision.
Agree a decision owner, working team, access to users and systems, known deadlines, confidentiality boundaries, and a review date. Bring operations, product, design, and engineering perspectives early enough to challenge each other. Technical feasibility without user evidence can automate the wrong work; user demand without operational ownership can create a service nobody can run.
If a product direction is already proven and the remaining job is trimming a large feature list, use the more focused MVP scope checklist. Discovery is for the earlier point where the problem, option, or feasibility still needs evidence.
Use seven evidence lanes to keep discovery decision-shaped
| Lane | Evidence to seek | Decision it supports |
|---|---|---|
| Problem and value | Trigger, consequence, frequency, baseline | Is this worth solving now? |
| Users and work | Observed jobs, variations, barriers, support | Whose complete journey matters? |
| Current system | Steps, handoffs, data, tools, exceptions | What must change—and what must remain? |
| Constraints | Policy, contracts, access, legacy, deadlines | Which paths are viable? |
| Options | Process, buy, configure, integrate, build | What is the smallest sensible intervention? |
| Risk | Assumptions with high consequence and low evidence | What must be tested first? |
| Release | One end-to-end flow, acceptance, ownership | What can the team commit to next? |
Research the real work, including exceptions and support
Interviewing stakeholders is a start, not the whole evidence base. Observe representative users completing the current task. Review forms, spreadsheets, inboxes, support tickets, analytics, policy, and existing system behaviour. Map the happy path, but spend time on rework, missing information, approvals, escalations, overrides, offline steps, and people who need assistance.
The official GOV.UK guidance on user research in discovery recommends examining the end-to-end service, including support and offline interactions, and using evidence such as observation, interviews, analytics, back-office workflow, and support logs. That principle translates well beyond government services: the screen is only one part of the work.
Record evidence separately from interpretation. “Three operators copied the same order details into two systems” is an observation. “We need a custom workflow engine” is a solution hypothesis. This separation keeps a familiar technical answer from becoming the premise of the research.
Turn constraints and assumptions into explicit tests
Map system access, data quality, identity, integrations, security, accessibility, legal or contractual rules, operating ownership, migration, peak demand, and deadlines. Classify each as hard, negotiable, or merely assumed. A vendor contract may be hard for this release; an inherited approval chain may be open to redesign.
Rank assumptions by consequence if wrong and confidence in the evidence. Test the high-consequence, low-confidence items first. That may mean a technical spike against a real API, a low-fidelity workflow prototype, a data sample, a policy review, or observing a rare but costly exception. Do not prototype the easiest screen merely because it looks like progress.
For a workflow currently held together by spreadsheets, use the spreadsheet-to-internal-tool decision guide to compare governance, SaaS, low-code, and custom paths before assuming a new application is required.
Reduce the option space before estimating the build
Compare at least the credible non-build and build paths: improve the process, configure an existing product, integrate systems, build a focused custom boundary, or defer. Judge them against user value, operational fit, feasibility, ownership, time pressure, reversibility, and the cost of getting the decision wrong.
GOV.UK's discovery-phase guidance makes a useful boundary explicit: discovery is for understanding the problem, users, constraints, opportunities, and whether to continue—not for starting the build. It also treats stopping as a valid result when the evidence does not justify further work.
Demand deliverables that remain useful after the workshop
A discovery package should be proportionate. A focused workflow may need one decision brief, current-state map, risk test, and release outline. A multi-party platform may also need service blueprints, data and integration context, prototypes, accessibility findings, security assumptions, and architecture options.
At minimum, the buyer should be able to review:
- the problem, decision owner, affected users, and success evidence;
- the current end-to-end workflow, variations, exceptions, and baseline;
- constraints, system and data context, assumptions, and unresolved risks;
- considered options and the evidence behind the recommendation;
- one complete first-release flow with exclusions and acceptance evidence;
- estimate assumptions, dependencies, owners, and the next review gate.
Avoid treating a prototype as proof of backend feasibility, an estimate as a guarantee, or a large backlog as completeness. Every artifact should state what is known, inferred, assumed, and still untested so a future delivery team can judge it honestly.
Finish with one reviewable software discovery exit brief
Complete the brief in plain language. Name the decision, strongest evidence, complete workflow, recommended path, release boundary, excluded work, acceptance evidence, remaining risks, dependencies, owners, estimate assumptions, and next gate. Link to deeper research rather than making the brief itself unreadable.
Before approving development, ask one final question: what evidence would make us reverse or resize this recommendation? If nobody can answer, the team may be defending a solution rather than making a decision from evidence.
When that decision becomes a competitive procurement, carry the evidence forward with the software development RFP checklist. It turns the discovery boundary into comparable partner assumptions, proof, ownership, and commercial responses.
Software discovery phase FAQ
What is included in a software discovery phase?
A useful software discovery phase defines the business problem and decision, researches users and the current workflow, maps constraints and existing systems, tests high-consequence assumptions, identifies viable solution paths, scopes the smallest complete first release, records delivery and operating risks, and ends with an evidence-backed recommendation and next step.
What should a software discovery phase deliver?
Deliverables should support a decision. A concise package normally includes a problem and success statement, user and workflow evidence, system and data context, assumptions and risk register, option comparison, prioritized first-release flow, acceptance evidence, architecture or integration notes where needed, ownership, estimate range assumptions, and a build, narrow, test, buy, or stop recommendation.
How long should software discovery take?
There is no universal duration. Size discovery by the decisions and risks that must be resolved, access to users and systems, stakeholder availability, regulatory or integration complexity, and the evidence needed for the next commitment. A focused known workflow may need a short workshop and spike; an unfamiliar multi-party service may need several research rounds.
Is discovery the same as writing software requirements?
No. Requirements describe what a chosen solution must do and how it will be accepted. Discovery comes earlier: it verifies the problem, users, workflow, constraints, options, and riskiest assumptions so the team can decide whether to build and what deserves to become a requirement. Some first-release requirements are an output, not the whole purpose.
Can discovery recommend not building custom software?
Yes. A credible discovery can recommend a process change, configuration of an existing tool, integration, smaller experiment, delayed decision, or no build. Stopping or narrowing is a successful outcome when the evidence does not justify custom development.