Write a small release note worth reading
Explain a product change through the problem it solves, its actual behaviour and its limits.
Lead with the changed behavior
“We’ve improved the experience” is difficult to evaluate. A useful release note tells a person what was awkward before and what they can do now. It should be specific enough that someone could recognize the change in the product. The size of the note should match the size of the improvement.
This is especially valuable for small tools, where a modest improvement can be described clearly without a promotional announcement. A file-import fallback or clearer save confirmation may deserve a paragraph, not a launch campaign.
Use a four-part structure
Describe the previous problem, the new behavior, how it was checked and a remaining limit. For the existing workbook’s saved-text fallback, a factual note can say that people can paste a compatible JSON export and restore its values when file selection is unavailable. It should also state that this is a manual restore path and entries are not automatically saved.
Avoid inventing the motivation. Unless users actually reported the problem, do not call it “our most requested feature.” Say what prompted the work: an observed internal test, a design review or a real report with permission to mention it.
Make verification proportional
A release note does not need to contain every implementation detail. It does need to avoid claiming more than the checks establish. If a change was exercised in one desktop browser, do not summarize that as “works everywhere.” If a malformed import preserved the current entries in a test, describe that behavior without turning it into a universal reliability guarantee.
Separate proposed improvements from shipped ones. An unsaved-change indicator may be a useful next step, but it should not appear in a list of available features until it exists and has been checked.
Help the next person find the change
Use a title that names the task, such as “Restore workbook progress from saved text.” Link to the relevant instructions rather than the general home page when possible. Include a date and the version or edition if those identifiers are actually maintained.
The finished note should answer a practical question: does this change matter to my work, and how do I use it? That is enough. Honest scope and a clear example usually communicate more value than a series of unsupported adjectives.