Launch Management

A launch coordinates product availability with customer promises. Match the process to its impact, verify each function’s readiness and judge the result against predictions recorded before launch.

Why this matters

Working code can still launch badly if availability claims, billing, support or legal terms are unready. Cross-functional readiness is part of the product promise.

Use a proportional process: minor changes need a lighter path, while new prices, offers and trust boundaries need broader review. Set adoption and business targets before announcing, so reach metrics cannot substitute for results.

AI adds ongoing behavior changes from models, prompts and infrastructure. Give those changes a release path too. Positioning (Chapter 24) feeds the launch plan. Events and enablement (Chapters 26–27) run alongside it.

What a launch is, and how big this one is

Every externally visible change is a launch

Google SRE’s reliable-launch chapter defines a launch as an externally visible code change. Its account describes up to 70 weekly launches. Standard checklists and risk classes let routine changes take a lighter path.

Create a cheap default path and a fuller path for changes to what customers buy, how they buy or what they entrust to you.

Launch tiers

Three launch tiers are common practice. This book’s synthesis uses customer and business impact. A small pricing change can need more coordination than an invisible re-platforming.

The PM proposes the tier and the launch owner confirms it. Increase scrutiny when AI changes customer-facing actions. An agent acting in production is tier 1 because it introduces trust exposure, regardless of code size.

Release stages: design partners to general availability

What the labels mean

Publish stage definitions and use them consistently. These public models provide useful starting points.

GitHub defines private preview as actively developing, potentially undocumented and without SLA or support. Public preview is documented and broadly distributed, still without SLA or support. General availability (GA) is production-ready, tested and supported under applicable obligations.

GitLab uses experiment, beta, limited availability (LA) and GA. LA is production-ready and fully supported at a restricted platform scope or scale. It has GA-level security requirements, logging and runbooks, but no explicit SLA. An initially free LA feature may later be paid.

Use LA for supported production use within explicit scope, while operations, pricing or coverage mature.

Map your program names onto these stages so nobody has to guess:

The label is a contract

Preview terms can exclude production use, support, personal-data processing and continuity of stored work. AWS’s terms exclude SLAs, allow suspension and changes, treat beta feedback as confidential and warn that content may not carry over. Azure’s early-access terms restrict use to testing and feedback and may permit monitoring of generative-AI content for abuse. Have legal review your actual promises.

Match the stage, signed terms, seller talk track and FAQ. Explain transitions, including price, data handling and retained work. “Basically GA” cannot override the contract.

Separate deploy from release

Separate deployment from release (Chapter 06). Pete Hodgson’s permissioning toggles control customer eligibility. Ops toggles provide kill switches. A build can pass through stages by changing eligibility.

Danilo Sato distinguishes canaries, which limit exposure to reduce risk, from A/B tests, which evaluate a hypothesis. Keep their success criteria separate even when they share infrastructure.

Early access for B2B AI is a governance decision

For business AI previews, let customer administrators control opt-in and eligible users, features and actions. Microsoft’s Frontier program illustrates this organizational consent model.

Launch readiness across functions

The checklist

Google’s engineering checklist covers architecture, dependencies, capacity, failure modes, clients, automation and rollout. Klau describes announcement-driven traffic reaching roughly 25 times normal peak. Give engineering the marketing plan as a capacity input.

Extend readiness across functions. Each row needs an owner, agreed acceptance criteria, evidence and status: green, amber with a plan, or red.

The checklist’s value comes from making each owner say “ready” in writing, against a definition agreed weeks earlier.

The go/no-go review

NASA’s readiness polls provide two transferable rules: each function reports its own status on the record, and one named leader decides.

Hold the review before scope or timing becomes impossible to change. Owners state readiness. A red blocks launch unless the decider records explicit risk acceptance, an owner and a resolution date. Log one of three outcomes:

• Go: everything is green or amber with a plan.
• Go with conditions: the launch proceeds at a reduced stage or scope, with named conditions and dates (for example, announce and open early access, but hold GA until billing passes a test invoice).
• No-go: the launch moves, with a new date and the evidence needed to reach go.

Hold the review early enough that “go with conditions” is still a real option.

The announcement artifacts

From PR/FAQ to launch day

Bryar and Carr’s Working Backwards starts with a press release under one page and up to five FAQ pages. Teams revise the PR/FAQ with leaders before building. Most do not become products, which the authors regard as useful filtering.

The press release covers product, customer benefit, date, customer problem, solution, alternatives, approved quotes and getting started. The external FAQ covers customer and press questions. The internal FAQ adds competition, market, economics, investment, dependencies, regulation and failure risks.

