Product launch announcement email

Use when you are launching something and the draft keeps turning into a feature list.

product-launch-announcement.md

Download .md

You are a product marketing copywriter. Write a launch announcement email.

Product: {{PRODUCT_NAME}}
What it does, in plain terms: {{WHAT_IT_DOES}}
Who it is for and who it is not for: {{AUDIENCE_AND_NON_AUDIENCE}}
What people had to do before it existed: {{OLD_WAY}}
Price and availability: {{PRICE_AND_AVAILABILITY}}
Proof I can cite, such as beta results or named users: {{PROOF}}

Output: subject, preheader, body of 150-250 words, one primary call to action, and one secondary link for people who want detail.

Structure:
1. What is now possible that was not before, in the first two sentences.
2. The old way and its cost, briefly.
3. What it does, in three plain statements. Not a feature list.
4. Who it is for, and one honest sentence about who should skip it.
5. Price, availability and the call to action.

Rules:
- No launch cliches: "thrilled to announce", "excited to share", "introducing the future of".
- No em dashes. No "it is not just a tool, it is a workflow" constructions. No closing paragraph restating the opening.
- Do not invent benchmarks, adoption numbers or quotes. Write {{NEEDS_FACT}} where one is needed.
- Keep the who-should-skip sentence in. Do not soften it into a benefit.

Fill in before running

Replace each placeholder with your own detail. The more specific you are, the less the model invents.

{{PRODUCT_NAME}}
{{WHAT_IT_DOES}}
{{AUDIENCE_AND_NON_AUDIENCE}}
{{OLD_WAY}}
{{PRICE_AND_AVAILABILITY}}
{{PROOF}}
{{NEEDS_FACT}}

Getting a better result

The "who should skip it" line raises trust and cuts refund and churn traffic from bad-fit buyers.
Lead with the new capability, not with the fact that you built something.
If you have no proof yet, say the product is new rather than letting the model invent traction.

Questions about this prompt

When is a launch email the right shape rather than a general update?

When there is a single new capability and a decision you want the reader to make. If you are bundling three unrelated changes, a release note serves better. The structure here spends its first two sentences on what is now possible, and that needs one thing to point at.

Which inputs decide whether the announcement works?

What it does in plain terms, who it is for and who it is not for, what people had to do before, price and availability, and any proof you can genuinely cite. The non-audience is the input people skip, and it is what feeds the honest sentence about who should skip this.

What does the announcement come back as?

Subject, preheader, a 150 to 250 word body following the five-part structure, one primary call to action and one secondary link for people who want detail. The who-should-skip line is the part to defend in review, because it cuts refund and support traffic from buyers who never fitted.

What gets edited out that should stay?

The who-should-skip sentence, softened into a benefit at sign-off. It is the change everyone requests and it removes the reason the line existed. The second failure is letting unsourced proof through: any {{NEEDS_FACT}} left in the draft is a number you have to find or a claim you have to cut.