The case for a public changelog
Shipping in silence is shipping half the feature. Why we think the changelog is a product surface, not a compliance chore.
Priya Raghavan
Engineering
Most teams treat the changelog as paperwork — the form you fill in after the real work is done. We think that has it backwards. A feature nobody notices might as well not exist, and the changelog is where noticing happens. It deserves the same care as the feature itself.
Shipping is a communication act
The work isn't finished when the code merges. It's finished when the person it was built for knows it exists, understands what changed, and adjusts how they work. Skip that last step and you've paid the full cost of building for a fraction of the value. The changelog is the cheapest, most durable way to close the loop — cheaper than a launch post, more permanent than a tweet, more honest than a banner.
What silence costs
- Support pays first. Every unannounced change generates "did something change?" tickets that a two-line entry would have prevented.
- Sales pays next. Prospects read changelogs the way investors read commit history — as evidence of pulse. An active changelog closes deals quietly.
- The team pays last, and most. Work that vanishes unannounced teaches builders that finishing doesn't matter. Announcing is how a team applauds itself on the record.
A public changelog is a promise with a timestamp: we are alive, we are moving, and we're not afraid to say what changed.
Making it cheap enough to be honest
The reason changelogs go stale isn't laziness — it's cost. If publishing takes an afternoon, it happens quarterly and reads like a press release. Our whole approach is to drive that cost toward zero: notes draft themselves from merged work, review takes minutes, and publishing is one action. When announcing is nearly free, teams announce nearly everything — and the changelog becomes what it should have been all along: the product's heartbeat, visible from outside.
Write it for the reader
One craft note, since tooling only gets you to the door. Write entries about the reader's Tuesday, not your sprint: what they can do now that they couldn't last week. "Boards scroll smoothly at 1,000 issues" beats "refactored board virtualization." The commit message is for your team. The changelog is for everyone who bet part of their workday on you.
Draft keeps planning, shipping, and announcing in one connected workspace. Start for free or read the docs.