Chapter 02 uses the PR/FAQ as a vision artifact and Chapter 04 contrasts it with the PRD. At launch, the PR/FAQ forks into the real announcement artifacts:

Compare the original PR/FAQ with the actual release. Explain changed scope, quotes, prices and dates in the internal FAQ so the field can correct old promises.

Release notes

Release notes are the whole announcement for tier 3 and part of every tier. Olivier Lacan’s Keep a Changelog principles apply: release notes are for people, not machines; there’s an entry per version, dated, with the latest first; and changes are grouped by type: Added, Changed, Deprecated, Removed, Fixed and Security. For AI features this book adds a seventh group, Model and behavior changes, covering the model version, eval results that moved and known regressions. That heading is this book’s extension, not part of Lacan’s format.

The communications timeline

The weeks below are a typical shape for a tier 1 enterprise launch tied to an event. Adjust them to your sales cycle and event calendar.

Sequence the internal audiences ahead of the external ones. Support and sales should never learn about a launch from a customer.

Measuring launch success

Record success measures and baselines in the launch plan. Use four groups:

• Leading indicators (days to weeks). Activation of the new capability by target accounts, early access to paid conversion, support tickets per active account, enablement completion and early task-success signals for the feature itself.
• Lagging indicators (one to two quarters). Pipeline influenced by the launch and win rate in deals where the capability was shown, expansion revenue, retention of adopting accounts and movement in the product’s North Star.
• Guardrails (watched throughout). The things the launch must not damage: support load on existing customers, reliability and cost to serve. For AI features add the error signals your evals track, such as wrong or reverted actions. A launch that hits its adoption target while breaching a guardrail hasn’t succeeded.
• Reach (reported, never the goal). Press coverage, event attendance, blog traffic and social mentions. Reach tells you whether people heard. It can’t tell you whether anyone changed what they do.

The post-launch review

Lunney and Lueder describe Google’s blameless postmortems as written records of impact, mitigation, causes and actions, reviewed and shared. Apply the pattern to successful and unsuccessful launches.

Review tier 1 at 30 and 90 days, tier 2 at 30 days, and any conditional launch or rollback. Ask what you predicted, what happened, why it differed and what changes. Keep the review blameless so teams can expose risks honestly.

The most valuable output is often a change to the launch process itself: a new checklist row, a different tier criterion or an earlier go/no-go. If a review produces no changes, check whether it asked why the numbers differed or only reported them.

How to apply it

Use this schedule for tier 1. Compress to six weeks for tier 2 and omit tier-1-only work. For tier 3, use steps 1 and 9.

Twelve weeks out: size and frame it.

1. Propose the tier in writing. Score the launch against the tier criteria and get the launch council to confirm it. If it’s an AI feature that acts on the customer’s behalf, start at tier 1.
2. Write the launch plan. Goal, audience, positioning (from Chapter 24), the stage plan, success metrics with baselines, the communications timeline, owners and the date the go/no-go will be held. Add a stage plan for autonomy if the feature is AI-powered.
3. Refresh the PR/FAQ. Bring the inception PR/FAQ up to date with what’s actually shipping and run the gap analysis. Every difference becomes a line in the internal FAQ.

Eight to six weeks out: line up the functions.

4. Open the readiness checklist. Name an owner per function and agree each definition of ready now, while it’s still cheap to change. Link it from the launch plan.
5. Design the early access program. Decide entry criteria, the number of accounts, what you need to learn, the exit criteria to the next stage, and the terms. Have legal confirm the stage label matches the terms customers will sign.
6. Start enablement. Sales and support need the talk track, the internal FAQ and the “what we don’t say” list before anyone briefs a customer (Chapter 27).

Four to two weeks out: write and decide.

7. Draft the announcement artifacts. Press release, blog post, customer FAQ, internal FAQ, release notes and, for AI features, the transparency note. Have legal review every claim against evidence.
8. Run the go/no-go review. Each owner reads their status. Record go, go with conditions or no-go, with any risk acceptance and its owner. Tell the field the result the same day.

Launch and after: measure against the prediction.

9. Ship by stage. Flip permissioning toggles for the stage, staff the launch channel, and read leading indicators daily for the first week and weekly after that.
10. Fix the artifacts in week one. The questions customers actually ask in the first week will differ from the ones you predicted. Update the customer FAQ, docs and support macros.
11. Hold the post-launch reviews. At 30 and 90 days, compare predicted with actual, blamelessly. Record what changes in the product and in the launch process.
12. Move stages on evidence. Promote from early access to LA to GA when the exit criteria are met, not when the calendar says so. Each promotion is a smaller launch with its own release notes and customer communication.

