Product & discovery
Test the assumption that could change the roadmap
Before turning an idea into a delivery plan, identify the uncertainty that could make the investment worthwhile or unnecessary. The useful discovery result is a better decision, with evidence someone can inspect.
A self-service booking feature sounds straightforward until the booking depends on decisions nobody has examined. Who can authorise the visit? Does the customer know which equipment needs attention? Can the provider promise an appointment before checking parts and technician availability? A feature list can move past those questions while leaving the investment exposed to them.
Consider a hypothetical equipment-maintenance provider planning a customer portal. Its proposed roadmap begins with calendars, reminders and appointment history. The consequential assumption is that customers can choose and confirm a visit without speaking to a coordinator. Discovering whether that is true should influence what gets built first.
Make the decision smaller than the ambition
Write the decision that the next piece of research must inform: should the provider invest in immediate booking, a guided service request or improvements to its existing coordination process? Each option can serve the same commercial ambition while creating different work for customers and staff.
GOV.UK's discovery guidance starts with understanding the problem, users and constraints before committing to a service. Its alpha guidance then concentrates experiments on the riskiest assumptions. [1][2] Those documents describe government delivery practice; the useful method for this business is to separate understanding the problem from testing a proposed solution.
For the maintenance provider, write the assumption in a form that can be challenged: a site coordinator has enough information and authority to confirm a suitable visit. Record what would make that false. A required purchasing approval, uncertain fault diagnosis or unavailable technician might each change the design. Rank these uncertainties by the consequence of being wrong and the evidence currently available.
Look for the circumstances behind the request
Start with recent maintenance requests and the people who handled them. Ask a participant to reconstruct an actual booking: what triggered it, what information was missing, who approved the work and where the conversation stalled. Examine appropriately anonymised examples where permission allows. An account of the last difficult booking can expose a constraint that a general question about desired features would miss.
Recruit people who do or are likely to do the task. GOV.UK recommends defining recruitment criteria around the research question and including the different kinds of people who need the service. [3] For this example, that might mean coordinators at sites with different approval arrangements, alongside the dispatch staff who complete the booking. A convenient group of internal stakeholders cannot stand in for every customer circumstance.
Keep observations separate from explanations. A coordinator pausing to obtain approval is an observation; concluding that every customer needs an approval workflow is an interpretation. Note which situations the research covered, which were absent and what further evidence would change the interpretation. Qualitative sessions can reveal mechanisms and difficulties without establishing how common they are across the whole customer base.
Choose proof that matches the uncertainty
A short interactive prototype could test whether a coordinator understands the difference between requesting a visit and receiving a confirmed appointment. Let the participant attempt a realistic task, including an uncertain date or missing equipment reference. Observe the choices and questions before explaining the intended flow.
GOV.UK describes prototypes ranging from sketches to realistic code and warns that prototype code does not automatically meet production security or performance standards. [4] A convincing interaction therefore leaves other questions open. It cannot establish that the scheduling system will reserve a technician correctly when several customers act at once.
That technical assumption needs a separate, bounded implementation experiment with representative scheduling rules and controlled test data. Check the reservation behaviour, conflicting requests and unavailable dependency. Record what was simulated. A successful prototype supports an interaction decision; a successful technical experiment supports the particular behaviour it exercised. Neither result establishes the complete service's readiness.
Agree what would stop, change or justify the work
Set decision criteria before reviewing the results. Otherwise, an appealing demonstration can become its own justification. The criteria should reflect the investment at stake and the questions the experiments can reasonably answer. For this hypothetical provider, three possible outcomes could be:
- Stop immediate booking if customers cannot make the necessary commitment and changing that constraint would exceed the intended investment.
- Change direction to a guided request if collecting clearer information helps coordination while the provider must still confirm availability.
- Commit to a bounded booking release if the relevant participants can complete the task and the scheduling experiment supports the required reservation behaviour, with remaining risks assigned.
Sources & further reading
The references behind this perspective. Reviewed . Product documentation can change; check the source before making an implementation decision.
- GOV.UK Service Manual — How the discovery phase works
Primary government-method guidance on understanding the problem, users and constraints before a build commitment. Applied here as an editorial method for a hypothetical business, not a universal mandate; checked 21 October 2026.
- GOV.UK Service Manual — How the alpha phase works
Primary guidance on testing risky assumptions with deliberately limited prototypes and deciding which ideas to progress; checked 21 October 2026.
- GOV.UK Service Manual — Finding participants for user research
Primary guidance on recruiting actual or likely users, relevant target groups and question-specific recruitment criteria; checked 21 October 2026.
- GOV.UK Service Manual — Making prototypes
Primary guidance on different prototype forms and the distinction between realistic prototype behaviour and production-quality implementation; checked 21 October 2026.
