Release Communication

There was a stretch where the product changed every two weeks and customers met each change on a Monday morning, on screen, for the first time. The product team kept a careful list of what shipped, but that list was written in the language of the people who built it. Features were added and behaviors were improved, and nowhere did it say what the reader was supposed to do.

The day the approval request button moved showed the size of that gap. One line went onto the shipping list. Forty tickets came in, most of them asking the same thing: where did the button go. Three enterprise customers had screenshots of the old layout inside their internal training material and had to rebuild it, and one of them quietly shelved a plan to expand to two more teams without telling anyone.

Release communication exists to fill that blank. It doesn't stop at describing what changed — it says what the change touches in the customer's own workflow, and what they need to have done by when. The organizing question is not what the team shipped but what the reader now has to handle.

One notice is built from six parts, and the order stays fixed, because readers decide in the first two lines whether this is their problem and keep or stop reading on that basis.

1. A one-line summary. What changes, when, and how, in a single sentence. A subject line carrying only a feature name gets filtered out of an inbox, so the date goes in the title.
2. The date and the audience. All customers or one plan tier, switched on at once or rolled out over several days. Leave the audience blank and customers the change doesn't touch will write in anyway. Pagedeck learned that from a billing change aimed at one plan tier that drew tickets from every tier.
3. What the customer has to do. This is the body of the document, and when there is nothing to do it says so explicitly. An empty section reads as something the customer must have missed, and they write in to check.
4. Before and after. If a procedure changed, list both sequences side by side; if a screen changed, include two images. Prose alone means an admin rewriting the internal announcement can't reuse what you wrote.
5. Existing settings and integrations affected. Permission rules, templates, external connections — anything worth re-checking because of this release. Skip this part and some account's integration goes quiet the week after the release.
6. The help article and where to ask. Detailed instructions belong in a help document — the per-feature reference — so the notice itself can stay short.

Changes that can't be undone are handled separately. When an old method disappears entirely, Pagedeck gives at least 30 days' notice and includes both an interim workaround and a named contact.

The draft comes from the product team, because the people who built the change are the ones who know it precisely, so Theo writes down what shipped and who it reaches. Sofia then rewrites it. What the customer has to do, and what it does to their existing configuration, can only be written by someone who knows how these customers work, and roughly half the sentences change in that pass. For a breaking change Mia sets the notice date and signs off on the interim workaround.

The readers are not one group. They split three ways and want different things. People who use the product daily only need to know how the screen differs. Account admins need to know whether permissions and settings have to be revisited. The person who maintains internal training material at an enterprise customer needs images and a numbered sequence, because they have to rebuild a deck, and a deck that contradicts the live product costs them more credibility than it costs you.

So one notice goes out through several channels. An in-product banner reaches daily users, email reaches admins, and for high-impact changes the account owner contacts the customer directly. Enterprise customers with an internal trainer get an extra training session — a walkthrough run live by their account contact. If you run a certification program that formally recognizes proficiency, its course material gets corrected the same day, because material showing the old screen means your own curriculum is now teaching customers the wrong thing.

"Draft's in for this release, but the section on what customers have to do is empty. If it's nothing, write nothing."

The blank in that section is what comes back as tickets.

"This one changes the approval flow, so it goes out as a 30-day notice. It's not riding along with this release."

For irreversible changes the notice period drives the schedule, not the ship date.

"Don't just email the five enterprise accounts — have their owners tell them. Those are the ones with internal training decks."

Same content, different channel depending on the account.

At Pagedeck, Sofia and Theo read the notice together the day before the release. Most of the work is stripping feature names out of Theo's sentences and replacing them with the names of things customers do. "The permission model changed" becomes "inviting a teammate works differently now."

The week after the release they read the tickets again. If the same question arrives more than ten times, the notice is treated as having missed that item; the document gets fixed and the correction goes into the help article too.

The most common assumption is that posting the shipping list counts as telling customers. Both documents cover the same release, so they look like one job. But a list is a chronological record of what changed, and a notice is a letter about what a particular customer now has to do. Post only the list and the handful of people who go looking will read it, while everyone else finds out when the screen moves and writes in. The list is still worth keeping; it just isn't an announcement.

Deciding that small changes don't need a notice is the other frequent mistake. From the building side, moving a button is a few lines of code and doesn't feel like news. But on the customer side, what makes a change small isn't the size of the diff — it's whether that behavior is baked into an internal procedure. Move a button fifty people press every day and forty tickets arrive, several of them filed as the product being broken. The right measure of size is how many actions a customer has to relearn, not how much work it was to make.