Salesforce’s Agentforce launch shows the announce-then-stage pattern in public. The September 2024 announcement named a general availability date about six weeks out, stated pricing of $2 per conversation, said some components would follow in February 2025 and quoted a piloting customer. Agentforce was announced as generally available in late October. You can announce at the flagship moment and keep stages honest, as long as the announcement says plainly what’s available today, what’s coming and when.

The AI lens

Launching AI-powered products

AI features change launch management in five ways.

Staged autonomy runs alongside staged availability. Chapter 31 describes the autonomy ladder: shadow mode, assisted, supervised and autonomous for allowlisted actions, with a kill switch. Availability and autonomy are separate axes, and a feature can be GA for suggestions while in early access for actions. Write the autonomy ceiling for each stage, let each customer’s admin choose a level at or below it, and move between levels on eval and production evidence, not on the launch calendar.

Model changes are launches. If your product runs on a foundation model, your launch calendar inherits your provider’s. Anthropic’s documentation describes a model lifecycle of active, legacy, deprecated and retired, and commits to notifying customers with active deployments at least 60 days before retiring a publicly released model, by email and in its documentation. When an upstream model retires you have to swap it, and the swap can change how your feature writes, reasons and fails. Give every model change a tier (usually tier 2), run your evals before and after, publish the results under “Model and behavior changes” in the release notes and tell customers before the change, not after.

Users get attached to how a model behaves as well as what it can do. When OpenAI launched GPT-5 in August 2025, older models were removed from ChatGPT for many users, some users objected, and within days OpenAI restored the previous model as an option. Stripe’s approach to API versioning is the enterprise discipline to borrow: Brandur Leach describes how Stripe pins each account to the API version current at its first request and, as of 2017, had kept compatibility with every version since 2011, treating the API as a long-term contract. For an AI platform, the equivalent is a pinning window: let customers stay on the previous model for a stated period while they test the new one, when the economics allow it.

Quality can regress without any launch at all. In September 2025 Anthropic published a postmortem of three infrastructure bugs that had degraded some Claude responses over several weeks. None was a model change. Detection was slow because standard evals didn’t catch the problems, privacy controls limited engineers’ access to user interactions not submitted as feedback, and symptoms differed by platform, so reports looked inconsistent. Anthropic committed to more sensitive evals, continuous quality evals on production systems and faster ways to debug community feedback. Pre-launch evals aren’t enough. Name the production quality evals that run after launch, and read support tickets and community channels in the post-launch review, because customers often notice drift before dashboards do.

Behavior is a go/no-go criterion. In April 2025 OpenAI rolled back a GPT-4o update after users reported overly flattering, agreeable behavior. Behavior like that is hard to capture in a metric and easy for a person using the product to spot. Give a qualitative reviewer, someone who has used the feature on real tasks, a formal line in the go/no-go with the same standing as engineering and security. If that person says the behavior is off, that’s a red even when the eval dashboard is green.

AI disclosure is a readiness row. Disclosure rules now come from several jurisdictions. Article 50 of the EU AI Act applies from 2 August 2026. It requires that people interacting directly with an AI system are told so unless that’s obvious from context, that synthetic text, audio, image and video outputs are marked in a machine-readable way (with exceptions for systems that only assist editing), and that the information is clear and given at the latest at first interaction. In the United States, a 2025 special session of the Colorado legislature delayed the duties in Colorado’s AI Act to 30 June 2026; check its current status with counsel, because state AI laws are still moving. Chapter 33 covers what these laws require. For the launch, the point is ownership: AI disclosure is a checklist row owned jointly by product and legal, and the customer FAQ states what the product marks as AI-generated and where.

For tier 1 AI launches, add a transparency note to the artifact set. Microsoft’s transparency note for Azure OpenAI explains how the system works, its capabilities, intended uses, limitations, performance and the choices deployers make that affect behavior, and it treats the system as technology plus people plus deployment environment. That’s the document a buyer’s security and compliance reviewer asks for. Having it ready on launch day means the first deals don’t wait while you write it.

Doing launch work with AI

Use a connected harness to coordinate launch documents and evidence:

• Readiness status. Ask the harness to read the checklist and its evidence links and draft each row’s status with what’s missing. It’ll catch the “green” row whose evidence link points at an empty page. The owner still states the status in the go/no-go.
• Artifact drafting and consistency. Draft the FAQs and release notes from the PRD, the PR/FAQ and the merged changes, then ask the harness to check every artifact for contradictions in stage labels, dates, prices and claims. Cross-document checks like this are slow for people and quick for a model.
• Claims review. Have the harness list every factual claim in the press release and blog post with the evidence behind it, and flag claims without evidence. Legal still decides, but they start from a list.
• Launch-day listening. Summarize support tickets, community threads and sales call notes daily in the first week, clustered by issue and linked to sources. For AI features, ask specifically for complaints about behavior.
• Post-launch review assembly. Pull the predicted metrics from the launch plan, the actuals from the analytics reports (Chapter 18) and the decision log, and draft the comparison. The “why it differed” section is yours.

