Der Überbringer schlechter Nachrichten: Unerwünschte Updates verfassen, ohne das Vertrauen zu verlieren
Warum dieser Prompt wichtig ist
How a setback is communicated changes customer and employee retention more than the severity of the setback itself. A vague, hedge-filled message about a delay reads as a signal that something worse is being hidden, which is what actually pushes clients to start quietly evaluating alternatives — even when the underlying relationship was healthy going in. Internally, a rambling, defensive layoff or cancellation announcement is the version of the message that gets forwarded, screenshotted, and remembered for years after the actual decision is forgotten.
Wofür wir ihn verwenden
You are a product manager who just learned that the client-facing integration promised for Q1 is being pushed to Q3, because the two engineers who were building it got reassigned last week to an urgent security patch. You have to tell the client's VP of Operations today, by email, before she hears about the delay secondhand from your account executive during tomorrow's renewal call.
Prompt
You are a seasoned [SENIOR MANAGER / INTERNAL COMMUNICATIONS LEAD / TEAM LEAD] who has delivered hundreds of difficult updates — project delays, budget cuts, canceled initiatives, negative decisions — without losing the trust of the people receiving them. CONTEXT: - What happened: [DESCRIBE THE SITUATION PLAINLY — what changed, why, what you already tried before it got to this point] - Who is affected: [DESCRIBE THE AUDIENCE, e.g., "my 6-person engineering team," "an enterprise client who pays for priority support," "the whole company, ~200 people"] - Relationship context: [DESCRIBE THE CURRENT STATE OF TRUST, e.g., "generally strong, this is our first real setback together" or "already strained from a missed deadline last quarter"] TASK — complete all three steps, in order, without skipping the self-critique: Step 1 — DRAFT. Write the message delivering this news. Lead with the actual news in the first two sentences — do not bury it under context or preamble. State the concrete impact on the reader before explaining the cause. Include one specific, concrete next step or remedy, even if the remedy is only partial. Step 2 — SELF-CRITIQUE. Now switch roles. Read your own Step 1 draft as the most skeptical, least charitable person who could receive it. List every sentence that could read as evasive, overly corporate, defensive, or like it is minimizing the problem. Flag any place where the lede was buried or excuses were front-loaded before the actual news. Be specific about which words or phrases trigger each flag — do not just say "tone could be better." Step 3 — REVISE. Produce a final version that fixes every issue flagged in Step 2. Do not introduce new hedging while fixing the old hedging. CONSTRAINTS: - No corporate hedge language: ban phrases like "due to unforeseen circumstances," "moving forward," "we take this seriously," "at this time" - Name the actual cause plainly, even if it is an internal mistake - Apologize at most once, and only if someone on our side is actually at fault - Maximum 2 sentences before the core news is stated - Match this tone/formality: [E.G., "casual Slack message to my own team" OR "formal email to an enterprise client's VP"] - Target length: [E.G., "under 150 words" OR "under 300 words"] OUTPUT FORMAT: 1. Draft v1 (the message) 2. Self-Critique (bulleted list, each bullet quoting the exact flawed phrase and naming the specific problem) 3. Final Revised Version (ready to send as-is)
Ergebnis
Draft v1:
Subject: Integration Delay — Moving From Q1 to Q3
Hi Sarah,
I need to tell you that the client integration we committed to for Q1 is now going to ship in Q3 instead. Due to an unexpected shift in our engineering priorities, the two engineers assigned to your integration were moved onto a critical security patch last week, and we don't expect to have resources back on your project until April.
We understand this is frustrating and we take this delay seriously. We want to assure you that we remain fully committed to delivering a high-quality integration, and we will keep you updated as things progress. Please let us know if you have any questions, and thank you for your continued patience and partnership.
Best,
[Name]
Self-Critique:
- «Due to an unexpected shift in our engineering priorities» — this is a vague corporate hedge. It never names the actual cause (a security patch pulled the engineers away). Reads as evasive.
- «we take this delay seriously» — banned boilerplate phrase. Adds zero information and signals a template response.
- «We want to assure you that we remain fully committed» — generic reassurance with no concrete action attached. Sounds defensive rather than helpful.
- «we will keep you updated as things progress» — no specific date or mechanism given. Reads as a brush-off, not a commitment.
- «thank you for your continued patience and partnership» — the message closes by asking the client for patience instead of ending on a concrete remedy. This minimizes the real inconvenience to her Q1 plans.
- The actual news (Q1 to Q3) is stated but delayed by «I need to tell you that» throat-clearing — tighten the opening.
- No interim remedy is offered anywhere — the message describes the problem but gives Sarah nothing she can use in the meantime.
Final Revised Version:
Subject: Integration Delay — Moving From Q1 to Q3
Hi Sarah,
Your integration is moving from Q1 to Q3. The two engineers assigned to it were pulled last week onto an urgent security patch for existing customers, and that patch takes priority through April.
I know this affects your own Q1 commitments to your team, so here's what we can do in the meantime: I can get you a working sandbox build of the current integration state by January 15, so your team can start testing against it even though the full release waits until Q3. I'll also set up a bi-weekly 15-minute check-in starting next week so you're not waiting until Q3 to hear anything.
I'm sorry for the disruption this causes on your side — happy to get on a call today if that's more useful than email.
[Name]
Die meisten Ratschläge zum Überbringen schlechter Nachrichten konzentrieren sich auf den Ton — seien Sie einfühlsam, seien Sie klar, seien Sie freundlich. Dieser Rat ist richtig und zugleich für sich allein nutzlos, weil die Menschen, die diese Nachrichten schreiben, bereits wissen, dass sie einfühlsam und klar klingen sollten. Was eine schwierige Nachricht tatsächlich entgleisen lässt, ist eine konkrete, benennbare Sprache: die Ausweichformulierung, die sich einschleicht, weil sie sich sicherer anfühlt, die Ausrede, die vor die eigentliche Nachricht gesetzt wird, das vage Versprechen, «Sie auf dem Laufenden zu halten», das zu nichts verpflichtet. Dieser Prompt ist darauf ausgelegt, genau diese spezifischen Fehler zu erkennen, statt allgemeine Ratschläge zum Ton zu geben.
Warum es den Selbstkritik-Schritt gibt
Die meisten KI-Schreibprompts hören auf, nachdem ein Entwurf entstanden ist. Dieser erzwingt einen zweiten Durchgang, in dem das Modell seine eigene Ausgabe wie der skeptischste mögliche Empfänger lesen und schriftlich jede Formulierung benennen muss, die diesen Empfänger weniger vertrauen lassen würde. Das funktioniert, weil ein KI-Modell, das eine Nachricht verfasst, und ein KI-Modell, das eine Nachricht kritisiert, funktional unterschiedliche Bewertungskriterien anwenden — der Entwurfsdurchgang optimiert dafür, «professionell und vollständig zu klingen», während der Kritikdurchgang dafür optimiert, «ob ein skeptischer Leser dies glauben würde». Diese beiden Kriterien stehen oft im Widerspruch, und genau die unternehmerische Ausweichsprache erfüllt das erste, während sie am zweiten scheitert.
Warum die Einschränkungen konkrete Formulierungen verbieten statt allgemeiner Hinweise
«Aufgrund unvorhergesehener Umstände», «wir nehmen das sehr ernst» und «im weiteren Verlauf» sind namentlich verboten statt kategorisch, weil Modelle (und Menschen) zuverlässig genau zu diesen Formulierungen greifen, wenn sie aufgefordert werden, etwas Schwieriges zu schreiben — es sind die tragenden Klischees schlechter Unternehmensnachrichten. Sie namentlich zu verbieten, zwingt das Modell, die tatsächlichen Worte für das Geschehene zu finden, was meist ehrlicher und konkreter ist als die Ausflucht, die es ersetzt.
Warum useCase und whyItMatters getrennt bleiben
Der Anwendungsfall beschreibt ein einziges konkretes Szenario — eine bestimmte Verzögerung, einen bestimmten Stakeholder, einen bestimmten Termindruck. Das Argument «warum es wichtig ist» betrifft die nachgelagerten Kosten, dies im Allgemeinen falsch zu machen: beschädigtes Vertrauen summiert sich lautlos, und ein schlecht gehandhabter Rückschlag verursacht oft mehr Abwanderung als der Rückschlag selbst. Diese beiden getrennt zu halten, ist bewusst — ein Leser sollte seine eigene Situation im Anwendungsfall erkennen können, während er über das zweite Feld versteht, was auf dem Spiel steht, ohne dass sich beide wiederholen.
Wie man ihn anpasst
Die drei Felder in Klammern — Rolle, Kontext und Zielgruppe — reichen aus, um diesen Prompt für fast jede schwierige berufliche Nachricht einzusetzen: eine verpasste Frist, eine Budgetkürzung, ein abgesagtes Projekt, eine negative Leistungsbeurteilung, sogar eine persönliche Entschuldigung, die konkret statt allgemein bleiben muss. Die Struktur (Entwurf, dann skeptische Selbstkritik, dann Überarbeitung) ist der wiederverwendbare Teil; der Inhalt ist das Schwierige, das Sie diese Woche tatsächlich sagen müssen.