A release readiness presentation should let the person with approval authority answer three questions: what exactly would go live, what evidence supports that change, and what happens if it fails? Lead with the requested decision, show unresolved conditions beside the evidence, and finish with a record of who authorized what. A row of green status icons is not enough.
Prepare the reviewed release notes first. You can then use Presenti to turn that text into an editable presentation draft, keeping evidence references and approval conditions in the slides. The example below follows a fictional appointment-booking service through a go/no-go meeting. Its records, timings, and thresholds are teaching examples, not results from a real deployment.
Name the release and the decision before showing progress
The team wants to release version 2.4, which changes how customers reserve and cancel appointment slots. Pricing, account migration, and the mobile app are outside this release. The candidate under review is build 2.4-rc3, with configuration set C17 and a new database migration. The proposed first exposure is ten internal test accounts, followed by a separate decision about customer access.
At the review, booking tests have passed. Notification delays are still being investigated. A rollback rehearsal covered the previous candidate, not rc3 and its migration. The opening slide should therefore say:
Recommendation: hold the rc3 pilot. Booking behavior has supporting test evidence, but recovery from this candidate has not been demonstrated. Resolve the recovery condition and characterize the notification delay before requesting pilot authorization.
That is a more useful opening than “Release 2.4 is 95% ready.” A percentage combines items that do not carry the same consequences. A missing recovery result cannot be cancelled out by several completed documentation tasks.
Put the build, configuration, review time, and requested exposure on this first slide. If a build or configuration changes during the meeting, the group needs to know which evidence still applies. Avoid quietly transferring an earlier candidate’s approval to a new artifact.
Show what each result actually supports
Use a short evidence panel, with the detailed records available separately. Each line should connect a claim to its scope and its remaining gap. “Tests passed” is too broad if the tests covered only internal accounts or one payment route.
| Area | Evidence in this fictional review | Decision implication |
|---|---|---|
| Booking behavior | QA-42 records creation, cancellation, and concurrent reservation tests on rc3/C17 in preproduction. | Supports those tested paths. It does not establish behavior under every customer workload. |
| Notifications | MAIL-9 records delayed confirmation messages during a retry test; the maximum delay and cause remain unresolved. | Keep the exception visible. Do not label notifications ready or assume the delay is harmless. |
| Recovery | RB-14 exercised the previous candidate. There is no rehearsal record for rc3 with its migration. | The agreed recovery condition is not met; current recommendation is hold. |
| Support coverage | OPS-6 names a primary responder, a deputy, the pilot window, and the escalation route. | Coverage exists for that window, not indefinitely or for an expanded launch. |
QA-42 and the other labels are example record IDs. In your own deck, make the equivalent references lead to the actual results, including environment, candidate, and time. Keep personal details and operational secrets in appropriately restricted records rather than copying them into a widely shared presentation.
Google’s discussion of reliable product launches emphasizes concrete, practical checks tailored to the service. Its historical launch checklist includes failure behavior, monitoring, recovery, and staged rollout. Use those as questions to adapt, not as a universal approval standard or evidence that your own service has passed.
Separate a blocker from an accepted exception
Before the meeting, agree which conditions require a hold and which can be considered for an explicitly limited release. Otherwise “amber” becomes a negotiation about color rather than a decision about exposure.
For this example, the team’s agreed rule is that the candidate’s recovery path must be demonstrated before any pilot deployment. That makes the missing rc3 rehearsal a blocker. The chair cannot turn it into an accepted exception merely by shrinking the audience from customers to ten employees.
The email delay is a different question. Could a narrowly scoped pilot proceed with that limitation? The group would first need to know the observed delay, whether booking state remains correct, what participants will see, and who can stop the pilot. “We have a workaround” does not answer those questions.
Give each proposed exception a small, readable record: limitation; affected users; evidence; temporary control; accountable role; expiry or review point. An exception without a defined audience and end point is an open-ended change to the release promise.
Keep three outcomes distinct. Go authorizes the stated scope under the agreed conditions. Restricted go authorizes a smaller, precisely described exposure. No-go leaves the proposed change unauthorized until the specified evidence and decision are revisited. None of these labels gives the presenter authority they do not otherwise have.
Draw a release path with a way back
A timeline that ends at “deploy” hides the work the approval depends on. Draw the proposed route as a short sequence, with a decision or stop condition between stages:
- Before exposure: complete the rc3 recovery rehearsal and characterize MAIL-9; attach the records to the new review.
- Authorization: the designated release authority decides whether the specific candidate may enter the ten-account pilot.
- Limited observation: named responders watch booking correctness, notifications, and the agreed monitoring signals during the pilot window.
- Next decision: remain limited, stop and recover, or request broader exposure. The first approval does not automatically authorize the last option.
For illustration, suppose a later review agrees to stop the pilot on any confirmed double-booking, a confirmation delay exceeding five minutes, or loss of the monitoring needed to observe either condition. These are example service-specific limits, not recommended defaults. A thirty-minute observation window could be part of that limited pilot; it would not establish reliability at a larger scale.
Put the stop authority beside the stop condition. In this example, the on-call lead may halt the pilot, while the release authority decides whether it can resume. Link the recovery route to the approved runbook; do not try to turn a presentation into executable deployment instructions.
For the migration, ask what “back” means. Can the previous application read records written by the new one? Does recovery require reconciliation of appointments created during the pilot? Show the known answer or the missing evidence. Switching application versions is not, by itself, proof that data has returned to a usable state.
Give the review six slides, not six status reports
A short review deck can follow the decision without repeating every team’s weekly report:
- “Hold the rc3 pilot until recovery is demonstrated.” Name the candidate, scope, recommendation, and approving role.
- “Booking tests support the tested paths; two conditions remain open.” Show the evidence panel and its limits.
- “The previous rollback result does not cover this migration.” Explain the blocking gap and the exact result needed.
- “The first approval would cover ten accounts only.” Show the staged route, observation window, and stop authority.
- “Support is staffed for the proposed window.” Name roles, deputy coverage, and the handoff after that window.
- “Record the decision and the conditions for another review.” Leave the meeting with a specific disposition.
The first slide is the recommendation; the last records the actual decision. They can differ. If the group changes the requested scope, record the change rather than editing the opening slide later and losing the history of what was considered.
To prepare a draft, paste the six headings and their reviewed evidence beneath them. A useful instruction is: “Keep rc3/C17 unchanged. Preserve the hold recommendation and unresolved recovery condition. Separate evidence, proposed future stages, and authorization. Do not invent test results, approval names, rollout dates, or performance improvements.” Review the generated wording before designing the final page; a neat layout must not turn a proposed stage into an approved one.
Leave with a completed decision record
Here is the record from the fictional meeting. It is short enough to read aloud before the attendees leave:
Decision: No-go for the proposed rc3/C17 ten-account pilot, recorded at the 14:00 review. No customer exposure is authorized.
Reason: Recovery evidence does not cover the candidate’s migration. Notification delay is not yet characterized.
Next evidence: Engineering lead supplies the candidate-specific recovery result, including treatment of newly created appointments. Notification owner supplies the delay investigation and proposed pilot limitation.
Decision owner: The designated release authority reconvenes the review when those records are available. The suggested 16:00 checkpoint is for a status update, not permission to deploy at 16:00.
Unchanged scope: The customer rollout, mobile app, pricing, and account migration remain outside this decision.
Send that record with the deck and evidence references. If the next meeting reaches a different decision, add a new entry for the candidate and conditions considered then. The presentation has done its job when a person who missed the meeting can tell what was authorized, what was withheld, and what must happen next.