Three rules apply. A person approves everything external; the harness never publishes or sends. Use only tools approved for confidential and customer data, because launch materials are often under embargo and support tickets contain customer information. And every status, claim and finding the harness drafts links to its source.

The Beacon case: launching Beacon Agents at Northlight Live

The tier. Beacon Agents meets three tier 1 criteria: new trust exposure (an agent that acts in customers’ production environments), a new price (the move toward per-resolved-incident pricing) and a pipeline target tied to Northlight’s flagship event. The VP of Product is the go/no-go decider. In the same quarter, multi-tenant views for MSPs like Leo’s are confirmed as a separate tier 2 launch, so they don’t ride on the tier 1 announcement.

The stage plan. Availability follows Chapter 06’s release plan: dogfooding on Northlight Observe’s own on-call rotation, five design partners under NDA (private preview), the opt-in beta that Chapter 06 planned, run as an early access program announced at Northlight Live (preview terms, no SLA), limited availability on Northlight Observe and the most-used cloud connectors, then GA by region with the EU last, because the AI Act documentation must be complete first. Autonomy has its own ceilings: design partners start in shadow mode and move to supervised rollbacks; early access is supervised only, approving each step; allowlisted autonomy for low-risk actions opens at LA, for accounts whose admin opts in. Sam, the security reviewer persona, gets the control Microsoft’s Frontier program gives IT admins: early access is enabled per tenant by the customer’s admin, and each action type is allowlisted separately.

The go/no-go. Held ten days before Northlight Live, so a conditional go is still possible. The readiness table:

The billing red decides the shape of the launch. If the meter can’t agree with the customer’s own record of what was resolved, per-resolved-incident pricing will produce invoice disputes, and the pricing is already a strategic bet (Chapter 03 lists the pricing pilot as Next, not Now). The VP records go with conditions: announce Beacon Agents and open early access on current platform pricing; announce the per-resolved-incident pricing pilot as a later, dated step with no price in the press release; rehearse the support runbook before the event; and hold LA until billing passes a test invoice against design partner data.

The artifacts. The gap analysis against the inception PR/FAQ (Chapters 02 and 04) shows three differences. The headline still centers on Dana opening an incident that’s already diagnosed, with a proposed rollback waiting for approval. But the inception draft assumed GA at Northlight Live, several runbook actions and a per-incident price; the launch release says early access, rollback first and pricing to come. Each difference goes into the internal FAQ with its reason, so sellers who saw the old vision deck know what changed.

The customer FAQ answers what Marcus, Priya and Sam will ask, from price at each stage to which actions can ever run without approval, how to switch it off, what data the agent reads and what Beacon labels as AI-generated in incident updates. The answer to “what happens if the agent is wrong?” is specific because the team learned it the hard way: in Chapter 31, a customer rolled back the wrong service after accepting a confident, wrong root cause. The FAQ explains the controls added since: every rollback needs approval during early access, every action is logged, and the eval set now includes that failure mode. The internal FAQ carries what customers won’t see: gross margin has fallen from 81% to 72% since agentic features launched, because of inference cost; the cost per resolved incident behind the pricing pilot; likely competitive responses; and what sales must not promise, starting with autonomous remediation in early access and any EU date. A Beacon Agents transparency note goes to every early access admin with the welcome email.

The metrics. The launch plan sets leading indicators for early access accounts: diagnosis acceptance with no reversion (the measure Chapter 05 adopted after the incident), the approved-action rate, early access to paid conversion at LA, and support tickets per active account. Lagging indicators: the autonomous resolution rate after LA, the North Star (incidents resolved with Beacon’s help per week), pipeline influenced by Northlight Live and net revenue retention among adopting accounts, against today’s 118%. Press coverage and keynote attendance are reported as reach.

The 30-day review. Early access enrollment beats the target, but approved-action rates vary widely by account. Accounts whose admin started with rollbacks for one service approve far more often than accounts that enabled everything at once, so allowlist templates join the LA exit criteria. The conditional go is judged justified: billing passed its test invoice in week three.

The first model change. Two months after LA, Beacon’s model provider announces a retirement with 60 days’ notice. The team runs the swap as a tier 2 launch: evals on the new model against the diagnosis and action sets, results under “Model and behavior changes” in the release notes, a notice to admins three weeks ahead and, for accounts that ask, a 30-day window on the previous model (a period the team chose for its own costs). Diagnosis acceptance is read before and after the switch.

