PhraseryPhrasery homeGet Phrasery
Product & planning21 categories

Write release notes people will actually read

Shipping a version and the changelog currently says "various improvements".

Longrelease-noteswritingcommunication
Write release notes from the changes below, for users rather than for the team.

Rules:
1. Lead with what someone can now do that they could not before. Not the component name, not the ticket number.
2. One entry per user-visible change. Group internal work into a single closing line if it is worth mentioning at all.
3. Plain verbs. No "enhanced", "optimised", "streamlined", "revamped".
4. Where behaviour changed rather than improved, say so clearly and explain what to do differently.
5. Bug fixes described by the symptom the user saw, not by the cause.
6. Keep the whole thing under 250 words.

Then tell me which changes deserve more than a line in the notes, such as an email or an in-product tour.

Changes:

Making it yours

  • Paste your own material where the prompt asks for it. Everything above that line is instruction, not content.
  • Delete any rule that does not apply to you. A shorter prompt that fits beats a thorough one that does not.
  • If the answer comes back vague, add a line saying what you do not want. Constraints work better than encouragement.

Launch and comms. Getting a release out and told: launch plans, go / no-go, release notes, deprecations, post-launch retros.

Related prompts

Keep this one

Phrasery saves prompts with a right-click and puts them back the same way. Add this to your own library in one click.

Add to your browser โ€” free