These 14 product launch prompts take a launch from sizing and planning through risk checks, a go or no-go decision, the announcement, team preparation and a review two weeks later. Each one asks for your real facts and dates, and tells the model to flag gaps instead of filling them with confident guesses.
How to use these prompts
Each prompt works in ChatGPT, Claude or Gemini. Replace the blanks in double braces, or keep the default after the colon: {{launch_date:3 March}} means 3 March unless you change it.
Write one launch brief first: what is shipping, who it is for, the problem it solves, what it doesn't do yet, pricing if any, the date and the owners. Paste that brief into every prompt. When every announcement, FAQ and sales note comes from the same facts, they stop contradicting each other.
For the PRD, user stories and release notes, see the product manager prompts. For ad copy and social posts, see the marketing prompts.
Which prompts plan the launch?
1. Size the launch
Not every release deserves a press push. Deciding the tier first saves effort and attention.
Here is what we're shipping:
{{launch_brief}}
Classify this launch into one of three tiers:
Tier 1: major launch, all channels, press and customer outreach.
Tier 2: notable feature, email, blog, in-app and social.
Tier 3: small improvement, changelog and in-app note only.
Explain the choice against: how many customers it affects, whether it
changes pricing or workflows, competitive importance, and risk. List the
activities that match the tier and the ones we should skip.
2. Timeline working back from the date
Turns a date into a list of tasks with owners and deadlines.
We launch {{product:the new reporting dashboard}} on {{launch_date:3 March}}.
Launch tier: {{tier:2}}
Team and roles: {{team}}
Fixed dependencies: {{dependencies:legal review takes 5 working days, app store review}}
Work backwards from the launch date and produce a table: task, owner role,
start date, due date, depends on. Include product readiness, docs, support
training, announcement drafts and approvals, and a post-launch review.
Flag any task with no obvious owner and any week where one person has too
much.
3. Readiness checklist
Google's SRE book chapter Reliable Product Launches at Scale describes a "launch checklist" of common questions to ask about a launch and says: "The checklist proved to be a useful tool for ensuring reproducibly reliable launches." This prompt builds a lighter version for your launch.
Write a launch readiness checklist for:
{{launch_brief}}
Group the questions by area: product and quality, monitoring and alerts,
capacity, rollback, security and privacy, docs, support, sales, legal and
compliance, announcement. Phrase each item as a yes or no question with an
owner role. Mark the items that must be "yes" before launch and the ones
that can follow within a week. Only include items relevant to this launch.
Which prompts reduce launch risk?
4. Launch pre-mortem
Imagine it went badly, then work out why while there is still time.
It is two weeks after the launch of {{product:the new reporting dashboard}}
and it went badly. Here is the launch brief and plan:
{{launch_brief}}
List the 10 most plausible reasons it failed, across product, technical,
market, messaging and team causes. For each: likelihood (low, medium,
high), impact, an early warning sign we could watch for, and one action we
can take now to prevent it. Rank by likelihood times impact.
5. Staged rollout and rollback plan
The SRE book notes that "Almost all updates to Google's services proceed gradually, according to a defined process, with appropriate verification steps interspersed." You don't need Google's scale to borrow the idea.
Plan a staged rollout for {{product:the new reporting dashboard}}.
How we can release: {{mechanism:feature flag by account}}
Users: {{users:about 4,000 active accounts}}
Propose stages (for example internal, a small percentage, a larger group,
everyone), how long each lasts, and the metrics and thresholds that must
hold before moving on. Write the rollback steps for each stage, who can
trigger a rollback, and how we tell affected customers. Flag anything in
the plan that depends on a capability I haven't said we have.
6. Go or no-go review
A short, honest decision document for the day before.
Here is the status of our launch readiness checklist and open issues:
{{checklist_status}}
{{open_issues}}
Write a go or no-go summary: items that block launch, items that are risky
but acceptable with a mitigation, and items that can wait. For each
blocker, state what would need to be true to launch on time. End with
three options (go, go with reduced scope, delay) and the consequences of
each. Don't make the decision; lay out the facts for the team.
Which prompts write the launch message?
7. Message brief from the facts
One page every writer works from: the announcement, docs, sales and support.
From this launch brief, write a messaging brief:
{{launch_brief}}
Include: a one-sentence description a customer would understand, the
problem it solves in the customer's words (use these quotes: {{customer_quotes}}),
3 key benefits each backed by a specific capability, what it does not do
yet, who it is for and who it isn't for, and words to avoid. Use only facts
from the brief; list any claim you'd want evidence for before we publish.
8. Customer announcement email
Leads with what changes for the reader, not with the company.
Write an email announcing {{product:the new reporting dashboard}} to
{{audience:existing customers on paid plans}}.
Use only this messaging brief:
{{messaging_brief}}
Structure: subject line (3 options under 50 characters), first sentence
says what's new and why it matters to them, how to try it in 3 steps or
fewer, one screenshot placeholder, what's coming next if the brief says,
and a single call to action. Under {{words:180}} words. No hype words like
"revolutionary" or "game-changing".
9. Press release from facts only
Based on the approach in Anthropic's guide to reducing hallucinations, whose own example drafts a press release for a product launch and tells the model to remove any claim it can't back with a direct quote from the documents.
Draft a press release for {{product:the new reporting dashboard}} using only
information from these documents:
{{documents}}
Format: headline, subheadline, dateline {{dateline:London, 3 March 2027}},
opening paragraph with who, what, when and why it matters, two paragraphs
of detail, one quote from {{spokesperson:our CEO}} (mark it "DRAFT QUOTE,
needs approval"), availability and pricing, and a boilerplate placeholder.
After drafting, check each claim. For each, find a direct quote from the
documents that supports it. If you can't, remove the claim and mark where
it was with empty [] brackets.
10. Beta and early access invite
Invites early users and asks for honest feedback, without strings attached to a positive review.
Write an invite to join the early access program for
{{product:the new reporting dashboard}}.
Who we're inviting: {{audience:50 customers who asked for better reporting}}
What they get: {{offer:access 4 weeks early and a call with the product team}}
What we ask: {{ask:a 20-minute feedback call and an honest public review if they want to write one}}
Rules: under 150 words, clear about what early access means (bugs are
likely), how to opt out, and that any review is optional and should be
their honest opinion. Do not tie the offer to leaving a review or to the
review being positive.
Which prompts prepare the team?
11. Support FAQ and reply drafts
Support hears about the launch from customers if nobody tells them first.
From this launch brief, write a support pack:
{{launch_brief}}
Include: 10 questions customers are likely to ask with short, accurate
answers; known limitations and workarounds; how to tell a bug from expected
behavior; when to escalate and to whom ({{escalation:the on-call product engineer}});
and 3 reply templates for the most common questions. Mark any answer that
the brief doesn't fully support with "Confirm:".
12. Sales and success one-pager
What customer-facing teams need on one page.
Write a one-page internal brief for {{teams:sales and customer success}}
about {{product:the new reporting dashboard}}.
Use only this messaging brief:
{{messaging_brief}}
Include: what it is in two sentences, which customers to tell first and
why, a 30-second talk track, the 5 objections we expect with honest
answers, pricing and packaging facts, what not to promise, and where to
send questions. If the brief doesn't cover pricing, say so instead of
guessing.
13. Launch day run sheet
Who does what, hour by hour, on the day.
Write a launch day run sheet for {{product:the new reporting dashboard}} on
{{launch_date:3 March}}, time zone {{timezone:UTC}}.
Team and roles: {{team}}
Planned activities: {{activities:flag rollout, blog post, customer email, social posts, support monitoring}}
Return a table: time, action, owner, done signal. Add checkpoints to review
metrics and support volume, the conditions that trigger a pause or
rollback, the channel where the team coordinates, and who makes the call
if something goes wrong.
Which prompts review the launch?
14. Post-launch review
Two weeks later, compare results with what you planned.
Here are our launch goals, the plan and what happened:
Goals and metrics: {{goals}}
Results so far: {{results}}
Notes from the team: {{notes}}
Customer feedback: {{feedback}}
Write a post-launch review: goals versus results with numbers, what went
well, what went wrong and why, what customers said (quote them), and 5
specific changes for the next launch with an owner each. Keep blame out of
it; describe processes, not people. Mark any conclusion the data doesn't
clearly support.
How do you ask for reviews and testimonials honestly?
Launches create pressure to fill a page with praise fast. The FTC's guide FTC's Endorsement Guides: What People Are Asking sets the basic rule: "Endorsements must reflect the honest opinions or experiences of the endorser." It also says you can't condition an incentive, such as a discount, on a review being positive, and that people with a connection to the company, such as employees, should disclose it.
In August 2024 the FTC also announced a final rule banning fake reviews and testimonials, including AI-generated fake reviews and certain reviews by company insiders that don't clearly and conspicuously disclose their connection. Never ask a model to write reviews or testimonials in a customer's voice. Use it to draft the request, as in prompt 10, and publish only what real customers wrote.
The same rule applies to every claim in the launch: if you can't point to the source, cut it. Prompts 7, 9 and 11 all ask the model to mark unsupported claims, so a reviewer sees the gaps before customers do.
Make your favorite one a skill
If you ship every few weeks, turn the readiness checklist or the support pack prompt into a skill with your tiers, channels and approval steps built in, so Claude, Claude Code or Codex applies them to every launch. Paste it into the free SKILL.md generator. To find out what customers need before you build, start with the customer research prompts.
To keep a launch kit ready for the next release, save these prompts in Kipt with their blanks, tag them by phase (plan, risk, message, team, review) and press Cmd+K to find one. Your library lives as Markdown in a private GitHub repo you own.