Stakeholder Briefings

Quick facts

Classification: Foundation | Version: 1.0.0 | Category: communication | License: Apache-2.0

Try it: /pm-skills:foundation-stakeholder-briefings "Your context here"

A stakeholder-briefings artifact takes one source (a PRD, a discovery synthesis, a research report, a GTM or launch plan, experiment results, a retro or incident write-up, or raw notes) and produces a single saveable file containing:

1. a master document: the canonical, audience-neutral synthesis of the work (what and why, decisions, status, risks and open questions, asks, timeline), with each claim numbered (M1, M2, …); and
2. a set of audience briefings: the same content re-pitched for each chosen stakeholder, one self-contained, copy-paste-ready block per audience.

The skill runs master-first, then projects. The master is the single source of truth; every briefing is a projection of it. A briefing may omit, reorder, and translate master content, but it may never assert a claim that is not in the master. That projection rule is what keeps the executive version and the engineering version from quietly disagreeing, and it is the difference between this skill and asking a model to “rewrite this six ways.”

Distinct from foundation-stakeholder-update (one async update of meeting outcomes for a single audience, meeting-bound), discover-stakeholder-summary (a map of who stakeholders are and their influence/interest), and foundation-persona (a customer/buyer viewpoint to design or market against).

When to Use

• One piece of work must reach several audiences who each need a different framing, decision, and level of detail (a spec going to engineering, design, data, and the funder at once).
• You are about to manually rewrite the same update three to five ways, one per audience.
• A decision or result needs to propagate across functions without the versions drifting apart.
• A single audience needs a tailored briefing from a non-meeting source (N=1 is supported; the fan-out is the signature use, not a floor).

When NOT to Use

• One async update of meeting outcomes for stakeholders. Use foundation-stakeholder-update (it is meeting-bound; that is its scope).
• Understanding or mapping stakeholders (influence, interest, comms plan). Use discover-stakeholder-summary.
• A persona to design or market against. Use foundation-persona.
• There is no source content yet. This skill projects an existing artifact; it does not do the underlying analysis.

How to Use

Invoke the skill by name (/pm-skills:foundation-stakeholder-briefings on Claude Code, $foundation-stakeholder-briefings on Codex):

/pm-skills:foundation-stakeholder-briefings "Your context here"

Or reference the skill file directly: skills/foundation-stakeholder-briefings/SKILL.md

Instructions

When asked to create stakeholder briefings, follow these steps:

1. Ingest and classify the source. Read the provided artifact. Classify its type (spec/PRD, discovery/research, GTM/launch, strategy/roadmap, experiment/metrics, incident/retro, compliance/privacy/security, or raw/ambiguous). If the source is thin, continue but set input_quality: low and name the gap.

2. Build the master. Write the audience-neutral canonical document with these sections: What and Why, Decisions, Status, Risks and Open Questions, Asks, Timeline. Number every load-bearing claim with a stable ID (M1, M2, …). The master carries no audience-specific spin; it is the shared substrate.

3. Propose the audiences. From the source type, propose the relevant subset using references/source-type-map.md (for example, a spec proposes Engineering, UX/Design, Data/BI, Executive; a GTM plan proposes PMM, Sales, CS/Support, Executive). Present the proposal and accept go (generate the proposed set), an edit (drop X, add Y), or all (all nine). If invoked with --go, skip the prompt and generate the proposal. No audience is ever locked out.

4. Project each briefing. For each chosen lens (see references/audience-lenses.md), render a self-contained block delimited by --- BEGIN: <lens> --- / --- END ---, containing:

   • Draws on: the master claim IDs this briefing projects (required).
   • Primary ask: exactly one decision or action for this audience (required).
   • a one-line headline, a “what this means for you” framing, and the body, at the lens’s length, vocabulary, and tone. Every load-bearing line must trace to a master claim. Do not introduce a claim that is not in the master.

5. Flag translations. Keep a translations-applied log (internal, below the shareable boundary) for every technical-to-business or inferred re-pitch, so the user can verify it lands. This section is never part of a shareable briefing.

6. Self-check the invariant before finalizing:

   • Trace references resolve (deterministic, checkable): every briefing Draws on: ID resolves to a real master claim.
   • One CTA (deterministic, checkable): exactly one Primary ask: per block.
   • No untraced claim (review): re-read each block against its Draws on: set and confirm the body introduces nothing absent from those master claims. This is a review step, not automated.
   • Neutral master (review): the master has no audience-specific spin. List anything that fails.

7. Render the artifact. Master (with claim IDs) -> the delimited briefing blocks -> the boundary marker -> the translations-applied log -> Sources and References. Remove all guidance blockquotes from the final output.

Output Template

Stakeholder briefings: {{title}}

Master document

[The canonical, audience-neutral synthesis. Number every load-bearing claim M1, M2, … Briefings reference these IDs. No audience-specific spin here.]

What and why

• {{M1: one-line claim}}
• {{M2: one-line claim}}

Decisions

• {{M3: decision}}

Status

• {{M4: where the work stands}}

Risks and open questions

• {{M5: risk or open question}}

Asks

• {{M6: what is needed, from whom}}