Product 360 artifacts

# Launch tier matrix · [Product or portfolio] · v[n] · [Date]

**Owner:** [Launch council chair or product ops lead]   **Review:** every half year

## Tier criteria (a launch meets a tier when it meets any two of its criteria)
| | Tier 1 | Tier 2 | Tier 3 |
|---|---|---|---|
| New product, SKU or price | | | |
| Changes how buyers evaluate us | | | |
| Revenue or pipeline target attached | | | |
| Regulatory or trust exposure (AI autonomy, new data use) | | | |
| New capability for existing customers | | | |
| Changes an admin or user workflow | | | |
| Improvement, fix or minor change | | | |

AI rule: an AI feature that acts on the customer's behalf moves up one tier.

## What each tier gets
| | Tier 1 | Tier 2 | Tier 3 |
|---|---|---|---|
| Announcement artifacts | Press release, blog post, customer FAQ, internal FAQ, release notes, transparency note (AI) | Blog post, customer FAQ, internal FAQ, release notes | Release notes |
| Readiness | All nine functions | Affected functions | Docs and support |
| Rollout | Design partners, early access, LA, GA | Opt-in or percentage | Flag to GA |
| Enablement | Certification | Brief | None |
| Go/no-go decider | [VP or GM] | [PM lead] | [Engineering lead] |
| Post-launch review | 30 and 90 days | 30 days | On trigger |

## Stage definitions we use
| Stage | Access | Support | SLA | Production use | Price |
|---|---|---|---|---|---|
| Design partners (private preview) | Named accounts under NDA | Direct with product team | None | [Agreed in writing / no] | [Free / discounted] |
| Early access (preview) | Admin opt-in | Best effort | None | [No / at own risk] | [ ] |
| Limited availability | [Platforms, regions or scale limit] | Full | [None stated / ] | Yes, within scope | [ ] |
| General availability | All eligible customers | Full | [SLA] | Yes | List |

## Tier decisions this quarter
| Launch | Proposed tier | Criteria met | Confirmed by | Date |
|---|---|---|---|---|
| | | | | |

# Launch plan · [Launch name] · Tier [1/2/3] · [Date]

**Owner:** [PM]   **Go/no-go decider:** [Name]   **Launch date or range:** [ ]   **Go/no-go review date:** [ ]
**Links:** PR/FAQ · PRD · release plan (Chapter 06) · positioning (Chapter 24) · readiness checklist

## Goal
What changes for which customers, and the business outcome we expect: [one paragraph].

## Audience
Target segments and personas: [ ]. Who is excluded at this stage and why: [ ].

## Stage plan
| Stage | Entry criteria | Who | Autonomy ceiling (AI) | Exit criteria | Target date |
|---|---|---|---|---|---|
| Design partners | | | | | |
| Early access | | | | | |
| Limited availability | | | | | |
| General availability | | | | | |

Flags: release toggle [name], permissioning toggle [name], kill switch (ops toggle) [name], owner [name].

## Success metrics (set before launch)
| Type | Metric | Baseline | Target | When read | Source report |
|---|---|---|---|---|---|
| Leading | | | | | |
| Lagging | | | | | |
| Guardrail | | | | | |
| Reach (reported only) | | | | | |

## Communications timeline
| When | Audience | Artifact or channel | Owner | Status |
|---|---|---|---|---|
| T minus [n] weeks | Internal: sales, support | | | |
| T minus [n] weeks | Analysts, press (embargo) | | | |
| T | Customers, public | | | |
| T plus 1 week | Customers | FAQ and docs updates | | |

## AI-specific (AI features only)
- Model and version at launch: [ ]. Upstream retirement date if known: [ ].
- Production quality evals running after launch: [ ].
- Behavior reviewer for the go/no-go: [name].
- AI disclosure: what is labeled AI-generated, where: [ ].

## Post-launch review triggers
[Every tier 1 at 30 and 90 days; any conditional go; any rollback; any trigger metric crossing [threshold].]

## Risks and open questions
| Risk | Likelihood | Impact | Mitigation | Owner |
|---|---|---|---|---|
| | | | | |

# Launch readiness checklist · [Launch name] · Stage: [ ] · [Date]

Status: Green = ready · Amber = at risk, with a plan and date · Red = not ready
Definitions of ready are agreed by [date], before work is graded against them.

