A launch readiness review is an evidence-based go, conditional-go, delay, or stop decision. It confirms product behavior, quality, security, privacy, accessibility, operations, support, analytics, communication, rollout, and rollback. Each critical condition has an owner and proof. The meeting resolves risk; it should not discover the launch plan for the first time.
Who this is for: Product managers and cross-functional launch owners coordinating a consequential software release across technical and business teams.
- Define readiness criteria, severity, evidence, owners, and decision authority early in delivery.
- Review the complete customer and operating system, including support, data, communication, monitoring, and recovery.
- Use staged rollout and explicit stop conditions when uncertainty remains instead of converting every issue into optimism.
Set the launch decision
Clarify what is launching, to whom, where, at what scale, and with which irreversible effects. A private pilot, regional rollout, and default migration require different evidence. Define go, conditional-go, delay, and stop outcomes plus who has authority to make each decision. Record nonnegotiable legal, safety, security, and contractual gates.
Create criteria before the final week. Assign each item an owner, due date, evidence link, status, severity, and remediation. Teams should raise red conditions as soon as they appear. A readiness review fails when people feel pressure to conceal risk because the marketing date has become untouchable.
Review customer readiness
Confirm intended use, primary flows, permissions, data migration, errors, recovery, accessibility, localization, and performance with test evidence. Resolve whether known limitations are acceptable for the launch population and communicated accurately. Check that pricing, entitlements, terms, onboarding, documentation, and in-product messages match actual behavior.
Verify instrumentation for activation, product outcomes, errors, and guardrails. Run end-to-end scenarios in the release environment, including account states and integrations that differ from development. Ensure the launch does not depend on analytics events or configuration that nobody has validated with real test records.
Review operating readiness
Confirm capacity, monitoring, alerts, dashboards, on-call ownership, incident procedures, vendor contacts, backups, and rollback. Define who can pause rollout and how quickly. Test migration and rollback when feasible. A rollback plan that requires unavailable data or an unpracticed manual sequence is not yet operational evidence.
Prepare support, sales, success, finance, legal, and operations for the questions and changes they will own. Provide accurate training, known limitations, escalation paths, customer eligibility, and approved messages. Forecast support volume and staff coverage. Operational teams should review the plan, not merely receive a launch announcement.
Decide and monitor
Run the meeting from exceptions and evidence rather than reading every green checklist row. Owners explain unresolved risks, consequence, mitigation, and monitoring. The decision maker records accepted risks and conditions. Any conditional launch should specify what must happen, by when, and what automatically stops exposure.
Use a staged rollout with observation windows appropriate to the behavior. Monitor technical health, customer outcomes, guardrails, support, and qualitative reports. Hold a launch review after enough time to assess early evidence. Close temporary controls and update documentation instead of leaving launch configuration as permanent unexplained machinery.
Review readiness for invoice automation
A finance product will automatically match imported payments to invoices for a limited customer cohort.
- Define the cohort, matching threshold, reversible actions, approval duties, and financial-error stop conditions.
- Verify matching accuracy, permissions, audit trail, accessible review, data migration, and correction on representative accounts.
- Confirm monitoring, manual fallback, support scripts, finance escalation, vendor dependencies, and rollback rehearsal.
- Resolve one known currency limitation by excluding affected accounts and communicating eligibility accurately.
- Approve a five-percent rollout with daily reconciliation and named authority to pause automatically on threshold breach.
Launch readiness register
Track evidence and exceptions in one live record from delivery through post-launch review.
- Launch scope: capability, audience, region, environment, scale, timing, exclusions, and decision authority.
- Customer evidence: behavior, quality, accessibility, privacy, security, data, pricing, terms, content, and analytics.
- Operations: capacity, monitoring, alert, incident, support, training, vendor, backup, migration, and rollback proof.
- Exception: condition, severity, consequence, mitigation, owner, deadline, accepted risk, and stop threshold.
- Rollout: stages, observation windows, measures, pause owner, communication, final review, and cleanup.
Common mistakes
- Scheduling the readiness review after public commitments leave no practical ability to delay.
- Treating a green engineering status as proof that support, policy, analytics, and customer communication are ready.
- Writing a rollback plan without testing whether data and responsible people can execute it under pressure.
Try one
All feature tests pass, but customer support has no documentation and monitoring lacks an alert for the primary failure. Should the launch proceed?
A strong answer does not call the product ready. It assesses failure consequence, requires support and monitoring owners, creates and verifies the missing documentation and alert, and records a delay or tightly bounded conditional decision. Feature correctness alone does not cover detection, response, customer communication, or recovery, which are part of the launched system.
Sources
- Atlassian product requirements guideOfficial guidance on collaborative, concise, and testable product requirements.
- Atlassian product roadmaps guideOfficial guidance on communicating product direction, priorities, and progress.