---
name: agile-discovery
description: Use when asked to run the discovery track of dual-track agile — validating what to build before building it, via problem identification, user personas, and prototyping — as the track that runs alongside, not before, delivery (see agile-delivery), and feeds product-management's broader discipline.
---

# Agile Discovery

Discovery is the process of identifying, defining, and validating what a
product or feature should actually be — before committing engineering
effort to building it. In **dual-track agile**, discovery runs as a
continuous track alongside the delivery track (see
[[agile-delivery]]), rather than as a one-time upfront phase that
finishes before delivery starts: discovery is always a sprint or two
ahead, validating what delivery will build next.

## The discovery process

1. **Identify the problem** — what does this solve, really? Market
   research, customer conversations, and analysis of existing solutions
   ground this in reality rather than internal assumption (see
   [[voice-of-the-customer]] for the customer-feedback side of
   this).
2. **Define user personas** — fictional but research-grounded
   representations of the target audience, clarifying whose needs and
   goals the solution actually has to serve.
3. **Brainstorm potential solutions** — generate options against the
   personas' needs (see [[ideation]], [[brainstorming]]),
   evaluating each for feasibility, desirability, and viability — the
   three-part test commonly used to judge whether an idea is actually
   worth building.
4. **Prioritize features** — what do users actually want, using research
   or a prioritization framework such as MoSCoW.
5. **Create prototypes** — low-fidelity wireframes or a working
   high-fidelity prototype, tested with real potential customers before
   committing to full build effort.
6. **Iterate** — gather feedback on usability, functionality, and appeal,
   and refine based on what's actually learned, not just the first
   prototype's reception.
7. **Develop a product roadmap** — once the feature set is validated,
   translate it into milestones, timelines, and priorities feeding
   delivery.

## Why discovery and delivery run in parallel, not sequentially

A strict "discovery phase, then delivery phase" split risks two failure
modes: delivery sitting idle waiting on discovery to fully finish, or
discovery rushed to unblock delivery before ideas are actually validated.
Running discovery continuously, staying a step ahead of delivery, means
delivery always has validated work ready to build while discovery keeps
investigating what comes next — validated ideas flow from discovery into
delivery's backlog continuously rather than in one large upfront batch.

## Relationship to product management

Discovery is the concrete, ongoing activity that [[product-management]]'s
"discovery vs. delivery" framing describes at a more general level — this
skill covers the specific process steps; product management covers the
broader strategic context (prioritization frameworks, success metrics)
discovery operates within.

## Common pitfalls

- **Treating discovery as a one-time phase before "real work" starts** —
  defeats dual-track agile's whole premise; discovery should be
  continuous, staying ahead of delivery rather than finishing before it.
- **Skipping prototyping and validation** — building based on internal
  assumption rather than tested prototypes reintroduces exactly the risk
  discovery exists to reduce.
- **Personas built from assumption, not research** — see
  [[user-centred-design]]'s identical warning; an unvalidated
  persona gives false confidence rather than real insight.
- **Discovery that never feeds delivery** — validated ideas that stay in
  discovery indefinitely, never translated into a roadmap delivery can
  act on, produce research without outcome.

## Learn more

- [[agile-delivery]] for the parallel delivery track discovery feeds.
- [[product-management]] for the broader strategic discipline discovery operates within.
- [[voice-of-the-customer]], [[user-centred-design]] for the customer-research methods discovery draws on.