For the first two years of our product, writing release notes was a chore I actively dreaded. My process was elite in its laziness: paste the last two weeks of git commits into a Notion doc, delete the obvious junk like dependency bumps, lightly reword whatever was left, and email it to our list. The open rate was 8 percent. In two years I received exactly zero replies. I concluded, reasonably, that customers do not read release notes and I should spend as little time as possible on them.
I was wrong, and a designer friend told me so over coffee. She looked at one of our emails and said, kindly, 'this reads like your internal Jira board.' She was right. A bullet that said 'Reduced database query time on the reports page by 35%' is not for customers. It is for engineers. A customer reading that has to do a translation in their head, and most people will not bother. They will close the tab.
The reframe that changed the numbers
I started running the commit list through the Rewrite a Technical Changelog into Release Notes Customers Actually Read prompt. The key input is the audience tone, which I set to 'friendly and warm for small-business owners who are not technical.' I went with Gemini 2.5 Pro because our changelogs are long and I wanted the model to synthesize the whole sprint at once and keep the tone consistent across all of it, not drift halfway down the list.
The same database commit came back as: 'Your monthly report now loads in under two seconds, even with a full year of data.' Identical fact. Completely different reading experience. One is a status line from a machine; the other is a small promise to a human about their Tuesday. Every bullet got this treatment. The notes went from a wall of internal vocabulary to a short list of 'here is what is better for you.'
The structure helped as much as the wording. The prompt splits everything into What's New, Improvements, and Bug Fixes, and it ruthlessly drops the commits users do not care about. My old hand-edited notes mixed a genuine new feature with a dependency bump with a CI tweak, all in one undifferentiated list, so even the good stuff got buried. Now a customer can scan three clean sections in fifteen seconds and find the one thing relevant to them. I had been blaming low open rates on apathy when the real culprit was that I was asking busy people to dig their own gold out of my mine tailings.
- Email open rate climbed from 8 percent to 31 percent over three releases. Some of that is better copy, some is that I now send on Tuesday mornings, but the copy was the big lever.
- We got our first-ever reply to a release notes email: a customer thanking us, by name, for the faster reports.
- One customer read a bug fix in our notes, realized we were actively improving an area they cared about, and emailed to request a related feature. The notes became a conversation starter.
- The whole task dropped from about an hour to roughly fifteen minutes, because I review rather than write.
The audit table is the secret weapon
My favorite part is a feature I almost cut from the prompt: an audit table that pairs each original commit with its rewritten bullet. This matters because a benefit-led rewrite can quietly overpromise. The model once turned 'added retry logic to webhook delivery' into 'Webhooks now never fail,' which is a lawsuit waiting to happen. The audit table caught it in two seconds. I changed it to 'Webhooks now retry automatically if a delivery is interrupted,' which is both true and reassuring.
I also rely on the [CONFIRM] tags. When a commit is cryptic, the prompt makes its best user-positive guess and flags it for me. About one in ten bullets has a [CONFIRM], and maybe half the time I would have shipped something subtly wrong without it. That little guardrail is the difference between a fast tool and a reckless one.
One more thing I changed once the notes got good: I started sending them. That sounds obvious, but when your notes are embarrassing you quietly avoid drawing attention to them. Once each release read like a small gift instead of a database dump, I added them to our in-app changelog widget, our monthly email, and a short Slack-style post for customers in our community. The same fifteen minutes of work now reaches three surfaces instead of one, because I am no longer ashamed of the output. Quality did not just raise the open rate; it raised how often I bothered to publish at all.
Release notes turned out to be a relationship, not a chore. If yours read like a git log, grab the Rewrite a Technical Changelog into Release Notes Customers Actually Read prompt on Prompt Dock and run it on your next sprint's commits. When a release has a genuinely big feature, I write its launch announcement with the same benefit framing and link back, so the notes and the announcement finally tell one consistent story.