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
Ask 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.
Inspect 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.
Write a testable assumption
A useful discovery record says what would change the plan. The following YAML is a workshop artifact, not executable configuration. Its acceptance conditions are proposed criteria for this example and must be agreed with the client.
decision: whether_to_build_customer_status_page
assumption: warehouse_events_can_answer_where_is_my_order
checks:
- Trace a redacted order from warehouse event to support answer
- Identify missing, duplicate, and out-of-order events
- Ask a customer to interpret a prototype status message
required_evidence:
- event_definitions_confirmed_by_operations
- freshness_and_failure_behavior_documented
- unresolved_questions_assigned_to_owners
alternatives:
- improve_support_status_lookup_first
- show_last_confirmed_update_with_contact_route
owner: product_lead
outcome: pending
Keep prototype evidence in proportion
A prototype can reveal that participants misunderstand a label or cannot find a next step. It cannot prove that a production integration will deliver timely events. A technical spike can show that one sample payload is handled; it cannot establish the behavior of every carrier or exceptional order. Record those boundaries beside the findings.
Include 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
The handover should contain a narrowed problem, evidence supporting the first release, unresolved risks, acceptance examples, and a delivery sequence. Attach the evidence to the decisions so a new engineer can see why a live tracking map was excluded or why staff tools come first.
Build is one possible outcome. Changing the proposal or stopping can be justified when the data does not support the requested product. Conversely, discovery need not reject the original idea to be worthwhile: confirming an assumption with evidence is different from repeating it. The client should know what was learned, what remains uncertain, and who can authorize the next phase.