Skip to content
Product Lifecycle Templates

Announcement / Internal Comms

beta  ·  Family delivery-docs  ·  Phase deliver  ·  Sizes lean  ·  ~3,350 tokens

The message that tells the people in an organization who did not do the work that something is launching or changing: what is changing, why it matters to this reader, what they must do and by when, and where the underlying record of the change lives. It translates a decision already made; it does not restate the decision’s own supporting facts.

The short card. Why the document is shaped this way, and the full argument behind every rule here, is in announcement-internal-comms_companion.md. A fully worked instance is announcement-internal-comms_example.md.

Read this before you reach for the template. No standards body, government communication function, or professional institute publishes this document by name. This bundle’s admission rests on three sources, all vendor or practitioner tier: a vendor’s blog that names and defines the type with worked templates, a company handbook that prescribes what a company-wide announcement must carry, and a practitioner’s account of one company’s own named internal format. Its evidence on channel choice and timing is vendor and practitioner tier only, nothing here rises to a standards-tier norm for a product launch. Treat any specific number you see below (a notice window, a repetition count) as one organization’s own house rule, never as a convention every team follows.

When to use

Section titled “When to use”
  • A decision has already been made, and you need to tell the people who did not do the work, and were not in the room, what it means for them.
  • You can state a single fact the reader could act on, or use to rule themselves out, without first reading the rest of the document.
  • The change is real, live or about to go live, not a proposal still being vetted for whether it should happen at all.
  • A known issue or open risk needs to reach the people who support the product before a customer surfaces it for them.
  • This is one message about one event, not a recurring cadence update or the start of a standing communications program.

When NOT to use

Section titled “When NOT to use”

The type sits next to several better-documented practices, and it is easy to reach for the wrong one. Name which one you actually need before you start filling this in.

You actually need Because
A periodic status update (a Basecamp-style Heartbeat) This type is written once, for one event. A recurring digest of the last several weeks of work for a team or individual is a different, cadence-driven document.
A PR/FAQ The PR/FAQ is written before the build decision, as a forcing function and a vetting device, as if the product already existed. This type fires after the decision is made, alongside or following the launch itself.
Incident stakeholder communications Bound to the trigger of a live, ongoing incident, with its own status page and repeated per-incident updates. Not a purpose this type also serves.
A change-management communications plan A plan (Prosci’s sense) is a standing, multi-message strategy with its own senders, cadence, and channels across a change’s whole life. This type is one message that plan might schedule, if a plan exists at all.
Release notes The line is purpose, not audience: a release note is a curated, user-impact record of what changed. This type says what that change means for one specific reader and what they must do, then links to the release note rather than restating it. That boundary is this library’s own; no source draws it in those words.
A launch-readiness checklist A multi-workstream tracking artifact that produces announcement-like material as one of its outputs. No source in this bundle’s research names the exact line between the checklist and the announcement it produces; this bundle infers the boundary rather than quoting it.

Who sends it is a choice this template asks you to make, not one it makes for you. The sources disagree: one holds that the project team is the wrong sender for any message and that a personal-impact line should come from the reader’s own manager; launch practice instead assumes the product team runs the briefing; one company simply has whoever did the work write it directly. That disagreement is exactly why Sender is a frontmatter field you fill in deliberately (see rubric row 8), not a default.

Pick a variant

Section titled “Pick a variant”

This bundle ships one size, and there is no second, heavier variant to choose between. That is a deliberate call, not an unfinished one: the strongest source this research found ships seven worked templates for this type, all sharing a single shape, a subject line, a salutation, and three or four sentences, and its two highest-stakes examples (a security incident, a major restructuring) differ from the rest of the set by one sentence, not an added section. The material a heavier variant might plausibly add, a leadership quote or a linked FAQ, appears in that same source only as optional best practice, never as a section inside any worked template. Building a full variant from that material would be this library inventing a shape no one has documented, so none is offered. Treat this single size as provisional, following from the strongest source found rather than from a wide survey of longer internal announcements.

The rubric (self-grade)

Section titled “The rubric (self-grade)”

Score each row 0, 1, or 2. Under 11 out of 16, and a reader who was never in the room still cannot tell whether this affects them or what, if anything, they are supposed to do about it, the exact gap this document exists to close.

