QuQi
EMAIL

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

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