Which product changes deserve a customer email?

Name the affected audience precisely

“All users” is often a placeholder for an audience decision that has not been made. A new billing export might matter to workspace admins who reconcile invoices. A keyboard shortcut might matter to frequent editors. Neither group is necessarily your full mailing list.

Write one sentence identifying the affected group, using information you actually have. If you cannot reliably identify who uses a feature, do not invent a segment. You can publish a discoverable changelog entry, explain applicability clearly, or ask the team how to identify the audience.

Separate an available benefit from a required action

A required migration and an optional improvement need different treatment. For a required action, explain what the recipient must do, by when, and how to get help. For an optional improvement, show the situation in which trying it is useful.

Do not manufacture urgency for the optional case. “You can now export only the rows you selected” may be enough. If there is no clear action and only a small visible improvement, a changelog entry or a grouped digest may serve the reader better.

The amount of engineering effort is not a reliable measure of announcement value. A large refactor may leave customer behaviour unchanged. A small permission change may block someone’s workflow unless they know about it.

Ask what happens if the reader misses it

Imagine the reader does not see the announcement. Will something stop working? Will they miss a useful capability the team already knows they need? Or will they discover a small interface improvement the next time they use the product?

For a change with a deadline, email can be one part of a wider communication plan: documentation, an in-product notice and direct follow-up with affected accounts may also be appropriate. This editorial checklist does not replace incident response or contractual notification procedures.

• Action required: prepare a targeted notice with the verified deadline and migration steps.
• Useful new workflow: consider an email to the people who can benefit from it.
• Small discoverable improvement: record it in a changelog or a relevant digest.
• Internal maintenance with no customer impact: keep an internal record.

Group by the reader’s job

A digest can reduce interruptions, but only if the grouped changes form a useful story. Three improvements to preparing an invoice belong together more naturally than three unrelated PRs merged on Tuesday.

Lead with the shared job, then include only the details that help the reader use it. Link to the complete release record for people who need depth. Avoid making readers scan an engineering inventory to find their own benefit.

Record the decision with the draft

Keep a short note beside the proposed announcement: audience, reason for sending now, next action, and supporting source. That gives a reviewer something more concrete to assess than whether the copy sounds enthusiastic.

In Mergelay, an Update can bring together meaningful Changes and channel drafts. Use the review step to check the communication decision as well as the wording. A draft existing is not, by itself, a reason to publish it.

After sending, look for evidence tied to the intended action: replies about the change, migration progress or use of the relevant feature where you can measure it. Treat a delivery status or an open count as a limited signal, not proof that the announcement helped.