Product discovery should establish whose problem matters, how it is handled today, why existing options are insufficient and which assumptions could make the proposed solution fail. It should end with evidence, a bounded first release and a reasoned decision to proceed, change direction or stop—not simply a larger feature list.
“We need a portal”, “we should add AI” and “let’s build an app” are possible starting points for a conversation. They are not yet enough information to choose a sensible implementation. A team can build the requested feature correctly and still solve the wrong problem.
Discovery is the work of reducing that uncertainty before committing heavily to delivery. This guide explains the questions it should answer and the tangible evidence a business should receive.
- A requested feature is a proposed solution, not yet a validated problem.
- Test the most consequential uncertain assumption before polishing the interface.
- Discovery is successful when it improves the decision, including a decision not to build.
What problem are you actually trying to solve?
Describe the affected person, the task, the current difficulty and its consequence. “Customers need an app” contains a solution but no explanation. “Customers call repeatedly because they cannot see whether their documents were accepted” identifies a problem that several solutions might address.
GOV.UK’s discovery guidance starts with understanding the problem, users and constraints before building a service. Its context is public services, but the distinction is useful for commercial products too: discovery establishes whether and how to proceed, rather than assuming the requested build is already justified.
Separate what is known from what is believed. Support records might establish that status questions are frequent; they may not establish that customers want another login. Write both statements down with their evidence status.
How does the work happen today?
Map the current task from the user’s first need to the completed outcome. Include emails, spreadsheets, phone calls, approvals and work performed outside the visible application. The largest delay may be a policy decision or a missing handover rather than a missing screen.
Speak with the people doing and receiving the work. Ask them to describe a recent real occurrence, including exceptions. “Would you use this feature?” invites speculation. “What happened the last time a document was rejected?” is more likely to uncover practical constraints.
GOV.UK’s user research guidance emphasises understanding what users are trying to achieve and how they do it now. Use that as a starting discipline, then investigate the specific operations and commercial conditions of the business.
Which assumptions could make the idea fail?
List assumptions about demand, usability, data, integration, operations and economics. Then ask what would happen if each assumption were false. The most important experiment is often the one that could invalidate the project’s central benefit.
A customer dashboard may depend on a source system that cannot provide reliable status. An automated quote may depend on pricing rules that staff currently interpret differently. A polished prototype cannot resolve either uncertainty on its own.
Choose a proportionate test for each assumption. A prototype can test whether people understand a flow. A technical investigation can establish whether an API exposes the required information. A manual trial can reveal the real cost of an operational process.
| Uncertainty | Useful investigation | Evidence to retain |
|---|---|---|
| Do people have the problem? | Review recent cases and interview affected users | Observed task, consequence and frequency limits |
| Can they use the proposed flow? | Task-based prototype test | Confusion, errors and successful paths |
| Can systems support it? | Small integration investigation | Actual permissions, data and failure modes |
| Can the business operate it? | Walk through routine and exceptional cases | Ownership, effort and escalation rules |
What should a prototype prove?
Give a prototype one or two explicit questions. For example: can a customer distinguish “received” from “approved”, and do they understand what action is needed after rejection? A prototype designed to impress stakeholders often hides the very uncertainty discovery should expose.
Match its fidelity to the question. A paper flow can expose confusing terminology; realistic interactions may be needed to test an upload or a complex comparison. Avoid connecting to production data when representative test information can answer the question safely.
Record where the prototype is simulated. A convincing demonstration of an AI answer or live status update is not evidence that the underlying system can reliably produce it. Keep technical feasibility work alongside the experience test.
How do you choose the first release?
Select the smallest complete outcome that is valuable and operable. “Build the dashboard shell” may be a development milestone, but it does not necessarily let a customer achieve anything. “Let a customer see one request’s current status and resolve a missing-document issue” is a bounded outcome.
Include the supporting work: permissions, source data, error states, notifications, support ownership and measurement. A thin interface over an unreliable process can generate more confusion than it removes.
Define what is excluded and why. Record the conditions that would justify adding a deferred feature. This prevents every suggestion from turning into an immediate requirement and makes scope decisions understandable later.
What should a discovery deliverable contain?
Expect a concise problem statement, a current-workflow map, research observations, prioritised assumptions, test results and unresolved questions. Add the proposed first release, major dependencies and the measurement plan. Each recommendation should be traceable to evidence or an explicitly stated assumption.
Include an options comparison. Improving the current process, configuring an existing tool and building custom software may all be legitimate choices. Compare their fit, operating implications and constraints rather than presenting custom development as the inevitable conclusion.
Avoid false precision in early estimates. State the assumptions behind the range and identify which unknowns could change it. A confident fixed number based on an untested integration is less useful than an honest range with a clear investigation plan.
When is discovery finished?
Discovery is complete when the team has enough evidence to make the next commitment responsibly. That does not require knowing every future feature. It requires understanding the main problem, testing the highest-risk assumptions and agreeing how the next stage will be evaluated.
An illustrative outcome might be deciding that automatic status emails and a small update to an existing portal address the immediate problem. A new app could remain unnecessary. Another project may justify a custom application because existing tools cannot support the required permissions or workflow.
Neither outcome is a failure. SystemVale’s discovery work is intended to clarify the decision and its reasoning. The useful output is a plan the owner can challenge and the delivery team can implement, with remaining uncertainty made visible.
Your next steps.
Describe the problem without naming a technology or feature.
List the assumptions that could invalidate the proposed solution.
Test the highest-risk assumption and write the next decision with its evidence.
A little more clarity.
Is discovery needed for a small feature?
It can be lightweight. The amount of work should match the uncertainty and consequence of getting the decision wrong. A small wording fix may need a brief review; a seemingly small integration can require deeper investigation.
How long should product discovery take?
There is no universal duration. Set a time box around the important unanswered questions and available evidence. Extend it only when the unresolved issue materially affects the next decision.
Is an MVP the same as a prototype?
No. A prototype explores a question and may simulate important behaviour. A minimum viable product is a usable release that must meet its real operational responsibilities, including permissions, support and failure handling.
Check the sources.
Primary references for the technical guidance above. Checked 12 October 2026.
Written by SystemVale
Practical guidance on software, AI and automation across our five core practices.
Explore Discovery & Decisions →
