The Multi-Audience Message Translator : une mise à jour, trois versions pour Execs, pairs et votre équipe
Pourquoi ce prompt est important
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.
À quoi nous l'utilisons
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]
Résultat
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
La même mise à jour de statut doit généralement atteindre trois publics différents, et la plupart des gens gèrent ça en envoyant soit une version générique à tout le monde, soit en la réécrivant manuellement trois fois sous pression — ce qui est précisément le moment où le détail le plus important passe à la trappe. Un executive qui parcourt une explication technique de deux paragraphes rate le seul chiffre qui comptait. Une équipe qui lit un résumé pour décideurs ne voit pas le détail de dépendance dont elle avait besoin pour planifier. Et un collaborateur qui lit du jargon corporate repart sans savoir ce qui change concrètement pour lui lundi.
Ce prompt résout la version difficile du problème : il ne vous laisse pas écrire trois messages sans lien, il force les trois versions à partir des mêmes notes brutes et à conserver chaque fait matériel — y compris les parties qui rendent la mise à jour moins flatteuse. Cette contrainte est plus importante qu'il n'y paraît. Il est tentant d'adoucir la version executive en omettant discrètement une réserve ou en écartant un risque qui complique le récit propre de la version pour l'équipe. Le prompt l'interdit explicitement : les faits matériels, surtout les défavorables, doivent survivre à la traduction dans chaque version, simplement filtrés par pertinence et exprimés à la bonne altitude technique pour ce lecteur.
La section « Flagged Assumptions » à la fin est la partie que la plupart des gens sautent quand ils écrivent ce genre de prompt eux-mêmes, et c'est celle qui évite le plus de dégâts. Tout modèle d'IA à qui on demande de remplir un message professionnel va tranquillement inventer des détails plausibles — un nom, une date, un montant — si les notes sources ne les précisent pas. Forcer ces inférences dans une liste visible et séparée permet de repérer une supposition erronée avant qu'elle parte dans un email à votre VP, au lieu de la découvrir après envoi.