You're ready to ship when every acceptance criterion has a pass/fail test attached, every open question has a named owner and a deadline, and someone with actual authority to say no has explicitly said yes. Readiness isn't a vibe engineering gives you at standup — it's a checklist with named owners, scored dimension by dimension, not a single "does the code work" gut check.
Quick answer: Ready to ship means every acceptance criterion is testable and tested, every readiness dimension (not just code) has a named sign-off, and a rollback plan has actually been run once. Missing any of the three means you're hoping, not shipping.
Why "Ready to Ship" Is the Wrong Question to Ask
"Is it ready?" fails as a question because it collapses five independent risk categories — functional, quality, operational, go-to-market, and reversibility — into one yes/no that nobody can reason about cleanly. Ask it as a single question and you get a single gut-feel answer, usually from whoever sounds most confident in the room, not whoever actually knows.
This is why large engineering organizations don't run launches on a verbal go/no-go. Google's internal Launch Readiness Review process, described in the Site Reliability Engineering book, walks every launch through a checklist spanning capacity planning, monitoring, rollback, and dependency risk — precisely because "does it work" and "is it safe to launch" turned out to be different questions with different owners.
The same logic scales down to a five-person team. Feature complete is not the same claim as release ready. A feature can be functionally correct and still be unsafe to ship if nobody's on call for it, support has never seen it, or there's no way to turn it off if something goes wrong at 2 a.m.
Most of this risk should already have been retired earlier in the cycle — Marty Cagan's product-risk framework from Inspired (value, usability, feasibility, business viability) is squarely a discovery-phase tool, not a ship-day one. What's left at ship time is narrower: execution risk. Did we build the thing correctly, and can the organization actually run it? A spec precise enough for engineers to build from — the standard covered in our PRD writing masterclass for the AI era — makes that narrower question answerable, because the acceptance criteria you wrote at kickoff are the same ones you're checking off at ship time.
The Five Dimensions of Release Readiness
Evaluate every release across five independent dimensions — functional, quality, operational, go-to-market, and reversibility — because a release can clear one and silently fail another. "The feature works" is a functional claim; it says nothing about whether support can triage a ticket about it or whether you can turn it off if it breaks something else.
| Dimension | Core question | Typical owner | What skipping it looks like |
|---|---|---|---|
| Functional | Does it do what the spec says, across the cases that matter — not just the demo path? | PM + QA | Works in the walkthrough, breaks on an edge case in week one |
| Quality (non-functional) | Does it meet the performance, security, accessibility, and reliability bar? | Engineering lead | Fine at staging load, times out under real traffic |
| Operational | Can support, ops, and on-call actually run and troubleshoot this? | Eng manager / SRE | First incident hits and there's no runbook, no alert, no owner |
| Go-to-market | Do sales, support, and marketing know it exists and how to talk about it? | PM + marketing | Support gets flooded because the help desk was never briefed |
| Reversibility | Can you roll it back or flag it off without collateral damage? | Engineering lead | A bad release stays live for days because rollback was never tested |
The quality row deserves its own note, because "quality" is where PMs most often wave their hands. The ISO/IEC 25010 software quality model gives it actual vocabulary — performance efficiency, reliability, security, usability, maintainability, portability — instead of leaving it as a synonym for "seems fine." Pull two or three of those characteristics that matter for the specific release and make them explicit gate criteria, not an implicit assumption.
Notice that only two of the five rows are "engineering" rows. Readiness is a cross-functional claim, not an engineering status update — which is exactly why a single "is the code done" question in a standup can't answer it.
Turning Fuzzy Requirements Into Testable Acceptance Criteria
A requirement is ready to ship only when its acceptance criteria are specific enough that two engineers, testing independently, would reach the same pass/fail verdict. "Works well" and "is fast" aren't ready regardless of how much code sits behind them — they're not falsifiable, so nobody can prove they're done.
The Given/When/Then structure from behavior-driven development — formalized by Dan North and popularized through the Gherkin syntax — remains the cleanest way to force that specificity. It's not ceremony; it's a forcing function that makes an ambiguous requirement visibly ambiguous before an engineer has to guess at 11 p.m. the night before launch. Here's a real fragment, for a bulk CSV export feature:
| ID | Given / When / Then | Status | Owner | Open question |
|---|---|---|---|---|
| AC-1 | Given a workspace with 10,000+ records, when the user requests a CSV export, then the file generates within 30 seconds with no row truncation | Tested | eng-lisa | — |
| AC-2 | Given an export in progress, when the user navigates away, then the export continues in the background and a completion notification appears | In progress | eng-marcus | What happens if the browser tab is closed entirely, not just navigated away from? |
| AC-3 | Given a Free-plan workspace, when the user requests an export over 5,000 rows, then the export is blocked with an upgrade prompt | Not started | eng-marcus | Does the upgrade prompt log a conversion event for growth? |
| AC-4 | Given a completed export, when the user clicks the download link after 24 hours, then the link returns an expired-file error, not a broken download | Tested | eng-lisa | — |
Two things happen when you write it this way instead of a prose paragraph. First, the open question column becomes a punch list, not a vague worry — AC-2 isn't "ready" because there's a real unresolved question with a name attached to it, not because the code is unfinished. Second, ambiguity surfaces where it's cheap to fix: in review, not in a support ticket three weeks post-launch.
If your acceptance criteria hinge on how records relate to each other — the export example above depends entirely on how workspace, record, and plan-limit entities connect — the underlying data model needs the same scrutiny the criteria got. Our PM's guide to reviewing a data model walks through validating those relationships before they turn into exactly the kind of edge-case bug AC-3 is trying to prevent. And if the release includes new screens, don't just describe the flow in the spec — click through it in an actual prototype. A written description and a real flow surface different bugs, which is the whole argument for building clickable wireframes before engineering starts, not after.
The Release Readiness Checklist Template
A usable release readiness checklist is one shared document — not five owners' private mental lists — with a row per gating item, a named owner, a status, and a place to record whatever's blocking it. Below is a version built from the five dimensions above; copy it and cut what doesn't apply to your release.
| Checklist item | Dimension | Owner | Status |
|---|---|---|---|
| All P0/P1 acceptance criteria have test coverage, automated or manual | Functional | QA lead | ☐ |
| Documented edge cases verified, not just the happy path | Functional | Eng | ☐ |
| Performance tested at expected peak load, not dev/staging load | Quality | Eng | ☐ |
| Security review done for any new data flows or permission changes | Quality | Security/Eng lead | ☐ |
| Accessibility pass complete — keyboard nav, screen reader, contrast | Quality | Design/Eng | ☐ |
| Monitoring and alerting exist for the new code path, with a named on-call owner | Operational | SRE/Eng | ☐ |
| Rollback has been executed in staging, not just theorized | Operational | Eng | ☐ |
| Feature flag or staged rollout plan defined | Operational | Eng + PM | ☐ |
| Support/CS briefed with a one-page "what changed, how to help" doc | Go-to-market | PM | ☐ |
| Docs / help center updated | Go-to-market | PM/docs | ☐ |
| Legal or compliance sign-off obtained if data handling changed | Go-to-market | Legal | ☐ |
| Every remaining open question has an owner and a decision date, or the list is empty | All | PM | ☐ |
Treat this as a stricter cousin of Scrum's Definition of Done — where DoD usually governs a single sprint's work, a release readiness checklist governs the whole shippable unit, across teams the sprint boundary doesn't touch (support, legal, marketing). A checklist item without an owner isn't a checklist item — it's a wish. Every row needs one name, not a team, next to it.
Don't let the checklist become theater. Filling in a checkmark because the box exists, rather than because the work happened, is worse than no checklist at all — it manufactures false confidence, which is a harder failure mode to catch than an honest "not ready."
Running the Readiness Review: Who Signs Off, and When
The readiness review isn't a meeting where you present a finished checklist for applause — it's a meeting where you force a decision on every unresolved row: ship as-is, ship behind a flag, delay, or explicitly accept the risk in writing with a name attached. A checklist with unresolved rows and no meeting is just a document nobody acted on.
Run it far enough before the target date that a "no" is still actionable — 48 to 72 hours ahead, not the morning of. Book the meeting when you set the ship date, not when you realize you need it. Keep the room small and specific: the PM, the engineering lead, whoever owns on-call, and anyone who owns an unresolved row. Everyone else gets the notes.
A workable authority split:
- PM owns the document — the checklist stays current, and the PM chases down owners for stale rows, but doesn't unilaterally overrule an engineering "not ready."
- Engineering lead owns technical readiness — quality, operational, and reversibility rows sit with them; they can block a ship even if every other row is green.
- On-call/SRE owns veto on operational readiness specifically — if there's no runbook and no alert, that's an automatic no, independent of how good the feature is.
- Anyone can flag risk; only named owners can clear it. A reviewer raising a concern doesn't get to also be the one who waves it through — that's how "we'll fix it after launch" quietly becomes the plan.
This is exactly where a static document starts to fail you. Acceptance criteria, open questions, and their status all need to live in one place that updates as engineering closes items out — not a doc that was accurate when it was written three sprints ago and has been diverging from reality ever since, which is the core argument in our piece on keeping your PRD a living document. Prodinja's Spec Studio is built around that same idea: requirements, acceptance criteria, and open questions stay in one structured PRD you can edit and version as the spec evolves, so the readiness review is checked against the current state of the spec, not a stale export of it.
Red Flags That Mean "Ready" Really Means "Rushed"
A handful of signals reliably predict that a checklist was filled out to satisfy the process rather than to answer the question — most involve either one person owning too many rows or "we'll fix it after launch" appearing more than once. Catch these before the review, not during the incident.
- One person filled out the whole checklist alone. Readiness spans five dimensions on purpose; nobody credibly self-certifies operational and go-to-market readiness from an engineering seat.
- "We'll fix it after launch" appears twice or more. Once is a judgment call. Twice is a pattern of moving risk past the gate instead of through it.
- Nobody in the room can name who gets paged. If the on-call owner is "the team" rather than a name, operational readiness isn't actually done — it's assumed.
- The rollback plan has never been executed, only described. A rollback plan that's never run is a hypothesis, not a plan.
- The readiness review got compressed to five minutes because the date was fixed before the scope was. That ordering problem — date first, scope second — is usually the real root cause, not whatever the checklist flags.
The cost of skipping this gate shows up in the data, not just anecdotally. Google's DORA research, published across several Accelerate State of DevOps reports (Forsgren, Humble, Kim), consistently finds that elite-performing teams post change failure rates in roughly the single digits to low teens, while low performers run several times higher — and the practices that separate the two groups are disproportionately about small, well-tested, reversible changes rather than raw engineering talent. A readiness checklist is a cheap way to buy your way toward the first group instead of the second.
Key Takeaways
- Readiness is five dimensions, not one: functional, quality, operational, go-to-market, and reversibility can each pass or fail independently — check all five, not just "does the code work."
- Acceptance criteria must be falsifiable. If two engineers testing independently could disagree on pass/fail, the criterion isn't done, no matter how much code sits behind it.
- Every checklist row needs a name, not a team. An unowned item isn't a checklist item — it's a wish that quietly becomes launch-day risk.
- Rollback has to be executed, not theorized. A rollback plan nobody has run is a hypothesis wearing a plan's clothes.
- Run the readiness review 48-72 hours out, while "no" is still actionable — not the morning of, when the only real options are ship or ship-with-regret.
- A stale spec makes the review meaningless. Acceptance criteria and open questions need to reflect the current state of the build, which is why the checklist should live in a document that updates as engineering closes items — not a static export from kickoff.
- "We'll fix it after launch" said more than once is a pattern, not a judgment call — treat the second instance as a signal to slow down, not a coincidence.
Frequently Asked Questions
What's the difference between a release readiness checklist and a definition of done?
A Definition of Done typically governs a single sprint's engineering work — code reviewed, tests passing, merged. A release readiness checklist governs the entire shippable unit across every function that touches it: support, legal, marketing, on-call. DoD can be fully green and release readiness can still be red.
How far in advance should you run a release readiness review?
Run it 48 to 72 hours before the target ship date, not the morning of. That window is long enough for a "not ready" verdict to still be actionable — closing a gap, briefing support, testing rollback — instead of forcing a binary choice between shipping broken and missing the date entirely.
Who should have final veto power on a go/no-go decision?
Split it by dimension rather than giving one person blanket veto: the engineering lead owns technical readiness (quality, operational, reversibility), and on-call/SRE holds an automatic veto specifically on operational gaps like missing runbooks or alerting, regardless of how polished the feature itself is.
What if the checklist is 90% done and the launch date is fixed?
Ship the 90% behind a feature flag to a limited audience, and treat the remaining 10% as explicitly accepted risk with a named owner and a written record of why — not as "basically ready." A fixed date is a reason to change scope or exposure, not a reason to skip the checklist.
Does every release need the full five-dimension checklist?
No — scale the checklist to the blast radius. A copy tweak or a config flag flip doesn't need a go-to-market row; a schema migration or a new billing flow needs every dimension, including legal. The habit that matters is asking which dimensions apply, not running all five reflexively every time.