# Writing release notes eats up a product manager's week: fixes for Mac in 2026

> Writing release notes eats up a product manager's week because the facts are scattered. Here is how to collect them early, with fixes that need no purchase.

URL: https://www.lazur.app/for/product-managers/problems/release-notes-eat-up-pm-week
Updated: 2026-11-08

Writing release notes eats up a product manager's week because the facts sit in several tools, and they were written for engineers. The fix is to collect facts as work ships, not in a last-minute scramble before launch. This page covers what the hunt costs, why it happens, and fixes you can use on your Mac today.

## Quick answer

- For most product managers, finding the facts takes longer than writing the note.
- Ticket titles and pull request names describe code, not what a customer sees.
- GitHub can generate a draft from merged pull requests. You still rewrite it for customers.
- App Store Connect allows up to 4,000 characters in What's New. Short and specific wins.
- Collect facts at merge time in one running sheet, then check the draft against the shipped build.

## What gathering info for release notes costs you

- **Your calendar loses time you never see.** Gathering facts splits into many small tasks. Each one is a short search, a question, or a wait. Each one breaks your focus on the work in front of you. Few of these tasks get a calendar slot, so the total is easy to miss. Track your own time across a few releases to see the real number.
- **Engineers and support get pulled in.** Every open question sends a message to an engineer, a designer, or a support lead. They answer when they can. Your draft waits for those answers. When the answers arrive late, release day slips, and the note gets written under pressure.
- **Vague or wrong notes create support tickets.** A line that says Improved performance invites questions about what changed. A line that promises an unfinished feature invites complaints. Support then spends time on questions your note should have answered, and you spend time on corrections.
- **Sales and marketing request extra versions.** Sales wants a sentence for a customer call. Marketing wants a headline for a blog post. Each request is a rewrite, and each rewrite needs another fact check against the ticket. The work multiplies after you think the note is done.
- **A pay reference, not a measure.** The U.S. Bureau of Labor Statistics reports a median annual wage of $102,320 for project management specialists in May 2025. That is a related role, and the figure is not for product managers. Use it only as a rough reference for what coordination work costs in pay terms, not as a measure of your week.

## Why it happens

1. **Facts live in too many places.** Release facts sit in the tracker, the code host, chat, design files, and the support inbox. No single tool holds the full picture. You rebuild that picture for each release, and the rebuild is the slow part of the job.
2. **Tickets describe the work, not the result.** A ticket title tells engineers what to build. It rarely says what a user will notice afterward. Translating from work to result takes a judgment call. Without a written rule, each call is made from scratch.
3. **Notes get written at the end.** Teams gather facts when the launch is close. People are tired, and the details have faded. The note becomes a rescue job instead of a planned output, and rescue jobs run long.
4. **Nobody owns the note.** Engineers assume the product manager writes it. The product manager assumes engineering will add the details. Without a named owner and a deadline, the task falls to whoever notices first, and that is often you.
5. **Generated lists look finished.** A generated list of pull requests looks like a complete changelog, so it is easy to publish as is. The list is complete for engineers and unclear for users. The cleanup then returns later as support questions.
6. **No template to reuse.** Each release starts from a blank page. You decide the format, the tone, and the headings again. The same choices repeat every time, and that repeated effort is wasted time.

## How to fix it

