Release notes are the cheapest, most-skipped marketing you have. Most teams either stop writing them or write them for other engineers. Here's how to write ones your actual users read.
In casual use the two terms overlap, but there's a useful distinction. A changelog is usually the running, dated list — every entry, in order, often auto-generated from commits or tickets. Release notes are the user-facing write-up of what a specific release means for the person using the product: what's new, what changed, what to do differently (if anything). A good changelog can be read by a machine; good release notes are written for a human who has thirty seconds and doesn't care about your internal ticket IDs.
Fizlog's widget publishes both from the same entry — the dated list is the public changelog page and RSS feed, and each entry's title + body is the release note.
A few concrete reasons teams keep doing it even without a dedicated writer: it reduces "did you know you can..." support tickets, it's evidence to churned or inactive users that the product is still actively improving, and — less obviously — a public, dated changelog page is crawlable content that can rank for long-tail searches about your product's specific features, something a changelog bolted onto a help center rarely does.
[Type: New / Improved / Fixed] Title in plain language (5–8 words) One or two sentences: what changed, and why it matters to the person reading — not how it was built. Optional: a link to "Learn more" / docs / the relevant setting.
That's the whole shape. Three types is usually enough — New for features that didn't exist before, Improved for changes to something that did, Fixed for bugs. Resist adding more categories; the point is a reader can scan the label and decide in half a second whether to keep reading.
fix: null check in invoice export path, resolves race condition on concurrent PDF generation requests
Fixed: invoice PDFs could occasionally fail to download when exported right after an invoice was created. They now generate reliably every time.
The "after" version keeps the same underlying fact but answers the only question a user actually has: does this affect me, and is it fixed now. If writing that rewrite by hand is the part you keep skipping, Fizlog's Pro plan includes a one-click "Rewrite for users" button that turns a raw commit message or ticket title into this before you publish.
A doc works until you want users to actually see updates inside your product. A changelog widget like Fizlog adds the in-app bell notification, a public page, RSS, and email alerts on top of the same writing habit — the writing is the hard part either way.
Whatever cadence you can keep up without padding entries — weekly or biweekly batches of real changes beat a daily trickle of filler, and both beat a changelog that goes silent for months.
Only the ones a user would notice. Silent internal fixes don't need an entry; anything that was visibly broken is worth a short "Fixed" line so affected users see it was resolved.
Fizlog turns this template into a widget, a public page, and an RSS feed from the same entry — free for one project.
Start free — no credit cardAlready using something else? See how Fizlog compares to Beamer, Canny, Headway and others.