Write update announcements that explain what changed for readers

A useful update announcement tells readers what changed, who is affected, and what they should do next. For an author's paid companion, distinguish a correction from a new supported task or a clearer example. Those changes deserve different language and sometimes different levels of urgency.

You are helping someone decide whether to revisit their work. “More powerful,” “improved guidance,” and “lots of updates” leave that decision to guesswork.

An app user, u/reddit76194c, described having to “"discover" them since those aren't listed on the release notes” when discussing improvements and fixes. The context is a phone app, not an author product, but the reader problem transfers: invisible changes are difficult to act on. Read the user's account.

Before drafting an email, complete this sentence: “Because of this change, a reader who ______ should ______.”

If the answer is “nobody needs to do anything,” that may be appropriate. Say so. A clearer example can help future use without invalidating past work. A correction, on the other hand, may require someone to recheck an output.

The Government Digital Service's release-note guidance recommends starting with how a change affects users and giving clear action where needed. Its context is technical services; the communication principle is useful for an author's product too. GDS release-note guidance.

Use these five fields:

The three examples below are original and fictional. They concern Rafael, an author whose method helps people plan short local-history walking tours. His proposed paid companion organizes stops, themes, and a draft running order. It does not verify historical claims, inspect a route, or establish accessibility or safety.

Subject: Recheck transition time in your walking-tour outline

The sample timing worksheet previously counted only the time spent speaking at each stop. It did not include travel between stops. The corrected example now lists speaking time and transition time separately.

If you used that example to estimate a tour's duration, review the transitions in your own outline before using the estimate. Add a separate line for each movement between stops, based on a route you have checked yourself.

The corrected worksheet is labeled “Speaking and transitions.” It includes a worked example showing both parts of the total. Your existing outline has not been reviewed or corrected for you.

This remains a planning aid. It does not verify route conditions, accessibility, safety, or historical accuracy. If you cannot find the corrected example, use the support contact listed with your purchase.

Why this works: The subject names the affected work. The opening identifies the omission without disguising it as an exciting feature. The action tells readers to examine their own transitions. The message also prevents a dangerous inference: changing the example has not repaired every prior outline.

Before sending a real version, add the verified destination for the corrected material and confirm who can access it. Do not describe a fix as available while it is still a draft. If the original mistake has broader consequences than the example suggests, investigate and communicate those consequences too.

Subject: You can now compare two draft tour routes

The companion now includes a route-comparison exercise for choosing between two draft walking-tour outlines.

Bring the purpose of your tour, the intended audience, the proposed stops, and the constraints you already know. The exercise helps you compare how clearly each route supports the theme and where more checking is needed.

You will get a structured comparison and a list of unresolved questions. You will not get a verified route, a safety assessment, or a guarantee about how long the walk will take.

If you are already happy with one outline, no action is needed. If you are deciding between two, open the route-comparison exercise and start with the supplied fictional example before using your own material.

Why this works: The new capability is a recognizable task. Inputs and outputs make it easier to judge relevance. The message does not imply that the companion has gained expertise beyond the author's bounded planning method.

For a real paid skill, make this announcement only after checking the task works as described. Representative task testing should precede claims about what readers can now do. If access differs by purchase or environment, state the applicable details rather than implying universal availability.

Subject: A new example separates a tour theme from a list of stops

The worked example now shows the difference between a theme and an itinerary.

“Market square, bridge, old station” is a list of places. “How trade changed the town's gathering places” is a possible theme connecting them. The example then shows how to identify a stop that does not support the theme.

The method has not changed. If you already have a clear theme and each stop supports it, you do not need to redo your outline.

If choosing a theme has been difficult, read the revised example and write one sentence explaining what your stops help visitors understand. Then check each stop against that sentence. Historical claims still need independent verification.

Why this works: The email teaches a small distinction in its own right. It explains the benefit without pretending the product has acquired a new capability. It also says when no action is needed, which respects readers who have already completed the task.

In a discussion of app update notes, u/Fingerbob73 objected to “the same generic message spans several updates”. The post expresses one user's frustration, not a measurement of how many people read announcements. Still, repeating the same celebratory paragraph makes it difficult for a returning reader to identify the relevant difference. Read the discussion.

Use precise verbs: corrected, added, clarified, removed. Name the example or task. If you removed something, explain the effect and available next step. Do not call a removal an improvement without telling readers what they can no longer do.

The Keep a Changelog project distinguishes a curated account of notable changes from a raw record of implementation activity. Your reader needs the meaningful difference, not your internal work diary. Keep a Changelog.

Keep a dated, findable record of meaningful changes. Send direct notices where readers need to act, and group low-urgency improvements when that suits your communication promise. A correction affecting existing work should not be buried beneath a promotional announcement.

Confirm the actual delivery route before stating how readers receive an update. Publishing revised material, notifying readers, and ensuring that a reader is using the revision are separate steps. If a reader must retrieve or apply something, give the verified instructions. If you do not know, resolve that before announcing availability.

Finally, read the message as someone who has five minutes and an unfinished task. Can they tell whether the update applies to them? Can they act without interpreting marketing language? Do the limits remain clear?

Draft the reader consequence before your next improvement. If you are designing an ongoing paid companion around your book's method, bring one sample task and update promise to Skillfully and choose Book onboarding.