- **Add a customer note field to every ticket.** Use a label, a status, or a custom field your tracker already supports. Ask the person who closes each ticket to write one plain sentence about what a user will see. This needs no new tool. It only needs a short rule the team agrees to follow.
- **Log each change at merge time.** When a change merges, add one line to a running sheet. Use columns for the change, the customer words, the ticket link, and a ready flag. A Google Sheet does this well, and so does a shared Notion database. Your draft is then ready on release day.
- **Keep one running draft with a template.** Put the template at the top of the draft. Use a what's new part, an improvements part, and a fixes part. Keep the last approved note as a sample, so the next release copies the tone and not the mess.
- **Let GitHub draft, then cut hard.** Use the Generate release notes button or gh release create with --generate-notes to get the list. Then remove internal refactors, bot noise, and dependency bumps nobody can feel. Add changelog.exclude settings to .github/release.yml so the cleanup repeats less often.
- **Write what a user can do, not what the code does.** Swap the code verb for a user verb. For example, a line about migrating the settings store becomes a line about what a user sees on the settings page. Ask yourself what changed on the screen, and write that instead.
- **Check the note against the shipped build.** Open the build that will ship, not the staging branch or the plan. Walk through each change in the note. Take a screenshot with ⌘ ⇧ 4 for your own record. If a line describes what the team hoped for, rewrite it or cut it.
- **Dictate the rough draft, then edit.** Hold fn and speak your rough bullets into a document. Dictation types clean text at the cursor in any app. Then edit for accuracy. Speaking often gets a first draft down faster than typing it, so the bullets are on the page before the details fade.
- **Set one approver and one deadline.** Name the person who signs off on customer copy, usually the product lead or the support lead. Put the deadline in the release channel. A named approver turns a week of back-and-forth into one review pass.

Release notes look like a small job. A few bullets, a short paragraph, and you are done. In practice the bullets come last. Most of your time goes to finding out what actually shipped, who it helps, and whether the wording is true. You can write the sentences quickly once the facts are clear.

## Where the time goes when you write release notes

Release facts live in more places than most teams admit. A ticket tells you the owner and status. A pull request tells you what code changed. A Slack thread explains why. A Figma file shows the new screen. Each source answers part of the question, and none of them answers it in customer words.

| Source | What it tells you | What it leaves out |
| --- | --- | --- |
| Ticket tracker, such as Linear or Jira | Owner, status, and priority | What a customer will notice |
| GitHub pull requests | What code merged and when | Plain-English user impact |
| Slack or Teams threads | Why a decision was made | Whether the decision held |
| Figma files | What the new screen was meant to look like | Whether it shipped that way |
| Support inbox | What users keep asking about | Which fix they will see |
| Your memory of meetings | Context from the last planning call | Anything you did not write down |

_Each source answers part of the question. None answers it in customer words._

Take one change. The ticket says Persist filter state on list views. The pull request says the filter moves into local storage. A Slack thread says support logged complaints about lost filters. The Figma file shows a small reset chip. The note you want reads: Your filters now stay selected when you come back to a list. You pieced that line together from several places. This example is invented to show the pattern.

## Why release notes take longer than they should

Work is written for the team that does it. Tickets, commits, and chat use internal words like refactor, flag, and migration. Release notes need customer words like save, find, and sign in. Translating between the two takes a judgment call each time. Judgment is slow when nobody has written the rule down.

Timing makes it worse. Facts get gathered at the end, when the team is tired and the launch date is close. Each missing detail becomes a message to someone who has already moved on to the next sprint. You wait for replies, and the draft waits too.

