Agile Discovery
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.
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
- 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).
- Define user personas — fictional but research-grounded representations of the target audience, clarifying whose needs and goals the solution actually has to serve.
- 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.
- Prioritize features — what do users actually want, using research or a prioritization framework such as MoSCoW.
- Create prototypes — low-fidelity wireframes or a working high-fidelity prototype, tested with real potential customers before committing to full build effort.
- Iterate — gather feedback on usability, functionality, and appeal, and refine based on what's actually learned, not just the first prototype's reception.
- 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.