Write a Product or Feature Announcement Email

    You are a product marketer writing an announcement. The reader does not care that we shipped something; they care what is now possible or easier for them.

What we launched or changed: {{whats_new}}
The problem it solves, and who had that problem: {{problem_and_who}}
Who should receive this, and who shouldn't: {{audience}}
What someone has to do to use it: {{activation_steps}}
Whether anything changes for existing users whether they like it or not: {{forced_changes}}
What I want them to do: {{desired_action}}

Produce:

**Segment first.** From {{audience}}: who genuinely needs this email. Announcing a feature to everyone, including people it doesn't apply to, is a reliable way to train a list to ignore announcements. Define who gets it, who gets a lighter mention, and who gets nothing. If the feature only serves a subset, say so and send only to them.

**The email.**
- **Subject and first line** stating the outcome, not the feature name. A reader who has never heard of the feature needs to know what it does for them before they know what it's called.
- **The change, in one sentence.** What they can now do that they couldn't before.
- **Why it matters**, tied to {{problem_and_who}} — ideally describing the annoyance they'll recognize as their own.
- **How to use it** — the shortest path from this email to the thing working. One step if possible, and a direct link into the relevant place rather than the homepage.
- **One call to action.** Not three.

Under 150 words. Announcements are skimmed, and length signals that the reader has work to do.

**If anything is changing for them whether they want it or not.** From {{forced_changes}}: this changes the email substantially. Say plainly what's changing, when, what they need to do, and what happens if they do nothing. Lead with it rather than burying it beneath the good news, give real notice, and acknowledge the disruption directly. Users forgive changes; they don't forgive finding out from a broken workflow.

**What to leave out.** The engineering detail, the internal reasoning, the roadmap context, and the paragraph about how excited the team is. Also anything that isn't live yet — announcing before availability produces a wave of frustrated replies.

**Variants.** A short in-app or in-product version, and a one-line version for a changelog or release notes. Different lengths, same claim.

**Follow-up.** What to send in a week to people who received it and never used the feature — usually more effective than the announcement itself, because the second message reaches people at a moment they might actually act. Include the one-question message to send to people who tried it and stopped.