.png)
If you want real examples to study: This article breaks down 13 release notes from SaaS companies worth paying attention to, annotated for what works and why.
If you need a starting point: There's a copy-paste release notes template you can adapt for major releases, minor updates, and bug fixes.
If you want to get better at writing them: Seven practical steps walk you through how to write release notes that users actually read, with before-and-after examples.
Most release notes are unread. Not because users don't care about what's changing in the product, but because the notes were written for the team that shipped the feature, not the person who needs to make sense of it.
You've probably seen this before: a release note that opens with "Implemented enhanced data persistence layer for improved throughput" when what the user actually needed to hear was "Your reports now load twice as fast." The first version checks a box. The second one drives adoption.
That gap matters more than most teams realize. A release note is a product communication moment. It's the window between shipping and adoption. Get it right and users explore the thing you built. Miss it and the feature might as well not have shipped.
This article gives you what you need to close that gap: 13 release notes examples from companies that do this well (organized by what makes each one worth studying), a template you can take and adapt today, and a step-by-step writing guide that covers the fundamentals. Whether you're a product manager writing your first release note or a product marketer refining the process, you'll walk away with something you can use immediately.
A release note is a brief, user-facing report published alongside new or updated software. It explains what changed, why it matters, and who it affects. For new releases, release notes give users a summary of what the product does. For updates to existing products, the notes explain what's new, what's improved, and what's been fixed since the last version.
Release notes vs. changelog
The terms get used interchangeably, but they're different things. Release notes describe a specific version or update in detail: what changed, why it matters, who it affects. A changelog vs. release notes distinction worth understanding: a changelog is the running log of all release notes over time. Think of it as the archive. Many products maintain both: individual release notes for each update, and a changelog page where they all live together in reverse chronological order.
Keeping that running record matters. It shows customers the product is improving continuously and that recent changes build on older ones. It also signals that the company listens to feedback and is committed to the user experience.
Not every update deserves the same treatment. The format and depth of your release notes should match the scope of the change:
They're the bridge between shipping and using. Users who understand what changed are more likely to explore and adopt new features. Release notes are the product communication moment where you translate what the engineering team built into something the user actually wants to try. Without that translation, features go unnoticed, and feature adoption suffers as the effort your team invested in building them doesn't reach its potential.
They reduce your support team's workload. Proactive release notes reduce inbound questions about why something looks different or works differently. When users encounter a change they weren't expecting, they open a support ticket. When they've already read a clear explanation, they don't. The math is simple: document the change before users stumble into it.
They build customer trust and retention. Visible, regular release notes signal that the product is actively improving. For customers evaluating whether to renew or expand, a healthy changelog is evidence that the product is going somewhere. For customers who submitted feature requests, seeing their feedback reflected in release notes deepens loyalty.
They sharpen internal alignment. The discipline of writing good release notes, specifically answering "what changed, for whom, and why it matters," forces product teams to communicate clearly across the org. Product marketing, customer success, and sales all benefit when release communications are crisp and consistent. The release note often becomes the source of truth that other teams reference when talking to customers about what's new.
Think of this as the anatomy of a release note. Every solid release note covers these elements, though the depth varies depending on whether you're announcing a major feature or a routine bug fix:
Knowing what to include is the foundation. How you write it determines whether anyone actually reads it. These seven steps are ordered for flow: start with what to say, then how to say it, then how to present it.
This is the single most important principle in release note writing. Every change was built to solve a problem or unlock a capability for the user. Lead with that.
The instinct is to describe what your team built. Resist it. Instead, describe what the user can now do (or no longer has to deal with).
Before: "Implemented batch processing for data exports with configurable chunk sizes."
After: "You can now export large datasets without the process timing out. Exports that used to fail after 10,000 rows now handle up to 500,000."
The first version describes the engineering work. The second describes the user's experience. Write the second version.
Users scanning release notes want two things: what changed and whether it affects them. Make both answers obvious within the first sentence of each item.
Clarity matters because web users don't read linearly. They scan. So make your release notes scannable. Highlight important keywords. Use bold text for feature names and change types. Front-load the most important information in each line.
Before: "Bug fixed and updates applied."
After: "We fixed a bug that caused unexpected crashes when switching between apps. App switching is now stable across all supported devices."
The first version is short but tells the user nothing. The second is still concise but answers the questions the user actually has.
Release notes can serve different purposes: promoting new features, building a relationship with the user, helping people find solutions. But none of that works when the notes are full of technical jargon that only your engineering team understands.
Unless you know your audience will easily comprehend specialist language, ease up on the jargon. Use straightforward, understandable phrasing. A good test: read the release note out loud to someone who doesn't know the technical background. If they get it, your users will too.
Before: "We have implemented the ability to use Graphics Interchange Format bitmap images which includes file compression, transparency, interlacing and storage of multiple images within a single file for our messaging service."
After: "You can now use GIFs in our messaging service."
Plain language isn't dumbing things down. It's respecting your user's time.
If your release note needs a lengthy written explanation, that's a signal to add a visual instead. A short GIF or annotated screenshot showing a feature in action communicates more than two paragraphs of description for any UI change.
This is especially useful for:
Visuals reduce the burden on the reader and make your release notes more memorable. When a change is visual by nature, show it visually.
Users become numb when asked to read a wall of text. Keep things organized and segmented with subheadings, categories, bullet points, and paragraph breaks. Breaking up large blocks of text helps users find which changes apply to them without reading everything.
Good organizational patterns include:
Consistency is a feature, not a limitation. When your release notes follow a predictable structure, users learn where to look for the information they care about. They'll spend less time parsing and more time understanding.
Pick a template (there's one in the next section you can copy), customize it for your product, and use it every time. This also speeds up the writing process for your team, since the structure is already decided.
Your release notes should sound like your brand, not like a commit message. If your brand is warm and approachable, your release notes should be too. If your brand is precise and professional, match that.
The key is to be genuine without overdoing it. You can add personality without sacrificing clarity. A little warmth goes a long way, but heavy self-promotion erodes trust. A useful guideline: 80% of the content should be genuinely useful information, and only 20% should reflect brand positioning or voice.
What to avoid: "We're here to revolutionize your workflow, something we've done successfully with every update. You're welcome. Our new hotfix includes 50% less energy consumption."
Better: "Bugfix: Software now reduces end-user energy consumption by 50%. One of many ways we're working toward a more sustainable future."
The first version inflates the brand and overpromises before mentioning the change. The second tells you the fix, then adds the brand angle naturally.
.jpeg)
Here's a release notes template you can copy and adapt. It covers the essentials for most updates. Adjust the depth based on the scope of your release: major releases get more detail per feature, minor releases can compress sections, and bug-fix-only releases can skip the "What's new" block entirely.
[Product name] release notes - [Version number or date]
Summary: [1-2 sentence overview of what this release addresses and who it affects]
What's new
- [Feature name]: [What it does and why it matters to the user]
- [Feature name]: [What it does and why it matters to the user]
Improvements
- [What changed] - [How it affects the user's experience]
Bug fixes
- [What the user experienced before] - [What happens now]
Known issues
- [Issue description] - [Workaround or timeline if available]
Questions? [Link to help docs or support contact]
How to adapt the template: For a major release with three new features, expand the "What's new" section with a paragraph per feature. For a minor release with five small improvements, you can combine "What's new" and "Improvements" into a single list. For a bug-fix-only release, lead with the fixes and drop the feature sections entirely. The structure should serve the content, not the other way around.
The examples below are organized into five categories based on what each company's release notes do particularly well. For every example, you'll find: what the company does, what their release notes get right, and a specific, transferable lesson you can apply to your own.
These examples show how to write for the user who just wants to know what changed and whether it affects them.
What they do: Linear is a project management and issue tracking tool built for software teams.
What their release notes do well: Linear's changelog uses short, punchy headings and plain-language descriptions for every change. There's no jargon, no feature-name-first structure. Each entry leads with the user impact: what you can do now that you couldn't before. The writing is tight, rarely more than two or three sentences per item, and every word earns its place.
What to emulate: Lead with the user impact ("You can now do X") rather than the feature name. If your heading says "New: Batch operations for issues," rewrite it to "Move, label, or close multiple issues at once." The user doesn't need to know your internal name for the feature. They need to know what it lets them do.
What they do: Notion is a connected workspace for notes, docs, project management, and wikis.
What their release notes do well: Notion's release page strips all technical language and organizes updates by what the user gains. Each entry is framed around a capability or outcome rather than an engineering deliverable. The tone is conversational without being casual, and the notes group related changes together so the user sees the full picture of what improved.
What to emulate: Use "here's what you can do now that you couldn't before" as your framing device. It forces you to write from the user's perspective and naturally eliminates technical jargon. If you can't finish that sentence for a given change, the change might not be worth including in user-facing notes.
What they do: Help Scout is a customer support platform for growing teams.
What their release notes do well: When announcing a new feature, Help Scout doesn't just describe the feature. They cross-link from the new capability to existing features that users might not be taking advantage of yet. For example, when announcing an update to their Messages editor, they link to documentation on related features like Markdown formatting, drawing attention to capabilities some users may have overlooked.
What to emulate: Use release notes as a discovery moment, not just an announcement. Cross-link new features to existing ones that complement them. This is a smart tactic for driving feature adoption: users who came to learn about the new thing leave knowing about two or three things they can try.
These examples show how design, categorization, and visual hierarchy reduce cognitive load and help users find what matters to them.
What they do: Retool is a platform for building internal tools and business applications.
What their release notes do well: Retool categorizes every update as "Minor," "Improvement," or "New." This labeling system creates a scanning shortcut: users who only care about new features can filter immediately, while users tracking bug fixes can find those just as quickly. Each release note also includes a feedback mechanism where users can leave sentiment reactions, creating a built-in feedback loop on the release itself.
What to emulate: Tiered labeling. Adding category tags to your release notes is low effort to implement and high value for users. It lets different audiences self-select the information they need. The feedback loop is worth considering too: knowing how users feel about a specific release helps you calibrate future communications.
What they do: UiPath is an enterprise automation and AI platform.
What their release notes do well: UiPath's release notes are long and technical by necessity (enterprise automation has a lot of moving parts). The table of contents solves a real navigation problem: users can jump directly to the component or module that affects their workflow without scrolling through pages of updates that don't apply to them.
What to emulate: If your release notes are long, give users a map. A table of contents is especially valuable for enterprise products or platforms with multiple modules. The goal isn't to make users read everything. It's to help them find the one thing that matters to them as fast as possible.
What they do: Canny is a feedback management and changelog tool for product teams.
What their release notes do well: Canny's changelog uses tag-based filtering (Features, Improvements, Bug Fixes) combined with a running timeline. Users can toggle filters to see only the category of changes they care about. The visual design is clean, with each entry clearly labeled and dated, making it easy to track what changed and when.
What to emulate: Tag filtering is low effort to implement and high value for users who only care about one category of change. Even if you don't build a custom changelog tool, you can replicate this pattern with clear category labels and a consistent structure that makes filtering easy, whether manually or with simple page search.
What they do: Amazon Business is Amazon's procurement and purchasing platform for organizations.
What their release notes do well: Amazon Business handles a high volume of changes across multiple product areas. Their release notes page uses drop-down menus to segment notes by category, product name, and release date. For enterprise users who need to find updates relevant to their specific use case, this segmentation is essential.
What to emulate: Segmentation for multi-product or enterprise products. When you're shipping updates across multiple product areas, a flat chronological list doesn't serve users well. Let users navigate by the dimension that matters to them: product area, date, or change type. The more complex your product, the more your release notes need structured navigation.
These examples show how GIFs, screenshots, and short videos increase comprehension and reduce the need for long written explanations.
What they do: Amplitude is a digital analytics platform for understanding user behavior.
What their release notes do well: Amplitude embeds short animated GIFs and screen recordings directly in each feature release entry on their changelog. Rather than describing a new chart type or filter in three paragraphs, they show a 15-second recording of it in action. The visual does the heavy lifting, and the written description adds context.
What to emulate: A short GIF showing a feature in action communicates more than two paragraphs of description for any UI change. If the change is visual by nature (a new interface, a new workflow, a new output), show it. The production quality doesn't need to be high. A screen recording with a brief caption is enough.
What they do: Loom is an asynchronous video messaging platform for workplace communication.
What their release notes do well: Loom uses short video clips in their changelog to show new features in context. Given that their product is a video communication tool, this is a natural fit: they're using their own product as the release note medium. Each video walks through the feature in under 30 seconds, giving users a clear picture of what's new without requiring them to read detailed explanations.
What to emulate: Match the format to the feature. If you build a screen-capture tool, use screen captures in your release notes. If you build a design tool, use designs. If you build a data platform, show the data. Using your own product to communicate about your product is both practical and a subtle demonstration of value.
What they do: Figma is a collaborative interface design and prototyping tool.
What their release notes do well: Figma's release notes use a mix of visual diagrams, annotated screenshots, and sometimes animated demonstrations to illustrate complex UI or collaboration changes. For a design tool, where the changes are inherently visual, this approach is far more effective than written descriptions alone. The annotations call out exactly what's different and where to find it.
What to emulate: For any product with significant UI changes, showing is faster than telling. Annotated screenshots (with arrows, highlights, or callout labels) are especially effective because they direct the user's eye to the exact change. You don't need a design team to create these. A screenshot with a few annotations in any basic image editor works.
These examples show how in-app delivery puts the release note in the context where the change actually happens, rather than on a separate page the user may never visit.
What they do: Feefo is a reviews and customer feedback platform for businesses.
What their release notes do well: Feefo uses Appcues to announce its latest features and releases directly inside the app. The key is the timing: the slideout modal appears when a user first encounters the changed area, not at login and not in a generic email. The user sees the announcement in the exact context where the change matters most, and they can click through to read the full release notes if they want more detail.
What to emulate: Match the delivery channel to the trigger moment. If a change affects a specific feature, show the release note there, not on a global changelog page. The closer the message is to the moment of change, the more effective it is. In-app delivery, through a modal, slideout, or announcement bar, puts the release note where the user will actually encounter the change.
What they do: Slack is a workplace messaging and collaboration platform.
What their release notes do well: Slack uses in-app "What's new" callouts and contextual tooltips to surface changes within the product itself. When you open Slack after an update, you may see a brief in-app banner or tooltip highlighting the change right where it lives, whether that's in a new sidebar layout or an updated message composer. The delivery is lightweight and contextual, not a modal that blocks your workflow.
What to emulate: In-app release notes don't have to be a full-screen announcement. Sometimes a tooltip or subtle banner at the point of change is more effective than a large modal. Think about the weight of the change and match the weight of the communication: small changes get small callouts, big changes get bigger treatments.
These examples show that release notes can reflect a company's personality without sacrificing clarity.
What they do: 37signals makes Basecamp (project management) and Hey (email), and they're known for strong opinions about product design and communication.
What their release notes do well: 37signals has a well-documented philosophy about product communication. Their Hey "What's New" entries and Basecamp updates are short, confident, and opinionated. Each entry makes a clear point in one or two sentences, without hedging or over-explaining. Minor improvements get a single direct sentence. Major changes get a few more, but never a wall of text.
What to emulate: Brevity paired with confidence. Not every release needs a five-bullet explanation. For minor improvements, a single direct sentence is enough: "Search results are now instant. No more waiting." That kind of writing builds trust because it respects the reader's time. If your brand has a point of view, let it show in your release notes. Voice and clarity aren't in tension with each other.
Writing great release notes is half the job. The other half is making sure the right users actually see them. Not everyone checks your changelog page, and not every update warrants an email blast. The distribution channel should match the importance and context of the change.
Here's where each channel works best:
The closer the message is to the moment of change, the more effective it is. When a user receives an email about a new feature, they're reading about it in one context and experiencing it later in another. In-app messaging closes that gap: the user reads about the change while they're already in the product, often right where the change lives.
This is where a tool like Appcues helps. Rather than building custom in-app announcement infrastructure, you can trigger release note messages based on user behavior, such as which features someone has or hasn't explored yet. That means the user who's already using the updated feature doesn't get a redundant notification, while the user who hasn't discovered it yet gets a timely prompt.
After studying 13 examples across five categories, a few patterns emerge consistently:
If you're looking to go beyond writing better release notes and want to make sure the right users see them at the right time, that's the delivery side of the equation. Appcues helps teams trigger in-app messages based on user behavior, so your release notes reach users in the context where the change actually matters.
And if you're planning a larger launch, not just a routine update, our Ultimate Guide to Product Launches covers the full release playbook.
You've got the examples. You've got the template. The last piece is making sure the right users see your release notes in the right context. With Appcues, you can trigger release note messages based on which features a user has, or hasn't, explored yet. That's the difference between announcing a release and actually driving adoption.
