The early stage of a product or feature project dedicated to understanding the problem space before any solutions are proposed. Discovery combines user research, stakeholder interviews, competitive analysis, and data review to ensure the team is solving the right problem — reducing the risk of building something well-crafted but fundamentally misaligned with real user needs.
Common contexts
- Kicking off a new product initiative by interviewing eight users before any wireframes are sketched
- Revisiting an underperforming feature to understand root cause before scheduling a redesign sprint
- Aligning engineering, product, and design on a shared problem definition before roadmap prioritization
Use when
At the start of any significant feature or product initiative, especially when assumptions about user needs are unvalidated. The larger the engineering investment, the more critical a well-scoped discovery phase becomes.
Avoid when
Don't stretch discovery indefinitely as a way to delay the discomfort of committing to a direction — 'more research' can become a proxy for avoiding hard decisions when the team already has enough signal to act.
Discovery work earns its budget not by producing deliverables but by preventing the team from building the wrong thing confidently — the best outcome is sometimes a single reframed problem statement that redirects months of planned work.
Real-world examples
- GOV.UK's Government Digital Service mandates a formal discovery phase for all digital government services, requiring teams to research user needs before any design or development begins.
- Spotify runs discovery phases when entering new market verticals like podcasts and audiobooks, conducting user research and competitive analysis before committing to product direction.
- NHS Digital uses structured discovery phases to understand patient and clinician needs before building any new health service, preventing costly misdirected development.