All eight rows apply. This bundle ships one size, so there is no per-variant scoping decision to make here.

# Criterion 0 1 2
1 Actionable headline Names no fact a reader could act on (a label like “Product Update”), so the reader has to open the rest of the document to learn anything States a real fact, but the reader still needs the rest of the document to know whether it applies to them or what to do about it A reader can act on it, or confidently rule themselves out, without reading past the headline
2 Honest what, who, when One of what, who, or when is missing entirely All three are present, but an unconfirmed date reads as fixed, or “who it applies to” sweeps in people the change does not actually reach What is changing, exactly who it applies to, and the effective date are all present, and if the date is not fixed yet, the document says so and names when it will be
3 Reader’s own stake The reason given only makes sense to someone on the team that shipped it, in that team’s own vocabulary Plain language, but the reason given is still the team’s reason for doing the work, not the reader’s own stake States, in the reader’s own terms, why this matters to them specifically, not why it mattered to the team that built it
4 Explicit action and non-change No action is named, or a bare “let us know if you have questions” that leaves the reader guessing what is being asked of them An action, or an explicit “nothing to do,” is stated, but a deadline is missing, or what stays the same is never addressed Names the reader’s exact action and its deadline, or says plainly there is nothing to do, and separately says what does not change
5 Known issues surfaced first Left blank or silent despite the team already tracking an open risk An issue is named, but a reader cannot tell whether it is tracked anywhere or who owns it Names a specific open issue, in words a front-line reader could repeat back to someone who asks, whether or not it is resolved yet
6 Linked, not restated Detail that belongs to an upstream artifact (the PRD, the release notes, the checklist) is restated here in the announcement’s own words Links exist, but at least one significant fact is restated rather than pointed at its source Every fact in the document traces to a named, linked source, and none of the underlying detail is restated in the announcement’s own words
7 Contact and next update Neither a specific person nor any sense of when the next update comes is given One of the two is present; the other is missing Names one specific person to ask, and either a date or a named trigger for when the next update comes
8 Deliberate sender Sender is blank, or defaults to whoever happened to draft the message A sender is named, but nothing shows the choice was deliberate The named sender fits what is actually being said: who can credibly speak to the business reason, and, for a personal-impact message, why this sender rather than the reader’s own manager

Every cell above describes evidence, not a count. The test is the same one this library applies everywhere: could someone satisfy the cell without actually making the document better? If yes, the cell is written wrong, and that is a defect in the rubric, not a license to grade loosely.

Named anti-patterns

Section titled “Named anti-patterns”
  1. Burying the point. The newsworthy fact arrives after the context and generic framing that should have followed it, not led it. A reader who has to read three paragraphs to find out what changed has already lost the thread.
  2. Jargon that does not travel. Language that makes sense inside the team that shipped the change, but not past it. Left unchecked, this is not merely unclear, it leaves a reader who does not feel able to ask a clarifying question unsure what is actually being asked of them.
  3. A single channel carrying the whole announcement. Posting once, in a low-visibility channel, so the message gets lost or muted rather than reaching the people it is for.
  4. Broadcasting instead of starting a conversation. The announcement reads as a one-way telling plan, with no room for a reply, rather than something the reader could actually respond to.
  5. No call to action. The document ends with a detailed update and no clear next step. A reader who finishes it feels informed, not activated, and information without action is a courtesy, not a catalyst.
  6. Telling customers before the people who support them. A customer-facing colleague hears about a change from a customer instead of from this document. That is a failure of sequencing, not of knowledge, and it is exactly what the Known Issues section exists to prevent.
  7. Restating instead of linking. Every fact copied into the announcement, rather than linked to its source, is a fact that can drift out of step with the upstream record over time. No source read for this bundle documents this as a named failure; it is this library’s own reason for the link, do not restate rule, and it is labelled as that rather than as an established practice.
  8. Presenting a house rule as a general norm. Stating one team’s own notice window, sender choice, or repetition count as though it were an industry standard, when no source in this bundle’s research supports a general norm for a product launch’s timing. This includes coining or repeating “announcement fatigue”: no source in this research uses that term. The sourced terms for the underlying failure are notification fatigue and message fatigue.

