Most launches under-perform because they were written once for one channel and copy-pasted everywhere. These 15 prompts take one feature brief and produce channel-tuned variants: in-app banner (8 words), push (15 words), email (200 words), social (X / LinkedIn / Reddit each different), changelog, blog, and press-friendly blurb. Each variant retains the same core promise but obeys the channel’s attention budget and tone.
Who this is for
PMMs orchestrating multi-channel launches, founders shipping their own announcements, growth teams running lifecycle campaigns, and content designers writing in-product messaging.
When not to use these prompts
Skip for tiny bug-fix releases — those go in changelog only. Skip too for stealth features where premature announcement could hurt the launch.
Prompt anatomy / structure formula
A launch-announcement prompt should always carry six elements:
- Role: who the AI plays (senior PM / solo founder / product designer / indie dev / growth lead).
- Context: stage (idea / MVP / growth / scale), team size, traffic or ARR, platform (web / iOS / Android), audience, constraints.
- Goal: one concrete deliverable — one PRD section, one user-story set, one experiment design, one launch post.
- Constraints: timeline (this sprint / this quarter), scope cuts, must-not-break (existing flows, billing, compliance).
- Output format: table, checklist, ticket-ready JSON, or labeled blocks you can paste straight into Linear / Notion / Jira.
- Examples / signal: 1-2 reference docs or competitors you like, plus 1 anti-example you want to avoid.
Best for
- Multi-channel feature launch
- Beta-to-GA announcement
- Major version (v2.0) launch
- Integration / partnership launch
- Sunset / replacement announcement
15 copy-ready prompt templates
1. Source-of-truth feature brief
Start here. Every channel variant pulls from this single brief.
You are a product marketer. Generate a feature launch brief that becomes the source for all channel variants. Sections: (1) one-sentence promise, (2) who it is for, (3) what they could not do before, (4) what they can do now, (5) one specific example, (6) availability (date / tier / regions), (7) 3 banned words for this launch. Total 200 words.
Feature: {paste internal spec}Variables to swap: feature spec
Optimization: If the brief sounds generic, add: “Every section must contain one concrete fact a competitor could not write — feature name, number, customer name, or specific workflow.”
2. In-app banner copy (less than 8 words)
From this brief, write an in-app banner headline for {feature}. Less than 8 words. Action-led. No exclamation. Plus the matching 12-word subhead and a 2-word CTA. Output 3 variants for A/B testing.
Brief: {paste}3. Push notification
From the brief, write a push notification for {feature}: title (less than 30 chars), body (less than 90 chars), deep link target. Make it feel earned, not spammy. Mark which user segment should receive it.
Brief: {paste}4. Email announcement
From the brief, write an email: (1) subject line (less than 50 chars), (2) preview text (less than 90 chars), (3) body (under 200 words) with: 1 sentence problem, 1 sentence solution, 3 bullets of what is new, 1 CTA button, 1 footer with link to changelog. Plus 2 alternative subject lines for A/B testing.
Brief: {paste}5. X / Twitter announcement thread
From the brief, write a 5-tweet thread launching {feature}. Tweet 1: hook (less than 200 chars, no link). Tweets 2-4: each one specific value (with one image suggestion). Tweet 5: where to start + CTA. Voice: builder-to-builder, not corporate.
Brief: {paste}6. LinkedIn announcement post
From the brief, write a LinkedIn post (1200-1500 chars) for the founder: lead with the problem story, show 3 specific outcomes for customers, include 1 customer quote (mark as TBD if not available), close with the CTA. Voice: confident, slightly reflective.
Brief: {paste}7. Reddit / community post
From the brief, write a Reddit post for {subreddit}. Voice: peer, not vendor. Acknowledge what the community has asked for, share what is new in plain terms, ask for feedback honestly, include known limitations. Less than 350 words.
Brief: {paste}8. Changelog entry
From the brief, write a changelog entry. Format: H2 title (action verb + outcome), 60-word summary, 3-bullet "what changed" list with screenshots or GIF placeholder, 1-line "what is next" note. Voice: precise, useful for power users.
Brief: {paste}9. Blog post (long-form)
From the brief, write a 600-800 word blog post: (1) why we built this (problem context), (2) what we learned in beta, (3) how it works (with one screenshot suggestion), (4) what is next, (5) thanks to specific early users. Voice: builder team, not press release.
Brief: {paste}10. Press-friendly blurb
From the brief, write a press-friendly 80-word blurb for journalists: lead paragraph (what + why now), one quotable line from the founder, availability detail, contact link. Avoid hype language. Should read like AP-style copy.
Brief: {paste}11. Sales enablement one-pager
From the brief, write a sales one-pager: (1) value statement (2 sentences), (2) 3 customer pain points it solves, (3) 3 talking points vs competitors, (4) discovery questions sales should ask, (5) common objections + answers. Format: tight, scannable.
Brief: {paste}12. Customer-success expansion email
From the brief, write an expansion email to existing customers in {segment} who do not yet use {related feature}. Frame the new feature as the missing piece. Less than 180 words. Include one personalized variable (last-used feature, role).
Brief: {paste}13. Sunset / replacement announcement
We are replacing {old feature} with {new feature}. Write announcements for: (1) email to affected users (200 words, with migration steps), (2) in-product banner (less than 25 words), (3) changelog (with timeline of deprecation). Voice: clear, takes responsibility for the transition.
Context: {paste}14. Channel-voice audit
Below are draft variants for the same launch across 6 channels. Audit voice consistency vs channel appropriateness: (1) same promise on every channel, (2) tone shifts appropriately (formal email vs casual X), (3) no copy-paste artifacts, (4) banned words honored. Score each variant 1-5 and rewrite outliers.
{paste variants}15. Post-launch retro template
Two weeks after launch, write a retro template comparing predicted vs actual outcomes per channel: open rates, click rates, in-product adoption, social engagement, support volume impact. For each gap: 1 sentence hypothesis. End with 3 lessons for the next launch.Common mistakes
- Writing one announcement and pasting it on every surface.
- Leading with “we are excited to announce” — wastes the most-read line.
- Stuffing 4 features in one launch — dilutes adoption.
- Hyperbole in changelog (“revolutionary”) — power users tune out instantly.
- Forgetting the in-app surface — most adoption comes from in-product, not email.
- Skipping the sunset announcement when replacing a feature — quiet removals destroy trust.
- No retro — repeating the same launch playbook without learning.
How to push results further
- Always write the source brief first; every channel variant derives from it.
- Each channel has a different attention budget — never reuse subject lines as banner copy.
- Match voice to channel; LinkedIn formal, X informal, Reddit peer.
- In-app and email together drive most adoption; never skip either.
- Always include known limitations in community posts — honesty earns goodwill.
- Time channels: in-app + email on launch day, social over 48 hours, blog within a week.
- Run a retro within 2 weeks; without it, lessons evaporate.
FAQ
- How many channels should I use per launch?: For a major feature: all six (in-app, email, social, changelog, blog, press). For minor: in-app and changelog. Do not over-launch small things.
- Should the same headline run on every channel?: Same promise, different wording. Email subject lines and in-app banners have different optimal lengths and tones.
- How early should I announce?: Teaser 1-3 days before for major launches, instant for minor. Avoid month-long pre-launches; users forget.
- Can AI write the founder voice for LinkedIn?: Draft yes, ship no. Founders should always rewrite the LinkedIn version in their own cadence.
- How do I know if the launch worked?: Adoption rate at 14 days, not engagement on the announcement. Open rates lie; usage tells the truth.