The Multi-Audience Message Translator: One Update, Three Versions for Execs, Peers, and Your Team
Why this prompt matters
Miscalibrated communication is one of the most common and costly leadership failures: send peer-level technical detail to an executive and the one number they needed gets buried in three paragraphs of jargon; send the executive-level summary to your own team and they're left without the specifics they need to actually change what they're doing this week. The failure mode isn't that information wasn't sent — it's that it arrived at the wrong altitude, which forces a second round of clarifying messages, meetings, and erodes trust when the details that were technically disclosed still feel like a surprise later.
What we use it for
A sprint retro just wrapped and you have five bullet points of raw notes: the payment vendor changed their API without notice, the auth integration slipped two weeks, there's no budget impact, and two engineers need to be reassigned starting today. You have 20 minutes before your next meeting to tell your VP, your peer team lead, and your own team — and each of them needs a completely different version of the same facts.
Prompt
Role: Act as an executive communications coach who specializes in helping technical and operational leaders adapt one core update for different audiences without changing the underlying facts. Context: I need to communicate one update to three different audiences who each need a different altitude of detail and a different call to action. Here is the raw update: [PASTE YOUR RAW UPDATE OR NOTES HERE] The three audiences are: 1. [EXECUTIVE AUDIENCE — e.g., "VP of Engineering, cares about timeline and budget impact"] 2. [PEER AUDIENCE — e.g., "fellow team leads, need technical detail and cross-team dependencies"] 3. [DIRECT REPORT AUDIENCE — e.g., "my team, needs to know what changes for them this week"] Task: Produce three versions of this update, one for each audience above. Each version must: - Lead with the single most relevant fact for that audience in the first sentence - Use vocabulary and detail level appropriate to that audience's role - End with a clear "what I need from you" or "what happens next" line - Preserve every material fact from the original notes — do not omit risks, delays, or costs to make any version sound better than the facts support Constraints: - Do not invent details not present in [PASTE YOUR RAW UPDATE OR NOTES HERE] - Keep the executive version under 150 words - Keep the peer version under 250 words, including any technical specifics that matter for their planning - Keep the direct-report version conversational, not corporate — write it the way you'd actually talk to your team - Flag explicitly (in brackets) any place where you had to infer missing context, so I can correct it before sending - Do not use hedge-phrase openers like "just wanted to check in" or "quick update" Output Format: ## Executive Version [150 words max] ## Peer Version [250 words max] ## Direct Report Version [conversational, no strict word limit] ## Flagged Assumptions [bullet list of anything you inferred rather than found in the source notes]
Result
Executive Version
The auth integration is delayed two weeks due to an unannounced breaking change in our payment vendor's API — not a scope or execution issue on our side. No budget impact; we're absorbing the delay within the current sprint buffer. Revised ship date: August 13. I need your sign-off to communicate the new date externally by end of day Friday.
Peer Version
Heads up for anything that depends on the auth service: our payment vendor deprecated the webhook signature method we were using without a deprecation notice reaching us in time, so we're mid-rewrite of the signature verification layer. This pushes our auth integration ship date from July 30 to August 13. If your team has anything gated on our auth endpoints being stable, plan around August 13, not July 30. The webhook payload shape isn't changing, only the internal verification method, so no action needed on your side unless you're calling our endpoints directly during the transition window — in which case ping me and we'll coordinate a freeze window.
Direct Report Version
Quick context on why priorities shift this week: our payment vendor changed how webhook signatures work and didn't give us enough notice, so the auth rewrite we thought was basically done needs another pass on the verification layer. That's a two-week slip, not because anyone dropped the ball, but because the ground moved under us. [NAME] and [NAME], I need you focused on the signature verification rewrite starting today — I'll move the dashboard polish work to next sprint to make room. Nobody's weekend plans should change; this is a reprioritization, not a crunch.
Flagged Assumptions
- Assumed the delay has genuinely zero budget impact — confirm before sending the executive version
- Assumed [NAME] and [NAME] are the right two engineers to reassign — adjust if wrong
- Assumed August 13 is achievable — verify with the team before committing that date externally
The same status update usually needs to reach three different audiences, and most people handle that by either sending one generic version to everyone or manually rewriting it three times under time pressure — which is exactly when the most consequential detail gets left out. An executive skimming a two-paragraph technical explanation misses the one number that mattered. A peer team reading an executive summary doesn't get the specific dependency detail they needed to plan around. And a direct report reading corporate-speak walks away without knowing what actually changes for them on Monday.
This prompt solves the harder version of that problem: it doesn't let you write three unrelated messages, it forces all three versions to originate from the same raw notes and preserve every material fact — including the parts that make the update worse. That constraint matters more than it sounds. It's tempting to soften the executive version by quietly dropping a caveat or omitting a risk that complicates the peer version's clean narrative. The prompt explicitly blocks that: material facts, especially unfavorable ones, have to survive translation into every version, just filtered by relevance and expressed at the right technical altitude for that reader.
The Flagged Assumptions section at the end is the part most people skip when they write this kind of prompt themselves, and it's the part that prevents the most damage. Any AI model asked to fill in a professional-sounding message will quietly invent plausible details — a name, a date, a dollar figure — if the source notes don't specify one. Forcing those inferences into a visible, separate list means you catch a wrong guess before it goes out in an email to your VP, instead of after it's already been sent.