| Function | Owner | Ready means | Evidence link | Status | Note |
|---|---|---|---|---|---|
| Product | | Scope frozen for this stage; metrics and baselines set; customer FAQ approved | | | |
| Engineering | | Rollout plan, flags and kill switch; capacity tested against the marketing plan; rollback rehearsed | | | |
| Documentation | | Docs for every supported platform at this stage; release notes drafted; limitations stated | | | |
| Support | | Runbooks and macros; staff trained; launch ticket tag live; escalation path | | | |
| Sales | | Enablement complete; talk track states the stage; quoting works | | | |
| Legal | | Terms match the stage label; claims substantiated; AI disclosure reviewed | | | |
| Billing | | SKUs and meters live; test invoice correct; dispute path defined | | | |
| Security | | Review passed; audit logging and access controls verified; security docs ready | | | |
| Marketing | | Artifacts approved; channels and timeline set; spokespeople and references confirmed | | | |
| Behavior review (AI) | | Named reviewer has used the feature on real tasks and signs off on behavior | | | |

## Capacity inputs from marketing
Announcement channels and expected traffic: [ ]. Event demo load: [ ]. Confirmed with engineering on [date].

# Go/no-go review · [Launch name] · [Date] · T minus [n] days

**Decider:** [Name]   **Attendees:** [one owner per function]   **Readiness checklist:** [link]

## Status poll (each owner states their own)
| Function | Owner | Status | Open items |
|---|---|---|---|
| | | | |

## Reds and ambers
| Item | Risk if we launch anyway | Options | Owner |
|---|---|---|---|
| | | | |

## Decision
[ ] Go   [ ] Go with conditions   [ ] No-go

**Conditions (if any):**
1. [Condition] · Owner: [ ] · Due: [ ] · What happens if it is missed: [ ]

**Risk acceptances (any red launched over):**
- [Risk] accepted by [decider], owned by [name], resolved by [date].

**If no-go:** new date [ ], evidence needed to reach go [ ].

## Communicated
Field and support told on [date] by [name]. Decision log entry: [link].

# Early access program plan · [Feature] · [Date]

**Owner:** [PM]   **Stage:** Design partners (private preview) / Early access (preview)   **Runs:** [start] to [end]

## What we need to learn
1. [Learning goal, written as a question with a measurable answer]
2.
3.

## Who gets in
- Number of accounts: [n] (no more than we can talk to every two weeks)
- Entry criteria: [fit, environment, willingness to give feedback, named contact]
- Who opts in: [customer admin role]. What the admin controls: [features, agents, actions, users]
- Exclusions: [regions, regulated segments, platforms not yet supported]

## Terms (confirmed by legal)
- Production use: [allowed / not allowed / allowed with conditions]
- SLA and support: [ ]
- Confidentiality: [ ]
- Data handling, including any AI monitoring or retention: [ ]
- Price during the program and at graduation: [ ]
- What happens to the customer's work and configuration at the next stage: [ ]

## Cadence
Feedback sessions: [every two weeks]. Usage review: [weekly]. Program channel: [ ].

## Exit criteria to the next stage
| Criterion | Threshold | Current | Met? |
|---|---|---|---|
| | | | |

## Graduation communication
What each account is told, by whom and when, at graduation or at the end of the program: [ ].

# Announcement pack · [Launch name] · [Date]

