GTMGO TO MARKETPLAYBOOKS
← All toolsLAUNCH OPERATIONS · FREE TOOL

Run a launch
readiness audit.

Check ten release and promotion gates. See which evidence blocks the launch, who owns the next action, and whether to hold, limit the release, or take a public-launch candidate to the accountable owner. Download the decision brief for the review.

Invented scenario · no signup · editable
SAMPLE OUTPUT · FICTIONAL LAUNCH

Hold the release.

The product path works, but no support owner has handled a test escalation. The audit names that failed gate, its owner, and what evidence would change the decision.

Check your ten gates ↓
01 · CURRENT CALLHold release

Support route is blocked. Assign a responder and verify a test ticket.

02 · NEXT POSSIBLE CALLControlled release

After core gates pass, limit eligibility and set a dated review. Keep broad promotion on hold.

03 · PUBLIC CANDIDATEEvidence complete

Verify all applicable promotion gates, then take the brief to the accountable owner.

Load the fictional example, replace it with approved evidence, and download a decision brief. See executive, launch-owner, and technical formats →

How the recommendation works

Five release gates must be resolved before any release. A controlled audience, accountable owner, and next review date are also required. Five more conditions must be resolved before broad promotion. “Verified” needs evidence and an owner; “not applicable” needs a reason and an owner.

Everything stays in this browser tab. The downloadable brief is generated on your device. Use generic or approved information; do not enter confidential details.

01 · CONTEXT

Define the decision.

02 · EVIDENCE GATES

Check what is actually ready.

Open a gate to add evidence, an owner, and an action. An unchecked gate never counts as complete.

01Audience and controlled cohortRequired for any releaseOpen

Who is eligible, and who can receive a limited release?

02Product scope and limitationsRequired for any releaseOpen

What works now, what is excluded, and how were limits checked?

03Support and escalation ownershipRequired for any releaseOpen

Who handles an issue, and how does it escalate?

04Billing, legal, privacy, and security reviewRequired for any releaseOpen

Record the relevant reviews or a reason each does not apply.

05Issue triage and pause authorityRequired for any releaseOpen

Who can pause the release and how will issues be reviewed?

06Positioning claim and supporting proofRequired for public launchOpen

What can you safely promise to a broad audience today?

07Offer, price, and eligibility termsRequired for public launchOpen

Can a buyer understand exactly what they will receive?

08Sales, success, and customer communicationRequired for public launchOpen

Can customer-facing teams explain the change consistently?

09Primary outcome measurementRequired for public launchOpen

Has the customer journey been tested end to end in the analytics source?

10Seven-day and 30-day decision reviewsRequired for public launchOpen

Are owners, measures, and continue or pause rules scheduled?

See three finished audience briefs and a filled launch readiness audit, then use the launch playbook to plan the work behind these gates.

What belongs in a launch readiness review?

Bring the release scope, controlled audience, customer promise, owner for each open gate, and evidence that the promised path works. A calendar date and a green status label are not substitutes for a tested support route, measured activation event, or accurate customer message.

Review after the release

First week: compare actual eligibility, issue volume, support response, and the activation event with the launch plan. Name one owner for any gap and decide whether to continue the controlled release, pause, or change the message.

First month: review adoption quality, unresolved issues, customer feedback, and whether the expected outcome occurred. Record a continue, revise, or stop decision with a next review date. Use the downloaded brief as the decision record.