El Traductor de Mensajes Multi-Audience: Una Actualización, Tres Versiones para Ejecutivos, Colegas y Tu Equipo
Por qué importa este prompt
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.
Para qué lo usamos
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]
Resultado
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 misma actualización de estado suele tener que llegar a tres audiencias distintas, y la mayoría de la gente lo maneja enviando una versión genérica a todos o reescribiéndola manualmente tres veces bajo presión de tiempo — justo cuando se omite el detalle más importante. Un ejecutivo que hojea una explicación técnica de dos párrafos se pierde el único número que importaba. Un equipo colega que lee un resumen ejecutivo no obtiene el detalle de dependencia específico que necesitaba para planificar. Y un reporte directo que lee un discurso corporativo se va sin saber qué cambia realmente para ellos el lunes.
Este prompt resuelve la versión más compleja de ese problema: no te deja escribir tres mensajes no relacionados, obliga a que las tres versiones se originen a partir de las mismas notas en bruto y conserven todos los hechos materiales — incluidos los que empeoran la actualización. Esa restricción importa más de lo que parece. Es tentador suavizar la versión ejecutiva omitiendo una advertencia o un riesgo que complique la narrativa limpia de la versión para colegas. El prompt lo bloquea explícitamente: los hechos materiales, especialmente los desfavorables, deben sobrevivir a la traducción a cada versión, solo filtrados por relevancia y expresados en la altitud técnica adecuada para ese lector.
La sección de Flagged Assumptions al final es la parte que la mayoría salta cuando escribe este tipo de prompt por su cuenta, y es la que evita el mayor daño. Cualquier modelo de AI al que se le pida completar un mensaje de tono profesional inventará tranquilamente detalles verosímiles — un nombre, una fecha, una cifra en dólares — si las notas fuente no lo especifican. Forzar esas inferencias a una lista visible y separada significa que detectas una suposición incorrecta antes de que salga en un correo para tu VP, y no después de que ya se haya enviado.