AI Knowledge Hub

How should a product team run discovery while delivering existing work?

Quick answer

Run discovery alongside delivery by giving each current question a decision it will inform, a small evidence activity and a named owner. Protect enough Product, design and Engineering time to test upcoming assumptions while the team finishes committed work. Feed findings into shaping and prioritisation at agreed review points, and adjust the balance when incidents or urgent delivery work intervene.

What to remember

Key takeaways

Frame discovery as a decision, not an endless research queue.
Include Engineering where feasibility or risk is uncertain.
Make discovery work visible in the team’s capacity.
Let evidence change future commitments before they harden.

An enduring team must improve today’s product and decide what to do next. If discovery waits until delivery stops, the next feature may arrive without evidence. If discovery consumes every specialist, current commitments suffer.

Define the next decision to inform

Discovery is the work of reducing uncertainty about users, value, constraints and possible approaches before or during a commitment. For each question, state what the team needs to decide and what evidence would change the answer. A short interview round, prototype, data check or technical spike may be enough. GOV.UK discovery guidance describes understanding users, constraints and the wider service before building. Its phases are a government service model; ongoing product discovery can use the same reasoning without following a formal phase sequence.

Use familiar research and planning practices

Teams often run research as a separate project or schedule it only before a roadmap cycle. This can work for a new or major service decision, but a live product also needs learning while delivery continues. GOV.UK user research guidance recommends small batches of research through development and live operation. Use an existing planning cadence to review the next research question, the work in progress and the decision date. Do not turn every idea into a full study.

Connect discovery to delivery choices

Product frames outcome and priority. Design or research leads appropriate user evidence; Engineering tests feasibility and technical unknowns early enough to influence the option. Bring the result into feature shaping: proceed, change direction, investigate further or stop. Record evidence quality and unresolved assumptions. A prototype that users understand does not prove it can be delivered safely; a successful technical spike does not establish demand. The team needs both perspectives before making a costly commitment.

Protect capacity and review the balance

Allocate explicit capacity for discovery and for delivery, including the people who must participate in both. Limit simultaneous questions so findings can be acted on. An incident or release may temporarily change the balance; reschedule the affected discovery work rather than leaving it invisible. Review whether decisions were made with sufficient evidence, whether work was abandoned too late and whether discovery activities delayed urgent service needs. Adjust the cadence to the product’s risk and pace.

Example

Hypothetically, a housing service team is finishing a repair-notification change while considering appointment rescheduling. Product names the decision: whether self-service rescheduling solves the main problem. Research speaks with residents and call handlers; Engineering checks supplier integration constraints. At the next planning review, the team decides to test a simpler notification improvement before committing to a new workflow.

FAQs

Does every team need a separate discovery team?

No. The same product team can reserve time and draw on specialist research support as needed.
Should developers attend every interview?

No. Involve Engineering where technical assumptions or shared understanding would affect the decision.
What if delivery pressure removes discovery time?

Make the trade-off explicit, protect the most important learning activity and set a date to revisit the deferred question.