![Product manager working on a laptop at a desk while reviewing release notes](https://images.lazur.app/content-images/problem/release-notes-eat-up-pm-week/writing-release-notes-eats-up-a-product-1-79fe80.jpg)

## Use GitHub's generated notes as a draft, not the final text

GitHub can generate release notes for a release. The generated text includes a list of merged pull requests, a list of contributors to the release, and a link to a full changelog. That is a useful draft for engineers. It is not customer copy, because it lists code work by title.

To generate notes in the web app, open the release form, pick a tag and an optional previous tag, and enter a title. Click Generate release notes above the description field. Review the output before you publish. Nothing is final until you edit it.

From a terminal with the GitHub CLI installed, run gh release create v2.0.0 --generate-notes. The --notes flag adds your own text above the generated list. Use --notes-file with a dash to read your prepared text from standard input.

> **Hide the noise:** Add a .github/release.yml file to your repository. Use changelog.exclude.labels to keep pull requests with certain labels out of the list. Use changelog.exclude.authors to exclude user or bot handles. Set it once, and every release starts cleaner.

## Writing the App Store What's New field

If you publish an iPhone or Mac app, the What's New in this Version field in App Store Connect is where your notes go. Apple allows up to 4,000 characters. The field is not available for an app's first version. It is required for every version after that, and you can localize it.

- **4,000** characters allowed in the App Store Connect What's New field ([source](https://developer.apple.com/help/app-store-connect/reference/app-information/platform-version-information))

Apple recommends that What's New give users detailed information about the specifics of changes, improvements, or fixes. Vague lines like Bug fixes and performance improvements tell a user nothing. Name the screen, button, or action that changed, and say what the user will notice.

## Edge cases that catch product managers

- Internal refactors with no visible change: leave them out, or point engineers to the full changelog link.
- Security fixes: check with your security or legal owner before you describe them in public text.
- Staged rollouts: say which users see the change first, and do not promise a date you do not control.
- Several platforms: write each note for the platform it ships on, not one blurred version for all.
- Localized text: send translators the final English, not the first draft.
- Customer quotes: use them only with permission, and follow your employer's rules on customer data.

The first version deserves a short note anyway. Apple does not require What's New there, so teams often skip it. Early users still want to know what they are getting. A short note costs little and sets expectations for the next update.

> **Customer data and regulated work:** If your product handles health, legal, or financial records, never name a real customer in a note. Do not paste support tickets that contain personal data into any tool. Follow your employer's rules on client or patient data first, every time.

## Mistakes that make release notes take longer

- Asking for facts on launch day instead of at merge time.
- Copying ticket titles straight into the note.
- Writing for the engineering team instead of the user.
- Promising a date, price, or feature that is not final.
- Skipping the check against the shipped build.
- Scattering drafts across apps, so nobody can find the last approved version.

![Team meeting in an office where release facts get confirmed before publishing](https://images.lazur.app/content-images/problem/release-notes-eat-up-pm-week/writing-release-notes-eats-up-a-product-2-320aa8.jpg)

## Where Lazur helps, and where it does not

Lazur is a voice assistant for the Mac. Hold ⌥ ⌘ to ask about anything on screen, and Lazur answers out loud. Ask where a button is, and Lazur draws a circle and a label around it. Hold fn to dictate clean text at the cursor in any app.

Lazur does not click buttons, edit files, or operate other apps for you. It listens and looks at your screen only while you hold the shortcut. It only knows what you show it or say. Treat its draft as a first pass, and check every claim against the ticket and the build.

## Turn rough bullets into customer language

Dictate your rough bullets with fn into a Notion page or a Slack draft. Then ask Lazur to rewrite them as plain sentences for a customer. Keep the technical bullets beside the draft, so you can check each sentence. If a sentence has no matching ticket, cut it.

![Person typing notes on a laptop, drafting customer-facing text for an update](https://images.lazur.app/content-images/problem/release-notes-eat-up-pm-week/writing-release-notes-eats-up-a-product-3-cb1a06.jpg)

## A checklist before you publish

1. Every line names something a user can see, use, or do.
2. Every claim matches the build you tested, not the plan.
3. Dates and version names match the release tag.
4. The text fits the field, with room to spare.
5. Translated copy was checked by a native reader.
6. Legal or security owners approved any risky wording.

Keep this checklist in your release template, not in your head. The next release will ask the same questions, and the checklist answers them before anyone has to.

## With Lazur

Lazur is a voice assistant for the Mac that lives in the notch. Hold ⌥ ⌘ and ask; it sees your screen, answers out loud, points at buttons and walks you through apps. Hold fn to dictate. Free for 3 days, then $18/month: https://www.lazur.app/download

- “Where is the button that generates release notes?”: Lazur circles the button and labels it. You click it yourself, then read the text before you publish. (Points at it)
- “Where is the button that generates release notes?”: Lazur circles the button and labels it. You click it yourself, then read the text before you publish.
- “What does this ticket change for a customer?”: Lazur reads what is on screen and answers out loud. Check the answer against the ticket before you use it.
- “Hold fn and speak your rough bullets into the note.”: Dictation types clean text at the cursor in any app. You edit the wording afterward.
- “Rewrite these bullets as customer-facing sentences.”: Lazur drafts and types the text. It only knows what you show it, so check every sentence against the source.
- “Walk me through adding a label to this ticket.”: Lazur guides you one click at a time and waits for each click before it gives the next step.
- “Remind me to write the release note on Friday.”: Lazur can set Apple Reminders by voice, so the task shows up when you need it.
- “Look up the changelog pages for the tools in our stack.”: Research runs in Lazur's own Chrome tabs through the Lazur for Chrome extension, then returns a summary and a report.

## A plan you can start this week

- **Week start: Set the rule and the template.** Agree with engineering that each ticket gets a customer sentence. Put the template at the top of a shared doc. Name the approver and the deadline. This takes one meeting and saves the scramble later.
- **Each merge: Log the change in customer words.** When work merges, add a line to the running sheet. Write what a user will see or do. Link the ticket, so you can trace the line back if someone questions it.
- **Midweek: Chase the open questions.** Post the changes that still lack a plain sentence in the release channel. Ask each owner to answer by a fixed day. Late answers cause most of the rework, so ask early.
- **Before release: Generate and trim the draft.** Run GitHub's generated notes from the release form, or use gh release create with --generate-notes. Remove internal work and bot noise. Move what is left into the template, one section at a time.
- **Release day: Check, paste, publish.** Open the build that ships and walk through each line. Paste the final text into the GitHub release or the App Store Connect What's New field. Confirm it fits the field before you save.
- **After release: Save the example for next time.** Keep the sheet and the final text together. Write down which questions took the longest to answer. Add those questions to the template, so the next release needs fewer messages.

## FAQ

### Why does writing release notes take so long for a product manager?

Most of the time goes to finding facts, not writing. The facts sit in tickets, pull requests, chat threads, and design files. Each one needs a question or a check. Writing goes quickly once the facts are clear.

### Can GitHub write my release notes?

GitHub can generate a list of merged pull requests, a list of contributors, and a link to a full changelog. That list is a draft for engineers, not customer copy. You still rewrite it in customer language before you publish.

### How long can App Store What's New text be?

Apple allows up to 4,000 characters in the What's New in this Version field. The field is not available for an app's first version. It is required for every version after that, and you can localize it.

### Should release notes list internal changes?

Usually no. Leave out refactors and cleanup that users cannot see. If engineers want those details, link to the full changelog. Keep the customer note focused on what changed for the user.

### Can Lazur write release notes from my tickets?

Lazur drafts and types text, and it answers questions about what is on your screen while you hold ⌥ ⌘. It does not operate your tracker or other apps for you. Paste the facts in, then check every line against the source.

### What should I do about customer names in release notes?

Do not name customers unless they gave permission. If your product handles health, legal, or financial data, follow your employer's rules on client or patient data before you paste anything into an AI tool.

### What if the release has no visible change?

Record it in the internal changelog and skip the customer note. Customers do not need a note for a fix they never notice. Engineers and support still benefit from a short internal line.

### How do I start if my team has no template?

Start with the last release. Rewrite each line in customer words, then keep the result as your template. Use the same headings and tone for the next release, and adjust them after each one.

## Sources

1. [Automatically generated release notes - GitHub Docs](https://docs.github.com/en/repositories/releasing-projects-on-github/automatically-generated-release-notes), GitHub, checked 2026-11-08
2. [gh release create - GitHub CLI manual](https://cli.github.com/manual/gh_release_create), GitHub, checked 2026-11-08
3. [App Store Connect Help: Platform version information](https://developer.apple.com/help/app-store-connect/reference/app-information/platform-version-information), Apple Developer, checked 2026-11-08
4. [Project Management Specialists: Occupational Outlook Handbook](https://www.bls.gov/ooh/business-and-financial/project-management-specialists.htm), U.S. Bureau of Labor Statistics, checked 2026-11-08