What should a launch readiness review measure before go-live?
A measurement framework for launch readiness that separates evidence of readiness from status optimism.
Question and scope
This protocol asks what a launch readiness review should measure so the decision reflects evidence rather than confidence. The scope is one launch with a defined release date and a named launch owner. The review covers the customer path, the message, the support plan, the measurement plan, and the rollback route. It does not attempt to measure every project task.
The framework is intended for a small GTM team that cannot afford a large program office. It uses documents and test results the team already creates. The output is a short readiness record with a decision and open conditions. The record should be useful to the launch owner, support, sales, and the person who will handle a problem after release.
Readiness dimensions
Measure five dimensions: message approval, customer path, support readiness, measurement readiness, and recovery readiness. Message approval means the customer-facing claims have an approved source and owner. Customer path means a real user can complete the intended action in the release environment. Support readiness means the support team has the current answers and a route for unknown questions.
Measurement readiness means the team can see whether the launch worked and can distinguish a launch effect from normal variation. Recovery readiness means the team knows how to pause, roll back, or correct the release and who can authorize it. Each dimension should have at least one observable pass condition. A dimension with no evidence is open, not passed.
Measure definitions
Define the pass condition in advance and write it beside the evidence link. For the customer path, the condition might be a completed test by a person outside the build team, with the date and environment recorded. For support readiness, it might be a briefing completed and a current FAQ published. The definition should let a reviewer decide without asking what the owner meant.
Use a small number of measures per dimension, and avoid composite scores that hide a failed item. A readiness percentage can be useful for a dashboard, but the decision needs the underlying pass and open list. Report the count of passed dimensions, the count of open dimensions, and the severity of each open item. A weighted score is optional and should never replace the named gaps.
Evidence standard
Require evidence that a reviewer can open and check. A statement that the message is approved is not evidence unless it links to the approved copy and the approver. A statement that support is ready is not evidence unless it links to the briefing record or the published FAQ. The evidence standard should be the same for every launch so owners know what to prepare.
Accept a documented exception when evidence cannot be produced before the decision. The exception should name the risk, the mitigation, the owner, and the review date. Do not accept a verbal assurance in place of a document when the document is normally available. The purpose is not to create paperwork for its own sake, but to make the decision traceable.
Sampling and timing
Review the full set of five dimensions for every launch, not a sample. The number is small enough to cover, and a missing dimension can be the one that causes the problem. For a large program with several launches, sample the launches by risk tier and state the rule. A high-risk launch should always receive a full review.
Close the evidence packet at least one business day before the decision. That gap allows the launch lead to read the evidence and route gaps back to owners. If a launch moves quickly, shorten the window but keep the sequence: evidence, review, decision. A decision made before the evidence is complete is a forecast, not a readiness review.
Reporting and decision rule
Report the decision in one of three states: go, conditional go, or hold. A go means every dimension passed or has an accepted exception with an owner. A conditional go means the release can proceed only if named conditions are met by a stated time. A hold means at least one open item is severe enough to stop the release.
For every open item, record the consequence, the mitigation, the owner, and the deadline. The decision owner should state which evidence changed their view, especially when the recommendation was to hold. This note helps the team learn which checks predict real problems. It also prevents a later reviewer from seeing only the final decision without its reasoning.
Limits and sources of error
A readiness review can suffer from optimistic evidence, where owners mark a check as passed because the work is nearly done. It can also suffer from scope creep, where the review expands into a full project audit. Keep the dimensions fixed for the launch type and reject additions that do not affect the release decision. A short review done consistently is better than a broad review done once.
The review cannot prove that a launch will succeed. It can show whether the team has evidence for the conditions it chose to require. The cited public sources describe control and security practice; they do not define a universal launch readiness standard. Treat the framework as a local operating choice and review it after each launch.
Review cadence
Debrief the review within three days of the decision. Ask which checks caught a real problem and which produced no useful signal. Record the answer against each dimension, then choose one or two changes for the next launch. Do not change the whole framework after a single result. Record the debrief notes beside the launch decision so the next review can use them.
Revisit the framework quarterly or when the launch type changes. Keep the pass conditions and the evidence standard visible so new owners can prepare. Compare several launches before deciding that a dimension is unnecessary. The aim is a stable decision process that improves as the team learns. A stable framework is easier to improve than a new one for every launch.
Evidence review in practice
Run the evidence review as a short working session, not a presentation. Open the packet, pick two or three checks, and ask the owner to show the evidence. If the evidence is a document, read the relevant section together. This catches a pass that was marked on the basis of a draft or an assumption.
Record the result of the session against each check. If a check is open, write the specific missing item and the owner. Do not let the session turn into a debate about the launch strategy. The review is there to test readiness, and the strategy discussion belongs in a different forum. Send the open list to the launch lead before the exception window opens.
When the launch scope changes
A scope change after the readiness review requires a new check on the dimensions it affects. If the release adds a new customer segment, the customer path and support checks may need another test. If it removes a feature, the message and enablement checks may need an update. Record the change and the reason for the added review.
Do not reuse the old decision without a note. State which evidence still applies and which must be refreshed. The launch lead decides whether the change is small enough for a written update or large enough to reopen the gate. A scope change that bypasses the gate is a silent exception. If the change is material, the full five-dimension review should run again.
Using the result after launch
Compare the readiness record with what happened after release. Look for a check that passed but later produced a support issue, or a check that was open but caused no problem. Record the observation without assuming the check was wrong. A single launch is not enough to judge a check, but a pattern is useful.
Update the check definitions only when the evidence supports a change. Keep the old definition in the history. Tell the owners what changed before the next launch. The goal is a readiness process that learns from real outcomes, not one that adds a new check after every surprise. A definition that changes without evidence makes the next comparison harder.