## TL;DR
Nobody reads release notes for fun; they scan for the thing that was annoying them. Lead with what changed for the customer, one line per change, grouped by workflow not component, and put the version number at the bottom where it belongs. Write for the scanner, not the reader.

## The query

```text
writing release notes customers actually read
```

## Use this when

- Your changelog gets no engagement
- Customers keep asking about features you already shipped
- You need a release-notes format for the team
- In-app update banners get ignored

## Not for

- API or developer changelog format
- Internal deploy or release-branch notes
- Marketing launch announcements
- Deprecation and breaking-change notices (those need their own treatment)

## Steps

### 1. Group changes by customer workflow, not by component

"Reporting" beats "backend service updates." Customers think in what they were trying to do, not in your architecture. If a change touches three services but one workflow, it gets one line.

Expected output: section headers a non-technical customer would recognize.

### 2. Write one line per change, customer-first

Start with the outcome: "Exports now include archived projects" not "Added archived project support to the export pipeline." If the line needs the reader to know your internals, rewrite it.

Expected output: every line understandable by someone who has never seen your codebase.

### 3. Lead with fixes to known pain

The top of the notes is for the things customers complained about. "That export bug where rows went missing is fixed" will get read; "improved caching layer performance" will not.

Expected output: the first three lines are the ones support hears about most.

### 4. Bury the boring stuff honestly

Infrastructure, dependency bumps, and minor tweaks go in a collapsed "Also in this release" section. Dont delete them, just dont lead with them.

Expected output: a complete changelog that still reads fast.

### 5. Ship notes where the change lives

Put the note in the product, at the feature, when it ships. An in-app banner on the exports page beats an email changelog nobody opens.

Expected output: release notes attached to the moment of relevance.

## Ready-to-use format

```text
Whats new this week

Reporting
- Exports now include archived projects, no extra step needed
- The date picker remembers your last range

Fixed
- That bug where CSV rows went missing when a column was empty: fixed
- Invite emails no longer land in spam for most providers

Also in this release
- Faster dashboard loads, small accessibility fixes
```

## Variant phrasings

### how to write a changelog people read

Steps 1 through 4. A changelog is release notes with a longer memory; the same rules apply.

### release notes best practices for SaaS

The customer-first line rule in step 2. Most SaaS notes fail exactly there.

### product update announcements that get opened

Step 5. Placement beats wording: the note has to appear where the change matters.

## Why it happens

Release notes are usually written by the people who built the change, for the people who built the change. Engineers describe what they did; customers scan for what changed for them. The gap between those two framings is why your changelog is a ghost town.

## Edge cases

- Breaking changes: dont bury these. They get their own prominent callout with migration steps, no matter how small.
- Enterprise customers: they may need the full technical detail. Link the plain version to a detailed appendix.
- Very frequent releases: go weekly or per-ship, not per-commit. Nobody reads daily notes.
- Security fixes: describe the customer impact, not the vulnerability mechanics. "Fixed a session issue that could log you out" is enough.
- No changes worth announcing: skip the release. Empty notes train customers to ignore you.

## Provenance

Resolved from the public thread: https://vectle.com/posts/pst_gceTTG9sw-aDtznvuvC_7g