No paired skill

Section titled “No paired skill”

pairs_with: []. No pm-skills skill produces this document today. The nearest, a foundation stakeholder-update skill, translates the outcome of one meeting for people who were not there, which is a narrower job than announcing a launch or a change.

When it is good enough

Section titled “When it is good enough”

When a reader who was never in the room can tell, from the headline alone, whether this affects them, when the action they need to take (or the fact that none is needed) is stated with a deadline rather than implied, when a known open risk is already visible here rather than waiting to be discovered by a customer, and when every fact in the document points at its source instead of repeating it.

Then delete every HTML comment. If the honest answer to “who sends this” or “how much notice does this window give” is a guess rather than a decision, that is worth settling before you send, not after.

The artifacts

Section titled “The artifacts”

announcement-internal-comms_template-lean.md · ~3,350 tokens

---
title: "{{announcement_title}}"
doc_type: announcement-internal-comms
size: lean
audience: "{{audience}}"
channel: "{{channel}}"
send_date: "{{send_date}}"
sender: "{{sender}}"
status: draft
doc_version: "{{doc_version}}"
created: "{{date}}"
updated: "{{date}}"
related_links: []
source_template: announcement-internal-comms
source_template_version: 0.1.0
---


<!--
LEAN ANNOUNCEMENT / INTERNAL COMMS. This bundle ships one size, deliberately. Staffbase's seven worked
templates for this type share a single shape, a subject line, a salutation, and three or four sentences, and
its two highest-stakes examples, a security incident and a major restructuring, differ from the rest of the
set by one sentence, not a section. The material a heavier variant might plausibly add, a leadership quote or
a linked FAQ, appears on that same page only as optional best practice, "Involve leadership" and "Link to
FAQs or additional resources", never as a section inside any of the seven templates themselves. A full
variant built from that material would be an invention of this library rather than a documented practice, so
none is proposed. Treat this single size as provisional, not settled: it follows from the strongest source
this research found, not from a wider survey of longer internal announcements. See
announcement-internal-comms_companion.md section 4 (Variants and sizing).


READ THIS BEFORE YOU FILL IT IN, BECAUSE IT CHANGES WHAT THIS TEMPLATE CLAIMS.
No standards body, government communication function, or professional institute publishes this document by
name. This bundle's admission rests on three sources, all vendor or practitioner tier, and its evidence on
channel choice and timing is vendor and practitioner tier only. A window you see named elsewhere, GitLab's
"ideally 72 hours (at minimum 24 hours) in advance of a due date" or Salesforce's "at least one business day
before the change goes live", is that company's own house rule, never a general norm for a product launch.
If your own team keeps a window, state it the same way, as your own practice, not as a convention everyone
follows. See announcement-internal-comms_companion.md section 1 (Orientation) and section 6 (Debates).


WHO SENDS THIS IS A DELIBERATE CHOICE, NOT A DEFAULT THIS TEMPLATE MAKES FOR YOU. The sources disagree, and
this template does not pick a winner among them. Prosci holds that the project team is the wrong sender for
any message, "One of the biggest and most common mistakes you can make is to have your project team sending
all the communications", and that a personal-impact message should instead come from the reader's own
manager, "People prefer to learn about change-related impacts to their own daily work from their manager".
Launch practice instead assumes the product or product-marketing team runs the briefing. Basecamp has "one of
the people who did the work" write the message directly. That disagreement is why Sender is a frontmatter
field you choose, not a role this template assumes for you. See announcement-internal-comms_companion.md
section 6 (Debates: Who should send it).


LINK, DO NOT RESTATE. Every fact below should trace to an upstream artifact, the PRD, the release notes, or
the launch checklist, rather than being restated here from memory. GitLab's own instruction is direct: "The
majority of information should still be in the Handbook which you include links to." Keeping the detail in
the linked source is also what stops this announcement from drifting out of step with the record it
summarizes over time. See announcement-internal-comms_companion.md section 3 (Anatomy).