Timeline

• {{M7: key dates / sequence}}

---

Briefings

[One self-contained block per chosen audience. Each block: Draws on (master IDs), Primary ask (exactly one), headline, what-this-means-for-you, body. Every load-bearing line traces to a master claim. Copy a block out as-is to send it.]

--- BEGIN: {{lens, e.g. Executive}} ---

Draws on: {{M1, M3, M6}} Primary ask: {{the single decision or action this audience owns}}

{{Headline: one skimmable line for this audience}}

What this means for {{audience}}

{{2-5 sentences re-pitched to this lens: the decision they own, what they care about, their vocabulary, at the right length and tone.}}

{{Body bullets as needed, all tracing to master claim IDs.}}

--- END ---

--- BEGIN: {{next lens}} ---

Draws on: {{IDs}} Primary ask: {{single ask}}

{{Headline}}

What this means for {{audience}}

{{…}}

--- END ---

---

[End of shareable briefings. Everything below is INTERNAL. Do not copy into an outgoing briefing.]

Translations applied (internal)

[Include when any technical-to-business or inferred re-pitch was made, so the user can verify it lands.]

• “{{technical term}}” -> “{{plain language}}” (audience: {{lens}})
• “{{acronym}}” -> “{{expansion}}”

Flagged but kept (may need review):

• “{{term}}” - {{why it was kept and where it might not land}}

Sources and References

• Source artifact: {{source_ref}}
• {{Any external references cited in the master, public links only}}
• Generated: {{timestamp}} | Skill version: 1.0.0 | Audiences: {{list}} | Input quality: {{high|medium|low}} ({{rationale}})
• Invariant self-check: {{N briefings, all Draws-on IDs resolve; one Primary ask each; neutral-master reviewed}}

Example Output

Example: stakeholder briefings from a PRD

A worked case showing the master-first projection: one PRD fanned out into four audience briefings. Source: a fictional B2B ecommerce platform shipping a built-in Campaigns (email/SMS) feature. All metrics are [fictional].

Prompt

/foundation-stakeholder-briefings @campaigns-prd.md
(skill proposes Engineering, UX/Design, Data/BI, Executive for a spec; user adds Legal for CAN-SPAM)

Output

# Stakeholder briefings: Campaigns (built-in email/SMS)

## Master document

**What and why**

- M1: Campaigns adds native email/SMS re-engagement to the platform so merchants stop stitching on third-party tools (Klaviyo, Mailchimp).
- M2: Target is the ~68% of merchants [fictional] who currently pay for an external email tool.

**Decisions**

- M3: v1 ships template-only sending (no drag-and-drop builder); CAN-SPAM one-click unsubscribe is in scope.
- M4: Deliverability runs on a dedicated-IP provider with domain warm-up.

**Status**

- M5: Engineering build is ~60% complete [fictional]; the sending pipeline and template gallery are done, analytics is not.
- M10: Success is measured by adoption among external-tool merchants plus deliverability health; this needs campaign-event instrumentation (created, sent, delivered, opened, clicked, unsubscribed) and an adoption/deliverability dashboard, both part of the unfinished analytics work.

**Risks and open questions**

- M6: Deliverability reputation on cold domains is the top risk; warm-up adds ~2 weeks to the timeline.
- M7: CAN-SPAM and GDPR consent handling needs legal sign-off before GA.

**Asks**

- M8: GA go/no-go decision at the 2026-07-15 review.

**Timeline**

- M9: Beta 2026-06-30; GA target 2026-07-20.

## Briefings

--- BEGIN: Executive ---

**Draws on:** M1, M2, M6, M8, M9
**Primary ask:** Approve GA go/no-go at the 2026-07-15 review.

**Campaigns is on track for a 2026-07-20 GA; one risk to watch**

**What this means for the Executive sponsor**

Campaigns lets merchants run email/SMS in-platform instead of paying for Klaviyo or Mailchimp, aimed at the ~68% [fictional] who use an external tool today. Build is on track for a 2026-07-20 GA. The one material risk is email deliverability on cold domains, which the warm-up plan addresses but which adds about two weeks. Decision needed from you: GA go/no-go at the 2026-07-15 review.

--- END ---

--- BEGIN: Engineering ---

**Draws on:** M3, M4, M5, M6
**Primary ask:** Confirm the dedicated-IP warm-up schedule lands before the 2026-06-30 beta.

**Template-only v1; deliverability warm-up is the critical path**

**What this means for Engineering**

v1 is template-only sending (no drag-and-drop) with CAN-SPAM one-click unsubscribe. Sending runs on a dedicated-IP provider with domain warm-up; the pipeline and template gallery are done (~60% overall [fictional]), analytics is not. The critical path is deliverability warm-up on cold domains. Confirm the warm-up schedule completes before the 2026-06-30 beta so reputation is established at launch.

--- END ---

--- BEGIN: Data/BI ---

**Draws on:** M2, M5, M10
**Primary ask:** Stand up the adoption + deliverability dashboard before beta so v1 is measurable.

**Analytics is the open build item; we need adoption + deliverability instrumented**

**What this means for the Data team**