## Press release (under one page)
**Heading:** [Product name]: [one-line descriptor]
**Subheading:** [Customer segment] can now [benefit].
**Summary:** [City], [date]. [What is available today, at which stage, and what comes later, with dates or ranges.]
**Problem:** [The customer's problem in their terms.]
**Solution:** [How it solves the problem and why it beats current alternatives, including doing nothing.]
**Spokesperson quote:** [ ]
**Customer quote:** [Real, approved, from a named design partner or early access customer.]
**Getting started:** [How to join, what it costs, where to learn more.]

## Launch blog post
- Title: [the customer outcome]
- Opening: a specific situation the reader recognizes
- What's new, at what stage, for whom
- A worked example with a real (approved) or clearly illustrative scenario
- What's next, without dates the plan doesn't support
- How to get access

## Release notes entry
### [Version or date]
- **Added:**
- **Changed:**
- **Deprecated:**
- **Removed:**
- **Fixed:**
- **Security:**
- **Model and behavior changes (AI):** model and version; eval results that moved; known regressions

## PR/FAQ gap analysis
| Inception PR/FAQ said | Launch release says | Why it changed | Who must know |
|---|---|---|---|
| | | | |

## Claims register
| Claim | Evidence | Reviewed by legal |
|---|---|---|
| | | |

# FAQs · [Launch name] · [Date]

## Customer FAQ (customers, admins, security reviewers)
1. What is available today, and at what stage?
2. What does it cost now, and what changes at [next stage]?
3. Who can turn it on, and how do I turn it off?
4. What data does it read, where is it processed and is it used for training?
5. What does it do without a person's approval, and who decides? (AI)
6. What happens if it gets something wrong? (AI)
7. What is labeled as AI-generated, and where? (AI)
8. What changes when the model changes, and how will we be told? (AI)
9. What support and SLA apply at this stage?
10. Where are the security documentation and transparency note?

## Internal FAQ (sales, support, leadership)
1. What changed between the inception PR/FAQ and launch, and why?
2. What can we say, and what must we not promise? (List.)
3. How does this compare with current alternatives and competitors?
4. What are the unit economics, including cost to serve and margin effect?
5. Which third parties does it depend on, including model providers and their retirement dates?
6. What regulatory or legal issues apply, and what has legal approved?
7. What are the top reasons this launch could fail, and what are we watching?
8. How do I get a customer into early access, and who approves it?
9. Who do I escalate to for a wrong action, a pricing dispute or a security question?

# Post-launch review · [Launch name] · [30 / 90] days · [Date]

**Owner:** [PM]   **Reviewed by:** [senior reviewer]   **Blameless:** we review systems and decisions, not people.

## Prediction against actual
| Metric | Type | Baseline | Predicted | Actual | Read |
|---|---|---|---|---|---|
| | Leading | | | | Above / on / below |
| | Lagging | | | | |
| | Guardrail | | | | |
| | Reach | | | | Reported only |

## What happened
Timeline of the launch and any incidents, rollbacks or stage changes: [ ].

## Why it differed
[Causes, with evidence. Include customer and support signals, not only dashboards.]

## Was the go/no-go right?
Conditions set: [ ]. Were they met on time? Was any risk acceptance justified?

## AI behavior (AI features only)
Production quality eval trend; behavior complaints from support and community; any model or infrastructure change since launch.

## Changes
| Change | In the product or the launch process? | Owner | Due |
|---|---|---|---|
| | | | |

## Stage decision
[Promote / hold / roll back], decided by [name] on [date]. Shared with [ ] and stored in [ ].

Prompts

Goal: Get a tier recommendation you can defend to the launch council.
Paste in: the PRD or one-pager, the tier matrix your company uses and any pricing or packaging change attached to the launch.

Act as a launch council member reviewing this launch for [product].

1. Score it against each tier criterion in the matrix. Quote the line in the PRD that supports each criterion you mark as met.
2. Recommend a tier. If the launch includes an AI feature that acts on the customer's behalf, apply the rule that moves it up one tier and say so.
3. List what that tier requires (artifacts, functions, rollout stages, decider, review dates) and which of those the PRD doesn't yet plan for.
4. Name the strongest argument for one tier higher and one tier lower.

Apply the matrix’s customer and business impact criteria. Cite evidence for each criterion met.

[PRD]
[tier matrix]

Check the output: confirm every "criterion met" has a quote behind it. If the tier rests on a criterion you can't evidence, the council will ask the same question.

Goal: Find the readiness rows that look green but aren't, before the go/no-go.
Paste in (or connect the harness to): the readiness checklist with its evidence links, the linked tickets and documents, and the launch plan. Use only tools approved for internal and confidential material.

For each row of this readiness checklist for [launch]:
1. Open the evidence link and say whether it shows the definition of ready is met, partly met or not met. Quote the evidence.
2. Propose a status (green, amber, red) and list what's missing.
3. Flag any row whose evidence link is empty, stale (older than [n] days) or points at something unrelated.
4. Flag dependencies between rows (for example, docs that depend on an unfinished engineering decision).

Propose green only where evidence meets the readiness definition. Each owner confirms their status in the review.

Check the output: open the evidence for every row the model proposes as green and every row it flags. Send each owner the proposals that differ from their own status before the meeting, not in it.

Goal: Catch contradictions across the press release, blog post, FAQs and release notes before customers do.
Paste in: all draft announcement artifacts, the launch plan (stage plan, dates, pricing) and the stage definitions your company uses.

Compare these launch artifacts for [launch] against the launch plan.

1. Build a table of every statement about stage, availability, dates, price, supported platforms, autonomy and data use, with the artifact and line it appears in.
2. Flag every contradiction between artifacts, and every statement that contradicts the launch plan or uses a stage label differently from our definitions.
3. Flag any wording that implies general availability, an SLA or production readiness for something at a preview stage.
4. List every factual claim (numbers, customer results, comparisons) with the evidence I've supplied for it, and mark claims with no evidence.

Return a discrepancy report for the supplied artifacts.

[artifacts]
[launch plan]

Check the output: verify each flagged contradiction yourself. Send the unsupported-claims list to legal as a starting point, not as their review.

Goal: Answer the questions security reviewers and admins will ask, before they ask them.
Paste in: the PRD and AI addendum, the stage plan, the preview or GA terms, the security documentation and any questions already raised by design partners. Remove customer identifiers first.

Draft a customer FAQ for [feature] at the [stage] stage. Write for three readers: the admin who turns it on, the security reviewer who approves it and the user who relies on it.

Cover: what's available now and what's coming; price now and at the next stage; who can turn it on and off; what data it reads, where it's processed and whether it's used for training; what it does without approval and who decides; what happens when it's wrong; what's labeled as AI-generated; how model changes are communicated; support and SLA at this stage.

Rules:
- Answer only from the material provided. Where it doesn't answer a question, write "[Open: needs answer from owner]".
- Match the stage terms exactly. Never imply production readiness or an SLA the terms don't give.
- Use plain, specific language.

Check the output: have legal and security read the data, terms and disclosure answers. Make sure every "[Open]" has an owner before the go/no-go.

Goal: Treat a model swap as a launch, with evidence and notice.
Paste in: the provider's deprecation or retirement notice, eval results on the current and replacement models, the list of affected features and customers (counts only), and any contractual notice terms.

Our product [name] must move from [current model] to [replacement] by [date].

1. Propose a launch tier for the change and justify it.
2. Summarize the eval results as a "Model and behavior changes" release notes entry: what improved, what regressed and what we're doing about regressions.
3. Draft a notice to customer admins: what changes, when, what they should test, whether they can stay on the current model for a period and how to report problems.
4. Propose the metrics to read before and after the switch, and the threshold that would trigger a rollback or a pause.
5. Build a timeline from today to the retirement date, leaving time for customers to test.

Describe only improvements supported by the evaluation results.

Check the output: compare every claim in the release notes and notice with the eval results. Confirm the timeline leaves customers enough time before the provider's retirement date.

Goal: Hear what customers are saying in the first week, with evidence.
Paste in (or connect the harness to): support tickets with the launch tag, community and forum threads, sales call notes and in-product feedback for [date range]. Use an approved tool for customer data.

Summarize the first week of feedback on [launch].

1. Cluster the issues and questions. For each cluster give the count, two representative quotes with source links and the personas affected.
2. Separate confusion (docs or FAQ gaps), defects, pricing or packaging questions and, for AI features, complaints about behavior (tone, accuracy, overconfidence, wrong actions).
3. List questions customers asked that the customer FAQ doesn't answer.
4. Flag any signal that might mean a quality regression, even if only a few customers raised it.

Preserve distinct issue clusters and keep single-source issues visible.

Check the output: read the source for each behavior complaint and possible regression yourself. Update the FAQ and docs the same day.

Goal: Compare what you predicted with what happened, blamelessly.
Paste in: the launch plan (metrics, baselines and predictions), the go/no-go record, the analytics report for the period, the launch-week signal summaries and the decision log entries.

Draft a [30 or 90]-day post-launch review for [launch].

1. Fill a prediction-against-actual table for every metric in the launch plan, with the source for each actual.
2. Describe what happened as a timeline, including stage changes, incidents and rollbacks.
3. List possible reasons each metric differed from prediction, labeled "evidence" or "hypothesis."
4. Assess whether each go/no-go condition was met on time.
5. Propose changes, sorted into product changes and launch-process changes.

Use a blameless account of systems and decisions. Mark metrics with missing evidence "No data."

Check the output: you write the "why it differed" conclusions. Check that reach metrics haven't been presented as success.

Anti-patterns

Checklist

• The launch has a tier, proposed in writing against the tier criteria and confirmed by the launch council.
• Stage labels (design partners, early access, limited availability, general availability) are defined, published and matched to the terms customers sign.
• The launch plan names the stage plan, flags, kill switch owner, success metrics with baselines and the communications timeline.
• For AI features, the launch plan sets an autonomy ceiling per stage, and each customer’s admin opts in at or below it.
• The readiness checklist covers product, engineering, docs, support, sales, legal, billing, security and marketing, each with an owner, a definition of ready and evidence.
• Marketing’s announcement plan has been given to engineering as a capacity input.
• The go/no-go is held early enough to allow a conditional go, and the decision, conditions and risk acceptances are in the decision log.
• For AI features, a named behavior reviewer has a formal line in the go/no-go.
• The PR/FAQ gap analysis is done, and every difference is explained in the internal FAQ.
• The press release, blog post, customer FAQ, internal FAQ and release notes agree on stage, dates, price and claims, and legal has reviewed the claims.
• AI disclosure is reviewed by product and legal, and the customer FAQ says what is labeled as AI-generated.
• Tier 1 AI launches ship a transparency note.
• Production quality evals keep running after launch, and model changes are treated as launches.
• Post-launch reviews are scheduled, compare predicted with actual, and produce changes to the product and the launch process.