When the stage becomes relevant
Define can become relevant when:
- discovery evidence supports continued product attention but several possible responses remain;
- an organization needs to align stakeholders around a product purpose, intended users, and outcomes;
- teams are working from a feature list without a clear product direction;
- an existing product lacks clear boundaries, priorities, ownership, or measures;
- requirements conflict because decision rights or intended outcomes remain ambiguous;
- a roadmap contains work but does not explain the product change that the work should create;
- portfolio, funding, vendor, or capacity decisions require a clearer product definition;
- design or development repeatedly revisits fundamental questions about users, value, scope, or responsibility;
- adoption or operational evidence shows that the product direction requires revision;
- evolution, consolidation, repositioning, or retirement planning changes what the product should become.
Definition can occur at several levels. An organization may need to define an entire product, a major product direction, a new capability, or a material change to a live product. The level should match the decision.
Questions and decisionsRead section
Purpose and intended users
- What business problem should the product address?
- Which users and stakeholders should the product serve, and in which contexts?
- What need, task, or outcome should improve for those people?
- Why should this product exist rather than relying on the current state, an existing product, or a non-product response?
- Which assumptions about users and value remain unresolved?
Outcomes and value
- Which user, business, operational, financial, strategic, or risk-related outcomes should the product influence?
- What evidence connects the proposed direction to those outcomes?
- Which baselines exist and which measures must be established?
- How will the organization distinguish product health, user behavior, output, and realized outcomes?
- What evidence would cause leaders to reconsider the direction or continued investment?
Product boundary
- Which part of the business problem should this product address?
- What belongs inside and outside the current product boundary?
- Which products, services, processes, policies, channels, data, and operational responsibilities surround it?
- Where should ownership transfer or remain shared across organizational boundaries?
- Which scope choices are necessary now, and which should remain open until design, technical exploration, or validation provides evidence?
Requirements and priorities
- Which capabilities, experience conditions, business rules, data needs, controls, and obligations are necessary to support the intended outcomes?
- Which requirements express a need or acceptance condition, and which accidentally prescribe an untested implementation?
- What should receive priority, and which evidence supports that order?
- Which dependencies, constraints, risks, and technical conditions influence sequencing?
- What is the smallest coherent product change that can produce useful evidence or benefit?
Ownership and decision rights
- Who remains accountable for product direction and continued product decisions?
- Which decisions belong to product management, product ownership, business leadership, engineering, design, data, operations, risk, and other specialists?
- How will conflicts, exceptions, and changes be resolved?
- Who owns the product after launch and during operation?
- Which governance cadence or portfolio decisions must remain connected to the product?
Direction and next decision
- Is the product direction supported strongly enough to shape experience work?
- Which aspects should Design explore, test, or make more precise?
- Which technical, data, operational, security, privacy, legal, accessibility, or financial questions require parallel investigation?
- Should the direction advance, narrow, expand, combine, reframe, return to Discover, route to an existing product, pause, or stop?
Activities and evidenceRead section
Definition activities connect evidence to explicit product choices. Useful work may include:
- synthesizing discovery findings into a concise product purpose and direction;
- identifying intended users, priority contexts, needs, and outcomes;
- defining the current product boundary and its relationship to surrounding products, services, processes, and channels;
- establishing product principles that help teams interpret later tradeoffs;
- translating needs and obligations into outcome-oriented requirements and acceptance conditions at an appropriate level of detail;
- separating required outcomes and constraints from preferred features or implementations;
- identifying assumptions that Design, Develop, or Validate must test;
- defining baselines, product-health measures, behavior measures, outcome measures, and evidence limitations;
- clarifying product management, product ownership, specialist, governance, and escalation responsibilities;
- evaluating strategic fit, costs, benefits, dependencies, capacity, risks, and competing investments;
- shaping an initial roadmap around meaningful product changes, decisions, or outcomes rather than a permanent feature commitment;
- considering adoption, operations, support, measurement, security, privacy, accessibility, data, and retirement implications early enough to influence direction;
- documenting alternatives considered, tradeoffs made, and the rationale for the selected direction;
- reviewing the definition with the people who must design, build, validate, launch, adopt, operate, govern, or depend upon the product.
Definition should remain precise enough to guide decisions and flexible enough to change when evidence develops. Detail that does not influence a current or foreseeable decision can wait.
Typical outputsRead section
Useful Define-stage outputs may include:
- a product purpose or product-definition statement;
- a clear business-problem statement and summary of supporting evidence;
- intended users, priority contexts, needs, and outcomes;
- a value proposition or value logic grounded in evidence;
- product boundaries, exclusions, surrounding dependencies, and ownership interfaces;
- product principles and material assumptions;
- outcome-oriented requirements, business rules, obligations, and acceptance conditions;
- product-health, behavior, and outcome measures with available baselines;
- product management, product ownership, specialist, governance, and escalation decision rights;
- an initial roadmap, release hypothesis, or sequence of meaningful product changes;
- a record of tradeoffs, rejected alternatives, unresolved questions, and the decision rationale;
- a recommendation to advance, revisit, narrow, combine, route, pause, or stop.
No single artifact proves that a product has been defined. The relevant test is whether the people responsible for later decisions can explain the intended product, its evidence, its boundaries, and the decisions that remain open.
Contributing responsibilitiesRead section
Product management
Product management typically connects the business problem, users, outcomes, value, boundaries, priorities, measures, investment context, and continuing direction. It makes tradeoffs and assumptions visible without replacing the decisions owned by specialists.
Product ownership
Product ownership connects the direction to delivery-facing clarity. This can include backlog structure, ordering, refinement, acceptance conditions, dependencies, and day-to-day product decisions. Product ownership should preserve the intended outcomes rather than reduce the definition to a list of requested features.
Users, research, experience, content, and accessibility
Research specialists help protect the integrity of discovery evidence and identify gaps. Experience, service-design, content, and accessibility specialists clarify experience implications, user contexts, journey boundaries, inclusive-use needs, and questions that Design should resolve.
Business and operational leadership
Business sponsors, operational owners, service owners, frontline leaders, and subject-matter experts contribute strategy, policy, workflow, capacity, ownership, benefit, and operating-model context. They help define which organizational changes must accompany the product.
Engineering, architecture, data, and operations
Engineering and architecture specialists clarify feasibility, system boundaries, dependencies, maintainability, reliability, integration, cost, and technical risk. Data specialists contribute availability, quality, lineage, permitted use, instrumentation, and measurement needs. Operations and support specialists establish conditions for sustainable ownership and active use.
Quality, security, privacy, legal, compliance, finance, and procurement
These specialists identify acceptance needs, controls, obligations, costs, contracts, sourcing constraints, and risks that should shape product direction. Their involvement should be early enough to influence the definition rather than only approve a finished proposal.
The accountable product decision-maker integrates the contributions while specialist accountability remains intact.
Cross-lifecycle considerationsRead section
- Opportunity and Discover provide the reason for attention and the evidence supporting the direction.
- Design can expose needs, experience conditions, or service boundaries that require the definition to change.
- Develop can reveal feasibility, dependency, data, cost, quality, or sequencing evidence that changes priorities or scope.
- Validate can show that requirements were incomplete, acceptance conditions were ambiguous, or the direction does not address the intended outcome.
- Launch and Adopt require defined audiences, ownership, measures, support conditions, and organizational changes.
- Operate tests the definition against real product health, behavior, cost, risk, support, and outcome evidence.
- Evolve revises product direction when needs, strategy, evidence, technology, or portfolio conditions change.
- Retire depends on a clear understanding of the continuing need, ownership, obligations, product boundary, and replacement relationship.
Product definition should remain a living decision reference. Changes should preserve the rationale and effects rather than silently replacing earlier commitments.
Common mistakesRead section
Treating the roadmap as the product definition
A roadmap communicates intended change and sequence. It cannot substitute for clarity about the business problem, users, outcomes, boundaries, evidence, and decision rights.
Defining the product as a feature collection
Features describe possible product behavior. They do not explain why the product exists, which outcomes matter, or how teams should make tradeoffs when conditions change.
Replacing direction with a broad vision statement
An aspirational statement can support alignment, but teams also need practical boundaries, priorities, measures, ownership, and evidence.
Requiring complete requirements before design or development
Some requirements become clearer through experience work and working increments. Define the conditions necessary for responsible progress and identify what later evidence must resolve.
Leaving exclusions and interfaces implicit
Ambiguous boundaries create duplicated work, unmet expectations, and ownership gaps. Explain what the product will not address now and how it connects to surrounding products and operations.
Confusing delivery metrics with product outcomes
Velocity, completion, release dates, and output counts may describe delivery. They do not show whether users benefit or the business problem improves.
Centralizing every decision under product leadership
Product leadership connects decisions but does not absorb engineering, design, research, quality, security, privacy, legal, operational, financial, or other specialist accountability.
Freezing the definition
A definition that cannot change becomes detached from evidence. Update it deliberately when material learning, strategy, or conditions change.
Decision signals
Advance to Design
Advancing to Design may be appropriate when:
- the product purpose, intended users, priority contexts, and business problem are clear enough to guide experience decisions;
- intended outcomes and available baselines are defined at a useful level;
- the current product boundary and important exclusions are understood;
- requirements, obligations, constraints, assumptions, and dependencies are visible;
- design has meaningful questions to explore rather than an instruction to decorate a predetermined interface;
- product ownership and specialist decision rights are sufficiently clear;
- the organization understands which evidence could change the direction.
Advance does not require every requirement, feature, release, or implementation decision to be complete.
Proceed directly to another decision context
An existing product may already have an established experience pattern and require a delivery-facing decision rather than a complete new design effort. Work can move to Develop, Validate, Adopt, Operate, or Evolve when the evidence supports that decision and any design responsibility remains addressed.
Revisit Discover
Return to Discover when the business problem, users, causes, context, or desired outcomes cannot be explained with sufficient evidence, or when definition work reveals a materially different problem.
Narrow, expand, combine, or route
The product boundary may need to narrow for coherence and risk, expand to address the complete problem, combine with related products, or route into an existing product direction.
Pause or stop
Pause when ownership, investment, evidence, a dependency, or an obligation prevents responsible progress. Stop when the evidence no longer supports the direction, an alternative adequately addresses the need, or expected value does not justify foreseeable cost and risk.
Applied-example continuation
Starting point
Discover established that customers need trustworthy, understandable status across an active service-request journey. It also revealed inconsistent operational language, uneven data freshness, multiple channel preferences, accessibility needs, and unclear ownership. The evidence did not support a mobile application as the complete response.
Product direction
The organization defines the product direction around reducing customer uncertainty through reliable status visibility and useful updates. The initial audience includes customers with active service requests and employees who support them. Intended outcomes include fewer avoidable status contacts, improved customer understanding, more consistent support, and clearer operational accountability for status data.
The initial product boundary covers status for selected active request types, understandable status language, expected next steps, important exceptions, optional notifications, preference management, and an assisted-support path. It does not include full case management, changes to every fulfillment workflow, or a new mobile application.
Requirements and measures
The definition establishes that displayed status must come from an accountable source, meet stated freshness conditions, use language customers understand, expose meaningful exception states, support accessible use, protect account and preference data, and provide a support path when digital status cannot answer the need.
The organization records baseline status-contact volume, portal use, current data latency, common escalation reasons, accessibility concerns, and support effort. It identifies future measures for status comprehension, successful self-service, notification usefulness, avoidable-contact reduction, data freshness, and unresolved exceptions.
Decision
The Define-stage decision advances to Design. Design will determine how customers find and understand status, how account and notification experiences work together, how exceptions and next actions appear, and how assisted support fits the journey. Technical and operational contributors will continue investigating data reliability and ownership because those findings may change the initial product boundary or release sequence.
Source notesRead section
- U.S. Digital Services Playbook. Supports grounding product direction in real user needs, complete experiences, measurable goals, accountable ownership, security, privacy, and evidence-driven decisions.
- The Scrum Guide, November 2020. Supports a Product Goal as a future state, an emergent ordered Product Backlog, accountable product decisions, and inspection and adaptation. This profile does not treat Scrum as a required delivery method.
- NIST Special Publication 800-160 Volume 1. Supports connecting stakeholder needs, system concerns, requirements, risk, architecture, operation, and lifecycle decisions.