The success measure for Campaigns is adoption among the ~68% [fictional] of merchants on external tools, plus deliverability health. Analytics is the one build item not yet done. We need event instrumentation (campaign_created, send_completed, delivered, opened, clicked, unsubscribed) and a dashboard covering adoption and deliverability before the 2026-06-30 beta, or v1 ships blind.

--- END ---

--- BEGIN: Legal ---

**Draws on:** M3, M7
**Primary ask:** Sign off on CAN-SPAM + GDPR consent handling before the 2026-07-15 GA review.

**Consent and unsubscribe handling needs legal sign-off before GA**

**What this means for Legal**

Campaigns sends commercial email/SMS, so it carries CAN-SPAM and GDPR obligations: one-click unsubscribe (in scope for v1) and lawful consent capture. We need your sign-off on the consent flow and unsubscribe handling before the 2026-07-15 GA review, since GA cannot proceed without it.

--- END ---

---

## Translations applied (internal)

- "dedicated-IP warm-up" kept as-is for Engineering; rendered as "deliverability reputation risk" for the Executive block (audience: Executive).
- "CAN-SPAM / GDPR" kept precise for Legal; rendered as "consent handling needs legal sign-off" for Executive.

## Sources and References

- Source artifact: campaigns-prd.md [fictional]
- **Generated:** 2026-06-20T17:00:00Z | **Skill version:** 1.0.0 | **Audiences:** Executive, Engineering, Data/BI, Legal | **Input quality:** high
- **Invariant self-check:** 4 briefings; all Draws-on IDs resolve to M1-M9; one Primary ask each; master reviewed as audience-neutral.

Real-World Examples

See this skill applied to three different product contexts:

Storevine (B2B): Storevine B2B ecommerce platform - 8-merchant interview synthesis fanned out to four lenses, driving the template-first scope decision

Prompt:

/foundation-stakeholder-briefings @campaigns-merchant-interviews.md

Source: 8-merchant interview synthesis on email tooling. Key findings:
~68% of merchants use an external email tool and resent juggling two systems
("tool-juggling tax"); the blank-canvas setup is where merchants stall on their
first send; merchants want "good enough fast," not maximum flexibility; the data
they want for targeting (orders, customers) already lives in Storevine; switching
cost off Klaviyo (lists, history) is the main thing holding adopters back.

Audiences: take the discovery proposal (UX/Design, PMM, Executive, Engineering).

Output:

# Stakeholder briefings: Campaigns merchant interview synthesis

</details>

<details>
<summary>Brainshelf (Consumer): Brainshelf consumer PKM app - the guilt-pile interview synthesis (why users save but never return) fanned out to design, product-marketing, and executive lenses to align before scoping a solution</summary>

**Prompt:**

/foundation-stakeholder-briefings @guilt-pile-synthesis.md

guilt pile interviews (n=7) are synthesized. want to socialize before we scope anything. need design + pmm + marco versions. don’t oversell, it’s 7 people. go

**Output:**

```markdown
# Stakeholder briefings: The "guilt pile" - why users save but don't return

</details>

<details>
<summary>Workbench (Enterprise): Workbench enterprise collaboration platform - standalone HIPAA and data-handling compliance review for Blueprints projected to four lenses</summary>

**Prompt:**

/foundation-stakeholder-briefings @blueprints-hipaa-review.md

Source: standalone HIPAA + data-handling compliance review of Blueprints (compliance/privacy/security). This is NOT a launch or a spec - it is a gap-finding review run ahead of selling into regulated healthcare ops teams.

Findings [fictional]:

1. PHI exposure in the CRDT layer: Blueprint content (incl. potential PHI) is stored as opaque Yjs binary; we have no redaction or selective-deletion path inside the co-editing document. Severity: high.
2. Audit-log retention: current retention is 12 months; HIPAA-aligned customers expect 6 years for access logs. Severity: medium.
3. No BAA: there is no Business Associate Agreement template ready; we cannot contractually take on PHI today. Severity: high (hard blocker for healthcare).

No incident has occurred; this is preventive. Remediation owners would be Karen L. (Eng) and Legal. Decision: is HIPAA readiness in scope for this cycle, or do we gate healthcare deals until a later cycle? Owned by Sandra C. (Head of Product). Audiences: take the compliance proposal (Legal, Engineering, Executive, CS/Support).

**Output:**

```markdown
# Stakeholder briefings: Blueprints HIPAA + data-handling review

</details>

## Quality Checklist

- [ ] Master present with numbered claim IDs (`M1`, `M2`, ...) and no audience-specific spin.
- [ ] Each briefing block has a `Draws on:` line whose IDs all resolve to master claims.
- [ ] Each briefing block has exactly one `Primary ask:`.
- [ ] No briefing asserts a claim absent from the master (projection rule).
- [ ] Audience set matches the source-type proposal or the user's edit; N=1 honored without refusal.
- [ ] Translations-applied log present (internal) when any translation was made; boundary marker separates shareable blocks from internal sections.
- [ ] Each briefing is at the lens's length and tone (a board block reads nothing like an engineering block).
- [ ] Guidance blockquotes removed from the final artifact.