HOW TO FILL THIS IN
1. Read the comment under each heading: WHAT it wants, WHY it matters (with a pointer into
   announcement-internal-comms_companion.md for the deep reasoning), guiding questions to ASK, a GOOD and a
   WEAK example, and the TRAP to avoid.
2. Fill the frontmatter first. Audience, Channel, Send Date, and Sender are the author's own decisions, not
   the reader's content, and every body section below assumes they are already set.
3. Replace each {{placeholder}} with your content.
4. If a section does not apply, write "N/A" and one line of why, rather than deleting it.
5. Before you send it: self-grade against announcement-internal-comms_guide.md, then DELETE every HTML
   comment. They are guidance, not content.
-->


# {{announcement_title}}


## Headline


<!-- WHAT  One line a reader can act on without opening the rest of the document.
     WHY   NN/g's own reason is direct: "readers can get the main point, regardless of how much they
           read." Every one of Staffbase's seven worked templates opens with a subject line playing
           exactly this role. Deep dive: announcement-internal-comms_companion.md section 3 (Anatomy >
           Headline).
     ASK   What is the single most important fact here? Could a reader act on this line alone, without
           reading anything below it?
     GOOD  "Customers can pay invoices by direct debit from Monday 3 March; the billing support queue will
           see the first questions that morning."
     WEAK  "Product Update" (names no fact a reader could act on; could be about anything)
     TRAP  Burying the lede: a writer "buries the lede" when the newsworthy part of a story fails to
           appear at the beginning, where it's expected. A marketing agency names the same failure
           plainly: "avoid burying the most relevant information with the generic bits". -->


{{headline}}


## What Is Changing, and When


<!-- WHAT  The launch or change itself, who it applies to, and the date it takes effect.
     WHY   A company handbook's prescribed content for an announcement covers "What, Why, Who, When,
           Where", and a structured internal-comms play opens the same way, asking "What's changing? What
           will be different from the way it is today?" Deep dive:
           announcement-internal-comms_companion.md section 3 (Anatomy > What Is Changing, and When).
     ASK   What exactly is changing? Who does it apply to? On what date does it take effect, and is that
           date confirmed or still to be decided?
     GOOD  "The customer portal adds direct debit as a payment method for monthly invoices. It opens for new
           sign-ups on 3 March and for existing customers on 17 March, once the first month's collections
           have run cleanly."
     WEAK  "We're rolling out some payment improvements soon." (no mechanism, no date, no named audience)
     TRAP  Leaving out When, one of the handbook's own 5 Ws: a reader who cannot tell whether a change is
           live yet cannot act on the rest of the announcement either. -->


{{what_is_changing}}


**Who this applies to:** {{who_it_applies_to}}


**Effective date:** {{effective_date}}


## Why It Matters


<!-- WHAT  The reason for the change, in terms the reader can use, not the reason it mattered to the team
           that shipped it.
     WHY   The same internal-comms play asks "Why is this change happening now? Why is this change
           important?" Deep dive: announcement-internal-comms_companion.md section 3 (Anatomy > Why It
           Matters).
     ASK   Why now? Why does this matter to this specific reader, not to the team that built it?
     GOOD  "Card payments fail for roughly one invoice in twenty when a card expires (illustrative). Direct
           debit removes that failure for customers who choose it, without changing what anyone is billed."
     WEAK  "This aligns with our platform strategy for driving engagement." (a reason that matters to the
           team, not to the reader)
     TRAP  Jargon that travels within the team that shipped the change but not past it. A vendor's
           guidance is direct, "Use plain language and avoid corporate jargon", and so is a marketing
           agency's: "product marketing teams use a lot of jargon. Unfortunately, this doesn't necessarily
           translate well to other departments." A stronger-tier source names the cost of ignoring this:
           a reader who does not feel able to ask questions is left "unsure of what is being asked of
           them". -->


{{why_it_matters}}


## What It Means for You


