What good product discovery looks like for clients
Use discovery to test a costly assumption, map operational constraints, and make an explicit build, change, or stop decision.
Start with an unresolved decision
Suppose a client requests a portal so customers can check order status. The first question is whether the problem is missing access to status, inaccurate warehouse updates, or unclear delivery promises. A portal only addresses some of those causes. This is a hypothetical example, not a reported client engagement.
The GOV.UK Service Manual recommends reframing a proposed solution as a problem and investigating users, context, and constraints. Applied here, discovery should establish which status information exists, who maintains it, and what customers need to decide after seeing it. A feature list alone cannot answer those questions.
Connect interviews to system evidence
I recommend asking support staff and customers to walk through a recent status enquiry using suitably redacted records. Capture the question, the information available at the time, and the action needed to resolve it. Avoid asking whether they would like a portal; agreement does not demonstrate that the proposed workflow helps.
I recommend inspecting a sample integration response in a safe environment alongside that research. A field called “shipped” may mean a label was created, a parcel left the warehouse, or a carrier scanned it. The engineer and operations owner should agree on the meaning before the designer turns it into a reassuring customer message.
Work through evidence that contradicts the proposal
Here is an invented order history, not a sample from a customer or carrier. Assume the operations owner has defined label_created as printing a label, and carrier_accepted as the carrier receiving the parcel. Those definitions are assumptions of this example; a real integration needs its own confirmed meanings.
The carrier acceptance occurred at 09:20 but reached the portal at 09:30. A label-created event occurred at 09:00 but arrived later, at 09:35. At 09:40 the same acceptance event arrives again with the same event identifier. Reading only the latest arrival would make the order appear to move backwards. Counting every arrival as a new milestone would count the duplicate twice.
Within these invented definitions, the history supports “Carrier received the parcel at 09:20.” It does not establish where the parcel is now, when it will arrive, or whether the absence of later events means nothing happened. Sorting timestamps alone would not resolve contradictory event meanings, bad clocks or partial shipments.
I recommend using this contradiction to narrow the decision: test whether showing the last confirmed milestone and a contact route helps customers, rather than authorise a live tracking map from these events. The example justifies investigating that alternative; it does not demonstrate that customers want it or that it reduces enquiries.
Keep prototype evidence in proportion
I recommend keeping different evidence separate. A participant misunderstanding a prototype label is a usability finding, not proof that production events arrive reliably. A successful sample payload is an integration observation, not evidence about every carrier or exceptional order. No interviews or integration tests were conducted for this fictional example.
I recommend including inconvenient cases: partial shipments, cancelled orders, and a tracking feed that has stopped updating. Decide whether the interface should show the last confirmed event, explain uncertainty, or direct the user to support. This is where discovery starts changing scope rather than only describing a preferred happy path.
End with a decision someone can own
For this hypothetical case, I recommend changing the proposal and investigating further before approving production delivery. Ask the operations owner to confirm event definitions and exceptional orders. Ask the integration owner to investigate freshness, duplicate identifiers and out-of-order delivery using suitably redacted real records. Assign someone to test whether customers can interpret the proposed milestone message.
The sponsor can authorise a bounded next phase once its question, cost limit and stopping condition are agreed. If no trustworthy milestone exists, I recommend improving the staff lookup process before putting status information in front of customers. If a milestone is reliable but does not answer the customer’s question, change the interface or reconsider whether a portal is useful.
GOV.UK’s discovery guidance ends with a decision about whether to proceed to alpha and says not to start building the service in discovery. Its public-service phases are not a required contract for a private project. I recommend borrowing the problem-and-constraints discipline while stating which research or prototype work belongs in the next phase.
This is a proposed decision method for a client sponsor. The fictional history is a reasoning example, not an executed event processor, a carrier specification, customer research or evidence of commercial savings. Agree access, data handling and success criteria before running research on real orders.