Marketing & GrowthFree
Feature Announcement Email and Changelog Kit
The in-app notice, the email, the changelog entry and the social post, written together so all four make the same claim.
River reads the release and types every change in it: added, changed, deprecated, removed, fixed. Then it writes the four surfaces from that typing rather than from how the release feels. The bulk import earns an email. The alert rule change earns an in-app notice on the screen it changed. The bug fixes earn a changelog line. The deprecation earns the only message in the set with a deadline in it, which is the one nobody drafts.
Four surfaces usually means four authors and four different sizes of claim. The social post says the forecasting is now intelligent, the changelog says the threshold moved, and a customer who reads both trusts neither. So every draft comes back with a consistency check: the claim each surface makes, set against what the release actually contains, and the surface that overclaimed named. Then the segment table, because the in-app notice and the email do not go to the same people.
Product marketers inheriting a release two days before it ships get the whole set in one pass. So do founders who are the entire launch function, and product managers whose changelog is the only thing customers read. Start from a release summary assembled from the commit history, route the send through the lifecycle email program, then read what it did in your consolidated campaign reporting. The marketing workspace keeps every release and its four drafts beside the last one.
How big the announcement is, decided by the release
Changelog convention already sorts changes into the categories an announcement needs. The Keep a Changelog format names six: added, changed, deprecated, removed, fixed and security. Each one implies a different surface. Added is the only type that reliably earns a broadcast. Fixed belongs in the changelog and nowhere else. The format is explicit about which matter most, advising that if you do nothing else, list deprecations, removals and breaking changes, because a user upgrading should find it painfully clear when something will break.
Semantic versioning turns that into a date. A minor version must be incremented if any public API functionality is marked deprecated, so the release number itself records that one happened. The specification then sets the notice period: at least one minor release carrying the deprecation before the major release that removes it, so users can transition. That is the announcement window, defined by the release process rather than by a marketing calendar, and it is the one that arrives late or never.
The email is the one surface with a legal shape, and the upgrade line changes it. A notice about a change in the features of a subscription the recipient already pays for is relationship content under the CAN-SPAM rule. Add a line selling the plan it sits on and the message carries both. The primary purpose test then decides whether it counts as commercial. Two things settle it: the subject line as a recipient would read it, and whether the notice comes at the beginning of the body.
How it works
Paste the release
Release notes, the ticket, the spec or the pull request titles. Whatever describes what changed.
River types the changes
Each change sorted by kind, then sized, so the announcement matches what actually shipped.
Read the four drafts
All four surfaces side by side, with the consistency check and the segment for each.
Ship them together
Publish the changelog, queue the email, set the in-app notice, and diary the removal date.
What you get
- Every change in the release typed, with the surfaces that type of change earns
- The in-app notice, email, changelog entry and social post, drafted from the same facts
- A consistency check naming the surface that claimed more than the release contains
- The deprecation notice written with its removal date and the accounts still affected
- A segment per surface, so the notice reaches the plan the change is on
- The email checked against the rule that decides whether it needs an opt-out
Common questions
What if we do not keep a changelog?
The typing still works, because it comes from the release rather than from a file. You get the entry written in the standard format alongside the other three surfaces, which is usually how a changelog starts existing. Added, changed, deprecated, removed, fixed, security. Six headings, no ceremony.
Our release is genuinely big. Does it downsize everything?
It sizes to the release, in both directions. A major version that removes an endpoint sixty accounts depend on gets more surfaces and more notice than most launches. Once six teams are involved and there is a go/no-go, the product launch pack coordinates it instead.
Can the announcement email include an upgrade prompt?
Yes, and the draft tells you what that costs. A notice about a change to features on a plan somebody already pays for is a relationship message. Adding a sell brings the primary purpose test into play, which means the opt-out, the postal address, and honouring marketing unsubscribes. Two emails usually beats one.
Who writes the in-app notice, and where does it go?
It comes back attached to the surface it belongs on, which for a changed behaviour is the screen that changed rather than a global banner. The copy fits a tooltip and it names the old behaviour, because a user who learned the previous rule needs to know it moved.
How is this different from a feature announcement email template?
A template gives you one surface and a shape to fill. This produces the four that have to agree, checks them against each other, and names the one that claimed more than the release contains. The overclaim is the actual failure, and a single-surface template cannot see it.
Does it handle the deprecation notice separately?
It writes that one first, because it is the only message in most releases with a date attached and the only one where silence has a cost. It goes to the accounts still using the thing, names the removal version, and gives the replacement. Collateral still listing the removed integration is a separate sweep, ranked in the collateral audit.
Feature Announcement Email and Changelog Kit
Fill in the form and your workspace opens with the work already underway.