Most teams ship far more than their customers notice. News and changelogs are the two places that fix that, and they work differently — which is worth knowing before you write in the wrong one.
A news post appears in the messenger, in its own tab, for customers who look. It's an outbound campaign like any other, which means you can target an audience — a feature that only matters to one plan can be announced only to that plan.
Nothing is interrupted. That's the point: the cost to a customer who isn't interested is zero, so news can carry the things that aren't worth an email.
Changelogs live on your feedback portal rather than being sent. They're the public, permanent record — a page anyone can read, including people who aren't customers yet.
Customers can subscribe, and entries can take comments, which turns a release note into a place where people tell you whether the change helped.
Lead with what a customer can now do, not with what you built. “You can now export filtered views” beats “Improved export module”, and “Various bug fixes and improvements” tells nobody anything.
Link to the help article, so an announcement turns into someone actually using the thing. And write for the customer who has never read a changelog before — internal names for features are the most common way to lose them.
One post every two weeks, reliably, does more than twelve in a day after someone remembers the changelog exists. Regularity is what makes people check it.
If keeping it up is hard, the recorder can draft an entry from a screen recording of the change — which turns writing a changelog into reviewing one.
News and changelogs can be used as a knowledge source, which means “is this available yet?” becomes answerable. That question is otherwise a gap in every help center, because documentation describes what exists rather than when it arrived.