When the stage becomes relevant
Discover can become relevant when:
- an Opportunity-stage decision authorizes further investigation;
- an organization can describe a concern but cannot explain its causes, affected people, or wider context with confidence;
- stakeholders disagree about the problem or rely on conflicting evidence;
- a requested feature or technology has become the assumed answer before the need is understood;
- an existing product underperforms and the reason remains unclear;
- adoption, support, operational, accessibility, or product-health evidence suggests a deeper problem;
- a change in policy, regulation, strategy, market conditions, technology, or risk may alter user needs or product direction;
- several teams or products address connected parts of the same experience without a shared understanding;
- an evolution or retirement decision depends on understanding a continuing need;
- earlier discovery evidence has become outdated, incomplete, or inconsistent with current conditions.
Discovery does not belong only at the beginning of a new product. A live product can return to Discover whenever the organization needs renewed evidence about the problem or the people affected.
Questions and decisionsRead section
The business problem
- What is happening, for whom, and in what context?
- What consequences does the current condition create for users, the organization, or both?
- Which causes are supported by evidence, and which remain hypotheses?
- Is the stated problem one problem, several connected problems, or a symptom of another condition?
- What happens if the organization maintains the current approach?
People and the wider experience
- Who experiences the problem directly, and who experiences its downstream effects?
- What are people trying to accomplish before, during, and after the relevant interaction?
- Which digital, assisted, operational, and third-party touchpoints shape the complete experience?
- Which groups encounter different barriers, accessibility needs, levels of digital confidence, or consequences?
- How do current workarounds affect users, employees, partners, and support teams?
Evidence and uncertainty
- What qualitative and quantitative evidence already exists?
- How current, representative, reliable, and complete is that evidence?
- Where do sources agree, conflict, or leave important gaps?
- Which assumptions carry the greatest user, business, technical, operational, ethical, or regulatory risk?
- What additional evidence could materially change the next decision?
Context, constraints, and dependencies
- Which policies, processes, technologies, data, contracts, integrations, funding conditions, or organizational structures affect the problem?
- Which constraints are fixed for the relevant decision and which could change?
- Which teams, products, services, vendors, or organizations influence the wider journey?
- What security, privacy, legal, compliance, accessibility, safety, or data-governance obligations require early attention?
- Which current products or initiatives already address part of the need?
Outcomes and next direction
- Which user, business, operational, financial, strategic, or risk-related outcomes could improve if the problem is addressed?
- What baseline evidence is available, and what may need to be measured later?
- Does the evidence support defining a product direction?
- Should the problem be reframed, narrowed, divided, combined, routed elsewhere, investigated further, paused, or stopped?
- Who is accountable for interpreting the findings and deciding what happens next?
Activities and evidenceRead section
Discovery activities should follow the important questions rather than a standard checklist. Useful work may include:
- reviewing the Opportunity-stage evidence, decision rationale, assumptions, and unanswered questions;
- conducting research with users, frontline employees, support teams, partners, and other affected stakeholders;
- observing current tasks, workflows, environments, workarounds, and failure points;
- mapping the wider journey across digital, assisted, operational, and third-party touchpoints;
- reviewing product analytics, support contacts, operational performance, financial data, audit findings, complaints, and prior research;
- examining existing products, capabilities, processes, policies, contracts, and related initiatives;
- establishing or refining baseline measures for the current condition;
- separating direct observations from interpretations, hypotheses, preferences, and solution ideas;
- identifying underserved or excluded groups and investigating accessibility and inclusion barriers;
- assessing data availability, quality, lineage, ownership, permitted use, and evidence limitations;
- involving technical and operational specialists to clarify feasibility concerns, dependencies, legacy conditions, and change constraints;
- involving security, privacy, legal, compliance, procurement, risk, and other specialists when their evidence could affect the problem or possible response;
- testing the riskiest problem assumptions without building a production solution;
- comparing the evidence with the original opportunity framing;
- synthesizing findings into an explicit recommendation and unresolved questions.
Research samples, methods, and depth should match the people affected, materiality of the decision, diversity of contexts, risk, evidence already available, and cost of being wrong. Completed interviews, workshops, surveys, or maps do not constitute discovery evidence by themselves. The value comes from what the organization learns and how that learning changes the decision.
Typical outputsRead section
Discovery should leave an understandable record of the evidence, interpretation, uncertainty, and recommendation. Useful outputs may include:
- a refined business-problem statement;
- a description of affected users, stakeholders, contexts, needs, barriers, and consequences;
- current-state and wider-journey findings;
- qualitative and quantitative evidence with known limitations;
- outcome hypotheses and available baselines;
- tested, supported, rejected, and unresolved assumptions;
- relevant constraints, dependencies, obligations, and risks;
- relationships to existing products, services, initiatives, and portfolio decisions;
- opportunity areas or response principles stated without premature feature commitment;
- a recommendation to advance, reframe, divide, combine, route, investigate further, pause, or stop;
- the decision rationale, accountable decision-maker, and questions that Define or another stage must resolve.
The record can combine several artifacts or remain concise. Its form should make the reasoning traceable, not create documentation for its own sake.
Contributing responsibilitiesRead section
No universal team owns every discovery. Participation should reflect the problem, affected people, evidence needs, and decision risk.
Product leadership
Product management can frame the learning objective, connect evidence across disciplines, relate findings to outcomes and existing product direction, make assumptions visible, and prepare the next product decision. Product ownership can contribute evidence from delivery, backlog, acceptance, and product use when an existing capability is involved.
Users, research, design, and accessibility
Users and affected stakeholders provide direct evidence about goals, context, needs, barriers, and workarounds. Research specialists guide responsible methods and interpretation. Experience, service-design, content, and accessibility specialists help reveal the complete journey and the needs of people who may otherwise be excluded.
Business and operational leadership
Business leaders, operational owners, frontline teams, service owners, and subject-matter experts explain current processes, policy intent, consequences, performance, ownership, and organizational conditions. Their knowledge is essential context, but it should not substitute for direct user evidence.
Data, analytics, finance, and portfolio governance
Data and analytics specialists clarify sources, quality, lineage, representativeness, baselines, and measurement limits. Finance and portfolio leaders contribute cost, benefit, investment, capacity, and competing-priority context without turning discovery into a complete business case.
Engineering, architecture, operations, and support
Engineering and architecture specialists identify technical context, integrations, dependencies, feasibility concerns, and legacy constraints. Operations and support specialists contribute incidents, service patterns, continuity concerns, and evidence from active use. Discovery should not require these contributors to estimate or design a predetermined solution.
Risk and obligation specialists
Security, privacy, legal, compliance, procurement, data-governance, safety, and other specialists identify obligations, risks, permitted uses, and constraints that could materially affect the problem or future response.
The accountable decision-maker integrates these contributions while each specialist retains responsibility for professional judgments within that discipline.
Cross-lifecycle considerationsRead section
Discovery can receive and change evidence from any Digital Product Lifecycle Stage:
- Opportunity provides the initial signal, reason for attention, and unresolved questions.
- Define may expose an ambiguity that requires renewed problem evidence.
- Design research may reveal that the organization misunderstood the user need or wider journey.
- Develop may uncover data, integration, or operational conditions that change the problem framing.
- Validate may show that the product works technically but does not address the intended problem.
- Launch preparation may reveal missing audiences, workflows, ownership, or support needs.
- Adopt may expose barriers that were not visible before real use.
- Operate can provide behavioral, support, performance, cost, incident, and risk evidence for renewed discovery.
- Evolve uses discovery to understand changed needs and conditions before changing direction.
- Retire may require discovery into continuing user needs and the effects of withdrawal.
Discovery findings should remain available to later stages, including evidence limitations and rejected assumptions. Later teams should not treat a summary conclusion as more certain than the underlying evidence supports.
Common mistakesRead section
Using discovery to justify a selected solution
Research loses decision value when questions, participants, or interpretation are designed to confirm an answer that leaders have already chosen. Preserve the possibility that the evidence may support a different response or no product response.
Confusing stakeholder requests with user needs
Stakeholders may provide important business and operational evidence. Direct evidence from affected users is still needed when the product changes their experience, work, access, or outcomes.
Studying only the digital interface
The business problem may span policy, process, people, data, support, assisted channels, and third parties. Limiting discovery to a screen or requested feature can hide the causes that matter most.
Treating a research activity as the outcome
Interviews, workshops, surveys, analytics reviews, and journey maps are methods or artifacts. Discovery must explain what was learned, how reliable it appears, what remains uncertain, and how the evidence affects the decision.
Ignoring conflicting or inconvenient evidence
Contradictory findings can reveal different user groups, contexts, causes, or evidence-quality problems. Resolve or preserve the disagreement rather than averaging it away.
Requiring exhaustive certainty
Discovery cannot remove every unknown. The appropriate standard is sufficient evidence for the next decision, with material assumptions and risks made visible.
Defining requirements or a roadmap too early
Detailed requirements and feature commitments can narrow discovery around an unproven direction. Capture ideas without allowing them to define the findings.
Assuming discovery occurs once
Needs, environments, technologies, policies, and products change. Returning to Discover can be responsible when current decisions rely on outdated or incomplete evidence.
Decision signals
Advance to Define
Advancing to Define may be appropriate when:
- the organization can explain the business problem, affected people, and wider context using credible evidence;
- important needs, barriers, consequences, and current alternatives are understood well enough to shape direction;
- material assumptions, constraints, dependencies, risks, and evidence limitations are visible;
- intended outcomes and available baselines can be articulated without promising a particular feature;
- the evidence supports continued product attention;
- unresolved questions are known and can be addressed through definition, design, technical exploration, or later validation;
- an accountable decision-maker accepts responsibility for defining the product direction.
Advancement does not certify that discovery is permanently complete. New evidence may require the organization to return.
Continue or narrow discovery
Additional investigation may be appropriate when a material user group, cause, context, constraint, or evidence source remains unclear and the uncertainty could change the next decision. Narrow the work around that decision rather than expanding research without a defined purpose.
Reframe, divide, or combine
The findings may show that the original problem was a symptom, several problems require different responses, or connected opportunities should be considered together.
Route to an existing product or another stage
The evidence may connect the problem to an active product whose next decision belongs in Define, Design, Develop, Validate, Adopt, Operate, Evolve, or Retire. Routing should preserve the discovery evidence and rationale.
Pause or stop
Pausing may be appropriate when evidence access, ownership, a dependency, timing, or capacity prevents a responsible decision. Stopping may be appropriate when the problem is not supported, the impact does not justify further attention, an existing response is sufficient, a non-product action is more appropriate, or foreseeable cost and risk outweigh the reason to continue.
Applied-example continuation
Starting point
The Opportunity stage identified rising customer contacts about active service requests, inconsistent escalation tracking, and limited status visibility. Leaders authorized investigation without approving the proposed mobile application.
Discovery work
Research follows customers from request submission through completion and includes people who use the account portal, people who rely on phone support, people who use assistive technology, frontline support employees, operational teams, and owners of the relevant data and systems.
The evidence shows that customers cannot reliably tell whether a request is progressing, whether they need to act, or when the next update should occur. Different operational teams use the same status words to mean different things. Some systems update overnight, while others depend on manual entry. Support employees compensate by consulting several sources and maintaining local notes.
The mobile-application assumption remains unsupported. Customers want trustworthy, understandable status and useful updates, but channel preferences vary. Some prefer the existing authenticated account experience, some want optional notifications, and some require assisted support. The research also identifies accessibility, consent, identity, privacy, data-quality, and operational-ownership questions.
Findings and decision
The organization reframes the business problem around unreliable and difficult-to-understand status visibility across the service-request journey. Evidence supports defining a product direction, but it does not support selecting one channel as the complete response.
The Discover-stage decision advances to Define with a documented view of affected users, current-state evidence, status-language inconsistencies, data constraints, desired outcomes, unresolved assumptions, and the wider products and operations that must contribute.
Source notesRead section
- GOV.UK Service Manual — How the discovery phase works. Supports understanding the problem, users, wider journey, constraints, alternatives, accessibility needs, and success measures before committing to build.
- U.S. Digital Services Playbook. Supports beginning with real user needs, addressing the complete experience, using qualitative and quantitative evidence, assigning accountable leadership, and making data-driven decisions.
- NIST Special Publication 800-160 Volume 1. Supports developing and maintaining evidence about stakeholder needs, system concerns, risk, and lifecycle context without assigning every specialist responsibility to product leadership.