Short answer: Dictate release notes one entry at a time using a three-beat structure: what changed, why it matters to the user, and what they need to do. Speak the explanations, type the version numbers and identifiers, and write each note at merge time rather than on release day.
Look at your project's changelog. Somewhere in it is a line that reads "various bug fixes and performance improvements," and somewhere near it is a line that reads "fixed issue with sync." Neither tells a single reader anything. Both were written at 6pm on a release day by someone who had already solved the hard problem and just wanted to ship.
The standard diagnosis is that engineers do not like writing. That is mostly a myth, and it misses what is actually going on. A release note is a translation task. You start with a diff, which is precise and dense, and you have to produce a sentence for a person who has never seen the diff and does not care about it. Translation is slow. And the output is prose, which means it gets produced at typing speed by people whose entire toolchain is optimised for producing code at typing speed.
An average adult types around 40 words per minute. Speaking runs 130 to 150. For a twenty-entry release, the difference between "bug fixes" and a changelog someone can actually read is maybe six hundred words of plain English. That is fifteen minutes of typing at the end of a long day, or about four minutes of talking.
The two documents people confuse
Before the method, a distinction that fixes half of all bad release notes: a changelog and a release note are not the same artifact, and trying to make one document do both jobs is why so many end up serving neither.
- The changelog is for you and for anyone integrating with you. It is complete, terse, and organised by change. Every merged change appears. Technical vocabulary is correct and expected. Nobody reads it front to back; they search it when something breaks.
- The release note is for users. It is selective, written in their vocabulary rather than yours, and organised by what they will notice. Most merged changes do not appear at all. It answers "should I care about this update?"
Dictation helps with both, but differently. For the changelog it mostly saves time. For the release note it changes the output, because the moment you say a change out loud you naturally describe it the way you would describe it to a person. The stiff, passive, feature-list voice that release notes drift into is largely an artifact of typing. Speech does not produce it.
The three-beat entry
Every entry worth reading has three beats. Most bad entries have one.
- What changed. The observable difference, described from outside the codebase.
- Why it matters. What the user gets, or what problem stops happening.
- What to do. Any action required, or explicitly nothing.
"Fixed issue with sync" is beat one, badly. The dictated version takes about eight seconds to say: "Files edited on two devices at the same time no longer overwrite each other. Previously the last device to reconnect would win and the other version was lost. If you have been keeping manual backups because of this, you can stop."
That is a genuinely useful entry and it cost less effort than the useless one, because saying it is faster than typing the short version. This is the same economics we described in our guide to dictating bug reports: terse output is almost never a discipline problem, it is a cost problem, and when the cost drops the quality rises without anyone deciding to try harder.
Beat three is the one most often skipped and the one support teams care about most. "No action needed" is a complete and valuable sentence. It stops tickets.
Write the note when you merge, not on release day
The single highest-leverage change to your process has nothing to do with tooling. Release notes are terrible because they are written last, in a batch, about work that happened up to three weeks earlier. By then you have lost the context that makes a good note easy, and you are reconstructing it from commit titles.
Instead, dictate the user-facing sentence at the moment the work is done, while the context is still fully loaded. It takes fifteen seconds. Put it in the pull request description, in a dedicated field on the ticket, or in a running file, whichever your team already looks at.
Then release day becomes an editing job rather than a writing job. You have twenty pre-written sentences, and your work is selecting, ordering, and cutting. That is fast and it happens at the exact moment when nobody has energy for slow work.
A practical version of this: when you open a pull request, dictate two things into the description. The first is the reviewer-facing explanation of what you did and what you deliberately did not do. The second is a single sentence marked as the draft release note. If your team writes PR descriptions in GitHub or tracks work in Linear, both of those are ordinary text fields, and dictation types into them exactly like a keyboard does.
Speak the prose, type the identifiers
This is the rule that keeps voice from introducing the one kind of error you cannot catch by proofreading.
A sentence that comes out wrong announces itself. Any reader sees the mangled phrase and either fixes it or asks. An identifier that comes out wrong does not announce anything. If the note says version 2.4.1 and the actual build is 2.4.11, that line reads as completely correct. It will get published, and then someone will spend an afternoon trying to reproduce a fix on a build that does not contain it.
Speak: the description of the change, the user impact, the reason it was made, the workaround for a known issue, the migration explanation, the summary paragraph at the top.
Type: version numbers, build numbers, dates, flag names, environment variable names, API endpoint paths, config keys, PR and issue references, package versions, and any identifier a reader will copy.
The practical rhythm is to dictate the whole sentence with a gap in it, then fill the gap with your hands: "This requires setting the," type ENABLE_NEW_SYNC, "flag to true before upgrading." It feels clumsy for a day, then it disappears into muscle memory. The same boundary applies to merge request descriptions in GitLab and anywhere else technical prose and technical identifiers sit in the same paragraph.
The five surfaces
1. Changelog entries
One dictation per entry. Keep them short and factual, and let yourself be slightly more technical than in the user-facing note. The value of dictating here is throughput: twenty entries in a few minutes rather than a slow grind where entries get progressively shorter as you tire. Watch that last effect in your own changelogs. The entries near the bottom are almost always worse than the ones near the top, and that is fatigue, not importance.
2. The user-facing release note
This is where speaking changes the writing rather than just accelerating it. Before you dictate, ask yourself the question out loud: "if a customer asked what is new in this version, what would I say?" Then answer it and dictate the answer. What comes out is in the user's vocabulary because you were imagining a user, not reading a diff.
Then cut. First drafts from speech are always long. Cutting is fast.
3. The in-app or store "What's New" text
Short, constrained, and read by more people than your changelog will ever have. This is worth several attempts, and dictation makes attempts cheap. Say four different versions of the same two sentences, read them back, and keep the best one. Anyone who writes these by typing generally produces one version and ships it, because producing a second costs as much as the first.
4. Breaking changes and migration notes
The highest-stakes prose in the whole release. A migration note has to explain what broke, why, what the new shape is, and what to do about it, and it will be read by people under time pressure who are already annoyed.
Dictate the explanation and the reasoning at length, then be pedantic about typing every code sample, path, and version boundary by hand. This is also the one place worth having somebody else read the note before publishing. Being clear to the author is not the same as being clear to the reader.
5. Everything around the release
The internal announcement. The email to the customers who reported the bug you just fixed. The support macro update. The status page note. The reply to the person who asks whether the fix landed. These are all prose, they all get written on release day, and they collectively take longer than the changelog itself.
Watch for the special case: when a customer asks a question about a change and you write a long, careful answer, you have just written a better release note than the one you published. Paste it into the doc.
Tracker traps that fragment your notes
Three things reliably go wrong on the first day, and none of them are transcription problems.
- Return submits. In many trackers and chat-style tools, pressing Return posts the comment. If your dictation is set up to add a newline, one release note becomes four separate comments in the thread. Check this behaviour in a throwaway draft before you use it on a real release thread.
- Single-key shortcuts. Issue trackers bind bare letters to actions when no field has focus. If your dictation hotkey is a plain letter, you will eventually assign a label or close an issue by accident. Use an F13 through F19 key, which is unbound by default.
- Selection is not insertion. Dictation types at the cursor, so there has to be a cursor. Having an issue selected in a list is not the same as having focus in its description field. Click into the field first.
One formatting note as well: markdown editors that auto-continue lists will fight you. If the editor already inserted "3." and you dictate "three, fixed the export dialog," you get doubled numbering. Let the editor own the list markers and dictate only the entry text.
Smart Vocabulary, with one caveat
Release notes are dense with proper nouns that no general transcription engine has ever encountered: your product names, your internal service names, your feature codenames, the third-party services you integrate with. Correcting the same six words in every entry is the fastest route to abandoning dictation entirely.
Smart Vocabulary is a personal dictionary with replacement rules, and the right way to build it is empirical. Dictate for two days, note which words you fix repeatedly, and add exactly those. Twenty to thirty entries usually covers a team's whole vocabulary.
The caveat specific to this use case: do not add mixed-case code identifiers as vocabulary entries. Things like getUserSettings or API_BASE_URL should be typed, not spoken, and adding them as replacement rules tends to make ordinary sentences worse by triggering on normal words. Keep vocabulary entries to things you would say out loud in a meeting. Product names, service names, and company names qualify. Function names do not.
International release notes
If you ship to multiple markets, the same release note has to exist in several languages, and it is usually the step that gets dropped when the release runs late.
The iPhone keyboard supports two-way translation across 24 languages while you dictate, which gets you a usable first draft quickly. Two honest caveats. First, a release note is published, customer-facing text and often carries commitments about behaviour, so a machine first draft should be reviewed by someone fluent before it goes out. Second, do not translate the identifiers. Version numbers, flag names, and endpoint paths stay in their original form in every language.
The hotfix case
Some release notes get written from a phone, because the incident happened at nine at night and you are not at your desk. The iPhone keyboard has a built-in mic button and works in any iOS app, so you can dictate the note into whatever your team uses without switching to a separate transcription app first.
Voice Edit is useful in this situation specifically: you can speak a change to text you have already written rather than fighting a phone cursor to fix one word. For a hotfix note, get the sentence out fast, then adjust it, then post it.
One rule for incident notes, though: do not dictate anything you would not want overheard. Incident details, customer names, and internal system state are exactly the sort of thing you should not narrate in a taxi.
Honest limits
- Do not dictate code. Code samples in a migration note should be typed or pasted. Spoken punctuation and symbols are slower and less reliable than your hands for anything with syntax.
- It does not generate the notes from your diff. There is no repository integration. It types what you say at the cursor, which is why it works identically in every tool with no plugin to install and nothing for IT to approve.
- It does not format. Headings, bullets, links, and code blocks are keyboard work.
- It needs a connection. Transcription runs in the cloud, so an air-gapped build machine is out of scope.
- It is audible. Talking through a release in a shared room is a real constraint, especially for anything security-related.
On privacy, since pre-release work is usually confidential: our servers store only operational pings. No audio and no transcript content is retained, and your history stays on your device. If you work under an NDA or a compliance regime, read our policy directly and check it against your own obligations rather than trusting a summary.
Frequently asked questions
Does this work with conventional commits or an automated changelog?
Yes, and they solve different halves of the problem. Automation is good at assembling the list of what changed. It cannot produce the second beat, the user impact, because that information exists only in your head. Dictate the human sentence into the commit body or PR description and let your tooling collect it.
How long should a release note entry be?
One to three sentences for most changes, longer for breaking changes and migrations. The test is not length, it is whether a user could decide from the entry alone whether the update affects them. "Bug fixes" fails that test at any length.
Will dictated notes sound too casual?
They will sound conversational in the first draft, which is usually an improvement on the passive voice most release notes default to. Cut the filler in the edit pass and keep the directness. If your product has a formal register, adjust in editing rather than trying to speak formally, which slows you down and makes the writing stiffer.
Can I dictate into the terminal for commit messages?
You can, and the same rule applies: speak the body of the message, type the identifiers and any code. Our post on voice typing in the terminal covers the specifics.
What if I ship every day?
Then the merge-time habit matters even more, because there is no release day on which to catch up. Fifteen seconds per merged change, spoken while the context is loaded, is the entire process.
Try it on the next release
Take the changelog from your last release and read the bottom five entries. If they are noticeably worse than the top five, you have a fatigue problem, and fatigue problems respond to making the work cheaper rather than to resolving to do better.
For the next release, dictate one sentence per change at merge time using the three beats, and type every version number by hand. Voice Keyboard Pro has a free tier with daily limits, and Pro is $4.99 a month or $34.99 a year. Compare the two changelogs side by side at the end of the cycle. The difference will not be that you tried harder.