How should a product team connect discovery with delivery?

A team can do careful research and still lose its findings when work becomes a delivery ticket. It can also build quickly while leaving the real user problem uncertain. The connection between discovery and delivery is a sequence of decisions, not a one-time handover.

Treat discovery and delivery as linked decisions

Discovery reduces uncertainty about who has a problem, why it matters and which response may help. Delivery turns a chosen response into something usable and supportable. The team need not wait for every uncertainty to vanish before building, but should know which assumptions are still open. For each important assumption, record the evidence, the next test and the Product decision it informs. Keep the problem statement and outcome visible in the work being delivered.

Use the strengths of established methods

Research plans, prototypes, backlog refinement and acceptance criteria can all carry learning forward. A research report is useful when its observations and limits are accessible to those shaping work. A backlog ticket is useful when it retains enough context to make a choice. A strict phase gate can protect investment in high-consequence work, yet it may leave fresh delivery learning out of the original decision. The GOV.UK Service Manual’s discovery guidance emphasises user problems and constraints before committing to build; its service phases are one context, not a universal organisation chart.

Create short feedback loops between roles

Product names the decision and what evidence would change it. Design and Research show what users did or said and distinguish observation from interpretation. Engineering explores technical options, constraints and the effort of learning safely. In a short joint session, decide whether to continue research, run a limited test, build a small increment or stop. Keep the person accountable for each decision visible. When delivery exposes a new constraint, bring it back to the problem and option discussion rather than quietly implementing a different solution.

Keep the loop open after release

Check whether the change is used and whether the intended user or business outcome moves, while monitoring reliability and support burden. A successful deployment proves only that a change was released. If evidence is weak, choose an additional observation or a revised intervention; if the problem has changed, reconsider the investment. Protect time for discovery amid delivery pressure, but avoid research without a decision to inform. Record unresolved assumptions so they are not mistaken for facts by the next team.

Example

Hypothetically, a university team believes students abandon a timetable flow because dates are unclear. Research observes confusion but also finds slow loading on older phones. Engineering tests the performance constraint while Design prototypes clearer date labels. Product decides to release a small wording change and investigate performance separately. After release, the team reviews usage and support contacts before deciding which improvement to fund next.

FAQs

• Must discovery finish before delivery begins?

  No. The team needs enough evidence for the next responsible decision and should keep learning as it delivers.

• Who decides to stop a proposed feature?

  Product owns priority and value decisions, informed by user evidence and Engineering’s account of cost, risk and alternatives.

• Can a prototype replace user research?

  A prototype helps test an option when observed with relevant users. It does not by itself prove the problem or expected outcome.