When the stage becomes relevant
Launch can become relevant when:
- validation evidence supports making a new product or capability available;
- an existing product will expand to a new audience, channel, geography, use case, or level of exposure;
- a release materially changes user behavior, workflows, support, policy, data, risk, or operations;
- a legacy product or process will transition to a replacement;
- availability depends on coordinated communications, learning, permissions, vendors, integrations, or organizational readiness;
- support, monitoring, incident, continuity, or rollback responsibilities must be activated;
- a phased rollout can reduce risk or improve learning;
- a previously launched capability requires relaunch or renewed enablement after substantial change;
- a product is technically available but was never introduced as an owned and supported product.
Not every technical change requires a distinct launch effort. The level of coordination should reflect user impact, organizational change, risk, reversibility, and exposure.
Questions and decisionsRead section
Audience and rollout
- Who should receive access, in what order, and under which conditions?
- What makes each rollout group coherent and supportable?
- Should availability be limited by audience, geography, product type, data source, channel, or time?
- How will the organization learn from early use before expanding?
- Which conditions authorize expansion, delay, pause, or rollback?
Product and operational readiness
- Does the validated product configuration match what will be released?
- Are environments, data, integrations, permissions, vendors, monitoring, capacity, and recovery procedures ready?
- Who owns incidents, product decisions, support, data quality, communications, and escalation after launch?
- Can the organization sustain the product at the expected level of demand?
- Are known limitations accurately represented to users and support teams?
User and organizational readiness
- How will intended users discover the product and understand its purpose?
- What onboarding, guidance, learning, support, policy, workflow, or role changes are required?
- Are frontline employees and support teams prepared to explain and assist with the product?
- Which groups may need different communication, access, or assistance?
- Does the surrounding organization have the capacity and incentive to support the change?
Measurement and governance
- Which launch, product-health, behavior, adoption, support, risk, and outcome signals will be monitored?
- Are baselines, instrumentation, dashboards, feedback paths, and decision thresholds ready?
- Who reviews evidence, how often, and who can change rollout decisions?
- How will the organization separate launch activity from meaningful adoption and outcomes?
Risk and contingency
- Which security, privacy, legal, compliance, accessibility, financial, contractual, and reputational conditions apply?
- What could fail, whom would it affect, and how quickly could the organization detect it?
- Which mitigations, manual procedures, communication paths, and rollback options exist?
- What happens to users in progress if availability is paused or reversed?
- What evidence supports launch now rather than later?
Activities and evidenceRead section
Useful launch work may include:
- confirming that the validated product version, configuration, content, data, and dependencies match the release candidate;
- selecting a rollout approach based on evidence, audience, risk, reversibility, support capacity, and learning needs;
- preparing deployment, migration, transition, rollback, recovery, continuity, and incident procedures;
- confirming operational ownership, support tiers, service levels, escalation paths, vendor responsibilities, and decision authority;
- preparing user communications, onboarding, guidance, learning, accessibility information, and assisted-support materials;
- preparing employees, partners, and frontline teams for changed workflows, policies, responsibilities, and questions;
- validating production monitoring, logs, analytics, alerting, feedback, audit, and product-health measures;
- establishing launch thresholds, review cadence, expansion conditions, and stop or rollback triggers;
- reviewing security, privacy, legal, compliance, procurement, financial, accessibility, and data-governance readiness;
- rehearsing high-impact incidents, support scenarios, migration steps, and communication paths;
- checking capacity, performance, demand assumptions, and dependency readiness;
- coordinating related products, channels, campaigns, operations, and organizational changes;
- recording the launch decision, rationale, limitations, owners, and next review.
Launch planning should begin before the product is technically complete when readiness work can influence definition, design, development, or validation.
Typical outputsRead section
Useful Launch-stage outputs may include:
- a launch and rollout plan;
- an integrated readiness record and decision;
- audience, access, sequencing, migration, and expansion definitions;
- deployment, rollback, recovery, continuity, and incident procedures;
- support model, knowledge, service levels, escalation paths, and accountable owners;
- user, employee, partner, and stakeholder communications;
- onboarding, learning, guidance, and assisted-support materials;
- monitoring, analytics, feedback, audit, and decision thresholds;
- known limitations, accepted risks, mitigations, and contingency plans;
- launch governance, review cadence, expansion criteria, and stop conditions;
- confirmation of vendor, contractual, financial, data, security, privacy, accessibility, legal, and operational readiness;
- a launch, phased-launch, delay, limit, pause, rollback, or stop decision.
The output should support coordinated action and accountability. A long checklist without owners, evidence, and decision authority does not establish readiness.
Contributing responsibilitiesRead section
Product leadership
Product management connects the launch to intended users, outcomes, scope, positioning, measurement, governance, and continued ownership. Product ownership connects release content, known conditions, backlog decisions, and immediate product tradeoffs.
Engineering, release, and operations
Engineering, platform, release, reliability, and operations specialists own deployment, environment, performance, monitoring, resilience, recovery, and technical support responsibilities. They provide evidence about production readiness and limitations.
Adoption, communications, learning, and support
Change, communications, learning, marketing, customer-success, service, and support contributors prepare people to discover, understand, access, and receive help with the product. Their work should accurately reflect the validated product and its limitations.
Experience, research, content, and accessibility
Experience and content specialists maintain coherence across the product, onboarding, notifications, documentation, and support. Research and accessibility specialists help evaluate readiness for different users and contexts.
Data, quality, security, privacy, and other obligations
Data and analytics specialists confirm production data and measurement. Quality specialists connect readiness to validation evidence. Security, privacy, legal, compliance, finance, procurement, risk, and vendor specialists confirm applicable responsibilities and decisions.
Business and operational leaders ensure that surrounding workflows, staffing, policy, ownership, and capacity can support availability.
Cross-lifecycle considerationsRead section
- Define and Design establish audience, value, experience, measures, and organizational implications that launch must preserve.
- Develop and Validate provide the working product, evidence, known conditions, and acceptance position.
- Adopt uses launch conditions and real behavior to determine whether people begin and continue using the product.
- Operate sustains the product, monitors health, and manages incidents after availability.
- Evolve may require a new launch decision when a change materially affects users or operations.
- Retire uses similar coordination for transition, communication, support, data, and withdrawal.
Launch evidence can require a return to any earlier stage. A missing support owner may require definition; a confusing communication may require design; an operational failure may require development and validation.
Common mistakesRead section
Treating deployment as launch
Technical availability does not prepare users, support, operations, measurement, governance, or the organization. Coordinate the complete introduction.
Launching to everyone to learn faster
Broad exposure can increase harm and reduce the organization’s ability to interpret evidence. Choose a rollout that creates useful learning within supportable risk.
Beginning communications immediately before release
Onboarding, policy, workflow, support, and organizational change can influence the product itself. Develop them early enough to shape product decisions.
Measuring awareness as adoption
Messages sent, impressions, visits, and access granted describe launch activity. Adoption requires evidence of effective and continuing use.
Omitting rollback conditions
Rollback should address users, data, integrations, work in progress, support, and communication, not only software deployment.
Hiding known limitations
Users and support teams need accurate expectations. Concealed limitations can damage trust and delay responsible response.
Ending product ownership at launch
Launch increases product responsibility. Adoption, operation, measurement, evolution, and eventual retirement still require accountable decisions.
Decision signals
Launch or begin phased rollout
Launch may be appropriate when the product acceptance position supports intended use; operational and support ownership are active; communications and onboarding are accurate; monitoring and feedback are ready; obligations and dependencies are addressed; and accountable leaders can expand, pause, or reverse availability.
Limit or phase
Limit or phase availability when a coherent audience or use case can receive benefit safely while the organization learns, protects unsupported groups, or manages capacity and dependency risk.
Delay and change
Delay when a resolvable readiness gap would create material user, operational, legal, security, privacy, accessibility, data, or reputational risk.
Return to Validate or an earlier stage
Return to Validate when the release configuration or material evidence changes. Return to Develop, Design, Define, or Discover when readiness work reveals a problem in capability, experience, direction, or problem understanding.
Rollback, pause, or stop
Rollback or pause when evidence crosses an agreed threshold or the organization cannot support responsible availability. Stop when the product no longer supports the intended need or risk and cost outweigh the reason to proceed.
Applied-example continuation
Validation supported a limited initial status product for request types with reliable source data. Launch planning selects a phased rollout to customers who have eligible active requests and authenticated accounts.
The organization prepares account messages, optional notification enrollment, accessible guidance, support scripts, employee learning, incident escalation, data-freshness monitoring, notification-failure alerts, product analytics, privacy support, and a manual status-check path. Owners are named for product decisions, source-data quality, operations, support, communications, and expansion.
Launch thresholds cover status accuracy, data freshness, account access, notification delivery, support volume, accessibility concerns, and unresolved exceptions. Rollback would disable notifications and new enrollment while preserving access to accurate account status and support information.
The Launch-stage decision authorizes phased availability. Expansion depends on stable product health, manageable support demand, accurate status, and early evidence that customers can understand and use the experience. The decision establishes conditions for adoption learning rather than assuming that availability creates benefit.
Source notesRead section
- GOV.UK Service Manual — How the beta phase works. Supports phased exposure, learning with real users, support readiness, accessibility, performance, security, privacy, and preparation for live operation.
- GOV.UK Service Manual — How the live phase works. Supports operational ownership, measurement, accessibility, security, uptime, support readiness, and continuing improvement.
- U.S. Digital Services Playbook. Supports deployment preparation, accountable ownership, real-user evidence, security and privacy, measurement, and iterative rollout.