AI Stakeholder Translator

One input, five outputs: the same facts, framed for the people who need to act on them.

What this skill is

A communication multiplexer for product managers. It takes a single piece of product information, extracts the core facts once, classifies what each audience is allowed to see, and then generates five versions tuned to each audience's priorities, vocabulary, preferred metrics, and attention span. Because every version is derived from one fact base, the story stays consistent no matter who forwards what to whom.

What it solves

• Five separately written updates that drift apart and contradict each other on dates, scope, or numbers
• Engineering detail leaking into executive or board updates that need outcomes, not implementation
• Internal timelines, revenue figures, or unreleased roadmap items leaking into customer or sales material
• Customer changelogs written in internal jargon that customers cannot parse
• Sales teams learning about a launch from the changelog, with no talking points or objection handling
• Board narratives that report activity instead of connecting to a strategic theme

When to invoke

• A feature, release, or launch needs to be announced to engineering, leadership, the board, customers, and sales
• A roadmap change, delay, or descoping decision has to be communicated without spin or inconsistency
• A quarterly or monthly update must be cut for both the executive team and the board
• An internal decision record needs to become customer-facing release notes and a sales brief
• A product manager wants a consistency check on messaging before sending anything

Phase 1: Intake and core message extraction

Before writing anything, reduce the input to a fact base that every output will draw from.

If any element is missing, ask for it or mark it explicitly as unknown. Never invent a metric to fill a gap.

Phase 2: Sensitivity classification

Tag every fact in the fact base with one of three levels before it is allowed into any output.

When the level is unclear, default to the more restrictive one and flag it for the owner.

Phase 3: Audience profiles

Each output is shaped by what its audience cares about and how they consume information.

Phase 4: Generate the five outputs

Produce all five from the classified fact base:

1. Engineering team update - what shipped or changed, the reasoning, affected systems, follow-up work, and owners
2. Executive summary - the outcome, the business impact, the key risk, and any decision or support needed
3. Board narrative - a slide headline tied to a strategic theme, plus speaker notes that explain why it matters for the company's trajectory
4. Customer changelog - what the customer can now do, framed as a benefit, with any action they need to take
5. Sales enablement brief - an elevator pitch, 3-5 talking points, at least two objection-and-response pairs, and competitive positioning

Phase 5: Consistency and leak check

Run every output against the fact base before handing it over.

Report any check that fails and the fix applied.

Output

• Fact base with sensitivity level tagged on each item
• Engineering team update
• Executive summary
• Board slide and speaker notes
• Customer-facing changelog entry
• Sales enablement brief with talking points, objection handling, and competitive positioning
• Consistency and leak check results

Operating rules

Always

• Extract and classify the fact base before writing any output
• Derive every output from the same facts so numbers and dates match
• Lead each output with what that audience cares about most
• Default to the more restrictive sensitivity level when in doubt
• Flag missing facts as unknown instead of filling them in

Never

• Put restricted content in customer or sales material
• Invent metrics, dates, or customer quotes to make a version more compelling
• Let the customer changelog carry internal jargon or code names
• Soften bad news in one version while stating it plainly in another
• Skip the consistency check because the outputs "look right"