Feature release note for existing customers

Use when you ship an update and need to tell current users what changed and what they must do.

feature-release-note-email.md

Download .md

You are a product communications writer. Write a release note email for existing customers.

Product: {{PRODUCT_NAME}}
What changed: {{CHANGES}}
Who is affected and who is not: {{AFFECTED_USERS}}
Any action the customer must take, and by when: {{REQUIRED_ACTION_AND_DATE}}
Anything removed, renamed or now behaving differently: {{BREAKING_CHANGES}}
Where the documentation lives: {{DOCS_LINK}}

Output in this order:
1. Subject and preheader that state the change, not the excitement.
2. A one sentence summary a busy customer can read in the preview pane.
3. "What you need to do" section. If nothing, say "nothing" in those words.
4. "What changed" as a short list, each item written as before and after.
5. "What was removed or renamed", with the migration path for each.
6. Where to get help.

Rules:
- Breaking changes go above nice-to-haves, always.
- Dates must be absolute, such as 12 March 2026, not "next week".
- Do not describe a change as an improvement if it removes something a customer relied on. Say what was removed.
- No em dashes, no marketing adjectives, no apology padding, no closing summary.
- If a change description I gave you is ambiguous, list it under "needs clarification" rather than guessing.

Fill in before running

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

{{PRODUCT_NAME}}
{{CHANGES}}
{{AFFECTED_USERS}}
{{REQUIRED_ACTION_AND_DATE}}
{{BREAKING_CHANGES}}
{{DOCS_LINK}}

Getting a better result

Put required actions above the feature news. Support volume comes from people who missed the action.
Before and after phrasing is faster to read than a description of the new behavior alone.
Absolute dates only. Relative dates break when someone reads the email a week later.

Questions about this prompt

When do I use this rather than the launch announcement prompt?

When the audience is existing customers and something they rely on has changed. A launch email sells a decision; a release note tells people what to do. If there is a required action or anything removed or renamed, this shape is right even when marketing would rather announce it.

What do I need to supply about the change?

Who is and is not affected, any required action with a date, everything removed, renamed or now behaving differently, and the docs link. Ambiguity in your change list comes back as a "needs clarification" item rather than a guess, so vague inputs return questions instead of copy.

What order does the release note come back in?

Subject and preheader stating the change rather than the excitement, a one sentence summary for the preview pane, a "what you need to do" section, changes written as before and after, removals with migration paths, and where to get help. The action section decides your support volume.

What is the mistake in a release note?

Putting the new feature above the required action because it reads better. Everyone who misses the action becomes a ticket. The other is relative dates: "next week" is wrong for anyone reading on Monday, which is why the prompt insists on absolute dates such as 12 March 2026.