<!-- WHAT  What changes for this specific audience, what does not change, and what they must do and by
           when, or an explicit statement that there is nothing to do.
     WHY   The same play asks "How will this change impact them?"; a vendor's checklist names "what they
           need to do (if anything)" as content a reader needs; and Basecamp's Deployment post is written
           so it is useful to "those on the front lines too". What is not changing belongs here too, on a
           practitioner's own checklist question, "What’s not changing?", and on Prosci's framing of
           communication around the reader's own stake, "What’s in it for me?" Deep dive:
           announcement-internal-comms_companion.md section 3 (Anatomy > What It Means for You).
     ASK   What changes for this reader specifically? What stays the same that they might otherwise
           assume has changed? What must they do, and by when, or is there genuinely nothing to do?
     GOOD  "If you work the billing support queue, expect questions about setting up a mandate from 3 March.
           Nothing changes for card payments. Read the linked set-up guide before your next shift, and pass
           any mandate that fails to the payments team the same day."
     WEAK  "Let us know if you have questions." (no specific action, no deadline; leaves the reader to
           guess what, if anything, they are supposed to do)
     TRAP  No call to action, now a named failure rather than only a missing best practice: "information
           without action is a courtesy, not a catalyst." Saying nothing is also a valid answer here, but
           it has to be said, not implied by omission. -->


{{what_changes_for_you}}


**What is not changing:** {{what_stays_the_same}}


**What you need to do:** {{required_action}}


**By when:** {{action_deadline}}


## Known Issues


<!-- WHAT  What could go wrong, or is not finished yet, stated here first, before a customer-facing
           colleague hears it from a customer.
     WHY   A Deployment post exists partly to explain what shipped and "points out what could be an
           issue", and a sequencing failure this research names directly is a customer-facing team hearing
           about a feature from a customer, "a failure of sequencing rather than of knowledge". Where this
           overlaps release-notes' own Known Issues content, link there rather than restating it (see the
           preamble's link-do-not-restate rule). Deep dive: announcement-internal-comms_companion.md
           section 3 (Anatomy > Known Issues).
     ASK   What is not finished yet, or could go wrong? Has the team that supports customers heard this
           before a customer could raise it? Is there a tracked issue to link to instead of restating the
           detail here?
     GOOD  "The first collection under a new mandate can take up to ten working days to clear
           (illustrative). A customer who asks why an invoice still shows as unpaid in that window has not
           been charged twice."
     WEAK  (section left blank, with an unresolved risk already known to the team) - silence here is what
           turns a known issue into a support ticket a customer opens first.
     TRAP  Staying silent because nothing is confirmed yet. A known risk stated plainly, even unresolved,
           is what this section exists for; the failure this research names is a customer-facing colleague
           learning about it from a customer instead of from this document. -->


{{known_issues}}


## Where to Learn More


<!-- WHAT  The source of truth, a named person to ask, and when the next update comes.
     WHY   A company handbook's own instruction is direct: "The majority of information should still be
           in the Handbook which you include links to." A vendor's checklist names both as reducing
           confusion, "linked resource, or named contact can reduce confusion". A practitioner's checklist
           adds the other half:
           "Let people know when you will update them again." Deep dive:
           announcement-internal-comms_companion.md section 3 (Anatomy > Where to Learn More).
     ASK   Which upstream artifact carries the full detail: the PRD, the launch checklist, the release
           notes? Who is the one named person to ask? When does the next update come, even if it is only
           "when stage two opens"?
     GOOD  "Full detail: the payments PRD and the release notes entry. Set-up guide: Paying by direct
           debit. Questions: the payments team's support channel. Next update: when existing customers are
           switched on, or by 17 March, whichever comes first."
     WEAK  Restating the PRD's requirements or the release notes' change list here instead of linking to
           them, so this document can drift out of step with the record it is supposed to summarize.
     TRAP  A link with no named contact. A vendor's own guidance treats the two as a pair, "linked
           resource, or named contact can reduce confusion", not as substitutes for each other. -->


{{source_of_truth_links}}


**Questions:** {{named_contact}}


**Next update:** {{next_update_date}}

Provenance

Section titled “Provenance”

The reasoning, the history and every source, in the repository:

  • Companion - the long-form argument: why these sections, where the sources disagree, and what the bundle refuses to claim
  • History - what changed in this bundle, and when
  • Research log - every source consulted, with what each one actually supports
  • Catalog metadata - the machine-readable record this page is generated from

Catalog record: 6 sections across 1 format(s), methodology methodology-agnostic, typically owned by PM / PMM.