When the stage becomes relevant
Validate can become relevant when:
- a working increment requires a product-acceptance decision;
- evidence from several disciplines must be interpreted together;
- a material requirement, experience, integration, data flow, control, or operational condition has changed;
- a product will expand to a new audience, channel, geography, use case, or level of exposure;
- testing produces conflicting findings or unresolved exceptions;
- stakeholders disagree about whether known limitations are acceptable;
- a defect, incident, accessibility concern, security issue, or operational failure calls earlier acceptance into question;
- adoption or outcome evidence suggests that technically correct behavior is not solving the intended problem;
- an evolved product direction requires renewed evidence;
- a retirement or migration change must be validated before users or systems transition.
Validation can occur repeatedly and at several levels. A small increment may require focused evidence, while a high-impact launch may require a broader integrated view.
Questions and decisionsRead section
Intended need and outcome
- Does the product address the defined business problem and relevant user needs?
- Does the experience support the intended tasks and contexts?
- Which outcome assumptions can be evaluated now, and which require adoption or operation evidence?
- Has the product direction changed enough to require renewed definition or discovery?
Requirements and experience
- Are material requirements and acceptance conditions satisfied?
- Can representative users understand, access, and use the product, including important exceptions and recovery paths?
- Does the experience remain coherent across devices, channels, support, and operational handoffs?
- Are accessibility findings resolved or addressed through an accountable decision?
Product behavior and quality
- Does the product behave correctly across functional, integration, data, performance, reliability, and resilience conditions?
- What happens when data is delayed, dependencies fail, permissions differ, or demand increases?
- Are defects and limitations understood by severity, user impact, likelihood, and detectability?
- Does the available evidence represent the product configuration and conditions that will advance?
Risk and obligation
- Are security, privacy, legal, compliance, safety, data-governance, and contractual conditions satisfied?
- Which risks remain, who can accept them, and under what conditions?
- Are evidence gaps themselves material to the decision?
- Would limiting audience, scope, duration, or exposure reduce risk responsibly?
Operations and evidence quality
- Can the product be monitored, supported, recovered, and measured?
- Are test data, environments, methods, samples, and results credible for the decision?
- Which findings conflict, and how should that conflict be resolved?
- Are exceptions, waivers, assumptions, and expiration conditions recorded?
- Who owns the integrated product decision?
Activities and evidenceRead section
Useful validation work may include:
- defining the decision, evidence scope, risk level, and accountable participants;
- tracing needs, requirements, experience conditions, obligations, and risks to available evidence;
- evaluating functional, integration, end-to-end, regression, data, performance, resilience, and recovery evidence;
- evaluating usability, comprehension, accessibility, assisted-support, and cross-channel evidence with representative users;
- reviewing security, privacy, legal, compliance, safety, and data-governance findings;
- reviewing operational monitoring, support, incident, continuity, deployment, rollback, and recovery evidence;
- confirming that analytics and measurement behave accurately enough for later decisions;
- distinguishing defects from accepted limitations, untested conditions, assumptions, and future work;
- assessing the combined effect of several individually minor findings;
- retesting changed or affected behavior;
- comparing evidence with the defined product direction and intended outcomes;
- recording the decision, rationale, dissent, conditions, owners, and next action.
Evidence should come from the product and conditions relevant to the decision. A demonstration, checklist, or approval meeting may contribute, but none replaces credible evidence.
Typical outputsRead section
Useful Validate-stage outputs may include:
- an integrated validation or product-acceptance record;
- traceability among needs, requirements, implementation, tests, findings, and decisions;
- usability, accessibility, functional, integration, data, performance, security, privacy, and operational evidence;
- resolved, accepted, deferred, and open findings with severity and ownership;
- exceptions, waivers, limitations, conditions, and review triggers;
- a statement of what was evaluated, in which environment and configuration, and with which evidence limitations;
- an outcome to advance, change, limit, retest, pause, return to an earlier stage, or stop;
- the accountable decision-maker and rationale;
- evidence and conditions that Launch or another stage must address.
The output should make the decision explainable and revisitable. Document volume does not compensate for missing evidence or unclear accountability.
Contributing responsibilitiesRead section
Product leadership
Product management connects the evidence to users, outcomes, product direction, boundaries, risk, and the next decision. Product ownership connects backlog items, requirements, acceptance conditions, findings, and delivery decisions. Neither responsibility can approve evidence owned by a specialist without that specialist contribution.
Quality and testing
Quality specialists guide evidence strategy, traceability, coverage, test design, finding severity, and interpretation. Testing may be distributed across teams and stages, while quality leadership helps the organization understand what the evidence does and does not establish.
Users, research, design, content, and accessibility
Representative users and research specialists provide evidence about comprehension, usability, context, and task success. Design and content specialists evaluate experience coherence. Accessibility specialists contribute standards-based and user-based evidence.
Engineering, architecture, data, and operations
Engineering and architecture specialists provide implementation, integration, performance, resilience, security, and technical-risk evidence. Data specialists address accuracy, lineage, freshness, permitted use, and measurement. Operations and support specialists evaluate monitoring, recovery, service ownership, and real-world support conditions.
Obligation and business specialists
Security, privacy, legal, compliance, safety, finance, procurement, and other specialists evaluate applicable obligations and risk. Business and operational leaders confirm that workflows, ownership, policy, and organizational conditions support the intended product.
The accountable product decision-maker integrates the complete position while specialist accountability remains intact.
Cross-lifecycle considerationsRead section
- Discover and Define provide the problem, users, outcomes, boundaries, requirements, and assumptions against which the product is evaluated.
- Design provides experience decisions and accessibility conditions.
- Develop supplies working capability and implementation evidence.
- Launch uses the validation position but separately evaluates organizational readiness and rollout conditions.
- Adopt and Operate reveal behavior, outcomes, support needs, and risks that may invalidate earlier assumptions.
- Evolve requires renewed validation when the product changes materially.
- Retire uses validation to confirm migrations, redirects, data treatment, access changes, and closure.
Validation findings can send work to any earlier stage. Returning to the decision that needs attention is more responsible than preserving an artificial forward sequence.
Common mistakesRead section
Treating validation as a final test cycle
Validation interprets evidence and supports a product decision. It should draw upon evidence produced throughout the work and add focused evaluation where gaps remain.
Equating test completion with acceptance
Executed tests can still leave material failures, untested conditions, weak coverage, or unresolved risk. Someone must interpret the evidence and decide what it means for the product.
Validating only functional behavior
A product can function correctly while remaining unusable, inaccessible, insecure, unreliable, unsupported, misleading, or disconnected from the intended need.
Hiding limitations in technical records
Decision-makers need a clear view of user impact, risk, evidence gaps, and conditions. Translate specialist findings without weakening their meaning.
Allowing schedule pressure to redefine evidence
A target date does not change what the evidence shows. Leaders may accept risk within their authority, but the acceptance and rationale should remain explicit.
Requiring zero defects
Not every finding prevents advancement. Evaluate severity, impact, likelihood, reversibility, exposure, mitigation, and ownership rather than using a universal count.
Assuming prior validation remains permanent
Product changes, dependencies, environments, user behavior, and obligations can change the validity of earlier evidence.
Decision signals
Advance toward Launch
Advancement may be appropriate when the combined evidence supports intended use; material requirements and obligations are satisfied; significant findings are resolved or explicitly accepted by authorized owners; limitations and evidence gaps are understood; and the product can enter launch planning without misrepresenting its readiness.
Change and retest
Change and retest when a resolvable finding prevents responsible advancement or when a modification could materially alter affected evidence.
Limit
Limit audience, capability, exposure, duration, data, or rollout when the narrower use is coherent, transparent, supportable, and sufficiently evidenced.
Revisit an earlier stage
Return to Develop for implementation changes, Design for experience decisions, Define for requirements or direction, or Discover when evidence challenges the original understanding of the problem.
Pause or stop
Pause when essential evidence, ownership, an obligation, or a dependency remains unavailable. Stop when the product cannot responsibly address the need or foreseeable value no longer justifies the cost and risk.
Applied-example continuation
Develop produced integrated status capability for selected service-request types. Validation brings together status accuracy and freshness, account access, usability, accessibility, notification consent, privacy, security, integration, performance, support, and operational evidence.
The product works reliably for request types supported by the frequently updated source. The overnight source creates a material risk of misleading customers, so those request types remain outside the initial scope. Research confirms that customers understand the revised status language and last-updated time. Accessibility evaluation identifies and resolves a focus-order issue. Notification testing confirms preference changes and unsubscribe behavior, while one failure path requires clearer support guidance.
The organization advances the limited product toward Launch for the sufficiently supported request types. The decision records the excluded request types, monitoring thresholds, support condition, remaining data dependency, and evidence required before expansion. Validation does not authorize launch by itself.
Source notesRead section
- GOV.UK Service Manual — How the beta phase works. Supports evaluation with real users, accessibility testing, performance evidence, secure operation, cross-channel experience, and iterative improvement before live operation.
- U.S. Digital Services Playbook. Supports automated testing, real-user evidence, security and privacy, data-driven decisions, and accountable ownership.
- NIST Special Publication 800-160 Volume 1. Supports multidisciplinary evidence, verification and validation, risk-informed decisions, and lifecycle traceability.