One release, four decisions
The clock is a constraint on coordination, not permission to skip verification. Stop it when a deadline, migration or security claim cannot be supported by the merged evidence.
- 01Minutes 0–3 · Group the shipped work
Start with the merge that carries the customer outcome. Add only pull requests that complete the same story: supporting UI, migration logic, documentation or rollout work. Leave maintenance and unrelated fixes for another Update. Give the release a boundary a reader can understand without seeing the branch names.
- 02Minutes 3–8 · Edit for each audience
Read the release note, internal brief, email and social drafts separately. Keep the outcome consistent, then remove what that audience does not need. Internal copy may name owners and rollout risks; customer copy should lead with consequence and action; a public record should remain useful after today’s notification disappears.
- 03Minutes 8–11 · Verify the consequential claims
Check dates, removals, changed defaults, availability, pricing, access rules and required customer actions against their attached sources. Resolve uncertainty or delete the claim. Do not replace a missing fact with softer language that still implies the same promise.
- 04Minutes 11–13 · Choose destinations and preview
Remove every channel that does not deserve an interruption. Confirm the Slack room, email audience, CMS webhook and social account; preview the sender, brand and links. A correct draft sent to the wrong audience is still a failed release communication.
- 05Minutes 13–15 · Approve one revision and send
Approve the exact version you just read, then inspect the outcome for each destination. Retry only the place that failed. Copy the private Markdown to your own changelog when no CMS destination is connected, and keep the source evidence with the Update for the next support question.
If verification does not fit inside the window, the correct result is a saved draft with a named blocker. Fifteen minutes is a useful operating target, not a promise that ambiguous source material becomes safe on schedule.
The seven checks that prevent expensive corrections
Run these against the final preview, after editing. A draft can be factually accurate and still fail because it reaches the wrong people, buries an action or promises a channel that is not connected.
- One release story
Every included merge contributes to the same outcome. If the headline needs “and” to connect unrelated features, create another Update instead of manufacturing a theme.
- A named affected audience
The message identifies who experiences the change: workspace owners, API consumers, support agents or all users. “Customers” is too broad when only one workflow moves.
- A customer consequence before implementation
The opening explains what becomes possible, different or unavailable. Component names and architectural work appear only when the reader needs them to take action.
- One unambiguous next action
When the reader must migrate, enable or review something, the verb and deadline are visible. When nothing is required, the draft says so without inventing urgency.
- Links open for the recipient
Test every call to action outside the author’s authenticated browser. Customer email must not point into a private repository or an internal document the audience cannot reach.
- Brand and sender match the promise
Preview the stored brand snapshot and sending identity. A migration email should look recognisable, but visual polish must not hide the sender or the reason for contact.
- The destinations are deliberate
Internal, public, customer and social routes are selected for this Update rather than inherited by habit. Remove email when the durable changelog record is enough.
Keep the shared fact; change the editorial job
Use this table when two drafts begin to look identical. The source event stays common, while the reader’s decision determines what belongs to keep.
| Draft | Must answer | Usually not |
|---|---|---|
| Internal Slack or Teams | What shipped, who needs to know, rollout state, owner and the next internal action | Promotional framing, every implementation detail or a customer call to action |
| Customer email | Who is affected, what changes, when it matters and the one action to take | Repository references, team ownership or the complete release history |
| Release-note record | A durable explanation of the outcome, scope, availability and relevant limitation | Temporary rollout chatter or instructions that only an internal operator can follow |
| Social post | One outcome understandable outside the current customer base and a useful source link | Migration detail, confidential context or a promise the public release cannot support |
Close the loop while the context is still fresh
Publication is not the final checkbox. Open the delivery outcomes and confirm which destinations succeeded, failed or stayed manual. A targeted retry should touch only the failed destination; resending a customer email because a webhook failed creates a second problem while fixing the first.
Record the question that readers ask first. If support repeatedly has to explain eligibility, the next Update needs that condition earlier. If nobody clicks the long migration guide but accounts still complete the change, the email may already contain enough. Release communication improves through observed questions and behaviour, not through adding more adjectives to the template.
For a young workspace, count a second publication on a different week as the useful activation signal. Creating one polished draft proves curiosity; returning to group, review and send another release indicates that the workflow displaced recurring work.
When fifteen minutes is the wrong target
- Pause when the source does not support a deadline, compatibility statement, security assertion or customer instruction. Ask the owner; do not publish a confident approximation.
- Split the release when several unrelated merges would force different audiences and next actions into one announcement. The ten-source ceiling is a maximum, not an editorial target.
- Use the email platform that already owns consent and segmentation for lifecycle campaigns or large marketing lists. Mergelay prepares release communication; it does not replace an audience system.
- Do not publish a social post merely to complete the checklist. A private fix or operational change can remain an internal brief and durable release-note record.
Questions
Does every release really take fifteen minutes?
No. The sequence is a focused operating target for a well-described merge, not a service guarantee. A breaking change with uncertain rollout evidence should wait until the facts are resolved.
Should every merge become an Update?
No. Routine maintenance is excluded from the proposed selection, and a person can omit any merge or channel. Communication should exist because a reader benefits, not because the repository changed.
Can internal communication publish automatically?
A workspace policy may allow internal communication to continue automatically. Customer email, public and social communication keep their applicable human review boundary, and any edit after review creates a new revision.
What should we measure after using the checklist?
Start with operational adoption: time to the first draft, percentage of drafts approved, delivery success, and workspaces that publish again on a later week. Signups without a completed publication do not prove a recurring workflow.
Where to read next
- Release communication examplesApply the checklist to five complete output packs across different change types.
- API deprecation email exampleInspect the rendered message behind the deadline and mapping checks.
- Automated product updatesSee which preparation steps run unattended and where human control remains.
Run the checklist against a merge that shipped this week.
Your first Update is free. No card required.