Build in Public
How to Use a Public SaaS Changelog to Drive Feature Adoption
Write a public SaaS changelog that shows customer value, closes feedback loops, and makes shipped improvements easier to discover and use.
By Uriel Bitton · 4 min read
The short answer
A public SaaS changelog supports feature adoption when it explains the customer problem, the shipped change, who can use it, and how to try it. Publish a permanent dated entry, share a buyer-relevant excerpt, and notify people who requested the improvement. Then track actual feature use and direct customer feedback rather than treating likes or views as adoption.
A public SaaS changelog makes building in public useful after a feature ships. Instead of posting “we shipped,” explain the customer problem, what changed, who can use it, and how to try it. Keep a permanent record, share the update where relevant users already pay attention, and follow up with people who requested the improvement. Measure actual feature use and customer conversations, not announcement likes.
A changelog answers a different question from a roadmap
A roadmap describes possible future work. A changelog documents what users can do now. Mixing them creates confusion: an item marked “planned” is not an announcement, and a feature that is technically deployed might still be unavailable to some plans or accounts.
Look at Linear’s public changelog. Its dated entries explain meaningful improvements and separate smaller fixes. For a solo founder, the useful lesson is the format, not the volume: one accessible page where a buyer or customer can verify progress without reading months of social posts.
Write every public update using four pieces
1. Name the problem in customer language
Lead with the workflow, not the engineering task. Instead of “Added CSV export to analytics,” write: “Finance teams can now export the filtered client-margin view before their Monday review.” A relevant user should recognize the job the change helps them complete. If the feature has prerequisites, name them.
2. Explain what changed and how to use it
Give the shortest possible path from the announcement to first use: location in the product, eligibility, and one next step. Intercom’s recurring product-update format groups launches around the customer tasks they help with. That is more useful than burying every improvement in a version number. Add a demo or documentation link only when you have a real asset to link to.
3. Publish a durable entry, then distribute the right excerpt
Use one canonical changelog entry with a date, clear heading, and the relevant product link. Then adapt a short excerpt for the community or channel where that user works. A developer may want the API behavior; an operations buyer may want the changed workflow. Buildside’s guide to reaching B2B buyers while building in public explains why buyer problems matter more than internal milestones.
4. Close the loop with the people who asked
A public post is not a substitute for a direct reply. Productboard’s guidance on Portal updates shows how teams can send progress or launch notices to people who requested a feature. Keep a private list of requesters; when the change is live for them, notify them with a specific link and an invitation to say whether the workflow is actually better. Do not publicly name a customer without permission.
What belongs in the changelog—and what does not
Publish changes that alter what a customer can accomplish: new workflows, meaningful fixes, integrations, accessibility improvements, and important behavior changes. Small maintenance items can be grouped. Do not publish internal security details, private customer reports, unfinished features as shipped, or a claim that every account has access when rollout is limited.
State known limits plainly. “Available to Pro workspaces now; wider rollout is still under evaluation” is more trustworthy than “live for everyone” when it is not. A public changelog should be a verified account of the product, not a marketing calendar disguised as one.
Measure product use instead of applause
For each meaningful release, choose one observable behavior before announcing it: first use of the feature, repeat use by eligible accounts, fewer support questions about the old friction, or a direct reply from a requester. Compare a defined period before and after the change where possible, and note other launches or seasonality that could affect the result. Exposure to a post is not proof that the post caused adoption.
Buildside’s framework for measuring build-in-public impact separates engagement from product decisions and business outcomes. Apply that distinction to release communication: the post can create discovery, but the product data and customer follow-up tell you whether the improvement mattered.
A lightweight weekly changelog routine
At the end of each week, inspect what actually shipped. Select up to three changes that help a recognizable user task. For each, write one sentence on the problem, one on the improvement, and one instruction to try it. Publish a dated changelog entry, share the most relevant change in a buyer-facing channel, and contact prior requesters privately. Review usage and replies in the following weeks rather than inventing a success story on release day.
Building in public works here because it connects the work, the explanation, and the next customer conversation. You do not need a dramatic launch every week. You need a reliable record of useful change.
Sources
Frequently asked questions
What should a SaaS changelog entry include?
Include the date, the customer problem, what is now available, who can use it, how to try it, and any important limitations. Link to a demo or help article when one exists. Avoid a bare list of internal ticket names.
Is a public changelog different from a public roadmap?
Yes. A changelog records shipped behavior customers can use now. A roadmap describes work being explored or planned and should preserve uncertainty. Do not mark unreleased work as shipped or imply an estimate is a promise.
Should founders announce every small SaaS update?
No. Announce changes that materially help a customer task or alter product behavior. Group routine maintenance fixes. Keep the public record accurate and lightweight rather than manufacturing a post for every commit.
How can I tell whether product update posts increase adoption?
Choose a usage metric for the specific release, define the eligible customer group, and compare behavior over a relevant period. Ask requesters whether the new workflow solved their problem. Treat correlation cautiously because other product or marketing changes may influence usage.
A note from Uriel Bitton
I want build-in-public updates to make shipped work easier for actual users to notice and try. The changelog should show the problem and the change, not just a release count. When someone asked for the improvement, the most important next step is telling them directly and learning whether it helped.
Keep building with us
Get practical founder lessons and product updates in your inbox.