pm-communication-patterns

name: pm-communication-patterns description: "Internal skill. Use cc-p4p-router for all PM tasks." allowed-tools: Read, Grep, Glob, AskUserQuestion

PM Communication Patterns

Overview

Expert knowledge for stakeholder communications -- status updates, risk communication, decision documentation, and audience-adapted messaging. Every communication should be tailored to its audience.

The Iron Law

NO COMMUNICATION WITHOUT AUDIENCE IDENTIFICATION AND TONE MATCH

Every communication must name its audience before drafting begins. Tone, format, length, and detail level all flow from audience. Writing without audience is broadcasting noise.

When to Use

• Drafting executive status updates
• Writing engineering team updates
• Preparing cross-functional partner communications
• Writing customer-facing announcements
• Documenting risks using ROAM framework
• Recording decisions using ADR format

Audience Templates

Executive / Leadership

Executives want: Strategic context, progress against goals, risks needing help, decisions needing input.

Status: [Green / Yellow / Red]

TL;DR: [One sentence -- the most important thing to know]

Progress:
- [Outcome achieved, tied to goal/OKR]
- [Milestone reached, with impact]
- [Key metric movement]

Risks:
- [Risk]: [Mitigation plan]. [Ask if needed].

Decisions needed:
- [Decision]: [Options with recommendation]. Need by [date].

Next milestones:
- [Milestone] -- [Date]

Tips:

• Lead with conclusion, not journey. "We shipped X and it moved Y metric."
• Keep under 200 words
• Status color = YOUR genuine assessment. Yellow = good risk management.
• Only include risks you want help with
• Asks must be specific: "Decision on X by Friday" not "support needed"

Engineering Team

Engineers want: Clear priorities, technical context, blockers resolved, decisions affecting their work.

Shipped:
- [Feature/fix] -- [Link]. [Impact if notable].

In progress:
- [Item] -- [Owner]. [Expected completion]. [Blockers].

Decisions:
- [Made]: [Rationale]. [Link to ADR if exists].
- [Needed]: [Context]. [Options]. [Recommendation].

Priority changes:
- [What changed and why]

Coming up:
- [Next items] -- [Why these are next]

Tips:

• Link to tickets, PRs, documents -- engineers click through
• When priorities change, explain why
• Be explicit about blockers and what you're doing to unblock
• Don't waste time with irrelevant info

Cross-Functional Partners

Partners want: What's coming that affects them, what they need to prepare, how to give input.

What's coming:
- [Feature/launch] -- [Date]. [What this means for your team].

What we need from you:
- [Specific ask] -- [Context]. By [date].

Decisions made:
- [Decision] -- [How it affects your team].

Open for input:
- [Topic] -- [How to provide feedback].

Customer / External

Customers want: What's new, what's coming, how it benefits them, how to get started.

What's new:
- [Feature] -- [Benefit in customer terms]. [How to use it].

Coming soon:
- [Feature] -- [Expected timing]. [Why it matters to you].

Known issues:
- [Issue] -- [Status]. [Workaround if available].

Feedback:
- [How to share feedback]

Tips:

• No internal jargon. No ticket numbers. No technical details.
• Frame as what customer can now DO, not what you built
• Be honest about timelines -- "later this quarter" beats a missed date
• Only mention issues if customer-impacting with resolution plan

Tone Mapping Matrix

Status Framework (Green / Yellow / Red)

Rules:

• Move to Yellow at FIRST sign of risk, not when sure things are bad
• Move to Red when you've exhausted own options
• Move back to Green only when risk genuinely resolved
• Document what changed: "Moved to Yellow because [reason]"

Jargon Detection

Internal terms that should NOT appear in customer/external communications:

Rule: Before sending customer comms, scan for internal terms and replace.

ROAM Risk Framework

Risk Communication

1. State clearly: "There is a risk that [thing] happens because [reason]"
2. Quantify impact: "If this happens, the consequence is [impact]"
3. State likelihood: "[likely/possible/unlikely] because [evidence]"
4. Present mitigation: "We are managing this by [actions]"
5. Make the ask: "We need [specific help] to reduce this risk"

Decision Documentation (ADR Format)

Architecture Decision Record -- Adapted for PM

# ADR-[number]: [Decision Title]

## Status
[Proposed / Accepted / Deprecated / Superseded by ADR-X]

## Context
[What is the situation? What forces are at play?]

## Decision
[What did we decide?]

## Options Considered
| Option | Pros | Cons |
|--------|------|------|
| A | ... | ... |
| B | ... | ... |

## Rationale
[Why this option? What tipped the balance?]

## Consequences
- [Expected positive outcomes]
- [Expected negative outcomes or tradeoffs]
- [What we'll monitor]

When to write an ADR: Any decision that is hard to reverse, affects multiple teams, or will be questioned later.

Channel Recommendations

Review Checklist

Before sending ANY communication:

• Audience identified and appropriate
• Tone matches audience expectations
• No jargon leaks (especially in customer comms)
• Actionable -- clear next steps or asks
• Length appropriate for audience
• Status/color justified by evidence (if applicable)
• Links included where relevant
• Reviewed for accuracy against latest data

Red Flags — STOP

• Writing without identifying specific audience → STOP. Who reads this determines everything.
• Internal jargon in customer communications → STOP. Scan and replace before sending.
• Status color (Green/Yellow/Red) without evidence → STOP. Justify every color with facts.
• Communication longer than audience expects → STOP. Exec: <200 words. Customer: <250 words.
• No clear ask or next step → STOP. Every communication needs actionable takeaway.
• Using same format for different audiences → STOP. Exec update ≠ eng update ≠ customer update.

Rationalization Prevention