Verified against ChatGPT · 2026-08-14
Write a stakeholder update that leads with bad news instead of burying it under three paragraphs of good news
Drafts a stakeholder update where anything that could disappoint or surprise the reader comes first and in plain language, with good news kept genuinely proportional instead of used to soften or crowd out the real message.
The prompt
Ready to copy — highlighted parts are example details you can swap.
You are drafting a stakeholder update for me. My honest failure pattern with these is that I lead with the good news to soften the reader up, and by the time I get to the actual bad news three paragraphs later, it reads as buried or reluctant — which damages trust more than just saying it plainly upfront would. RAW UPDATE MATERIAL (good and bad, unsorted) Missed the mid-August integration milestone by a week due to a vendor delay; signed two new pilot customers; team morale is fine; budget is tracking on target. STAKEHOLDER RELATIONSHIP AND HOW MUCH DIRECTNESS IS APPROPRIATE Board member, expects direct plain-language updates, no patience for spin. WHAT SPECIFICALLY CHANGED SINCE THE LAST UPDATE Last update we hadn't yet identified the vendor delay; this cycle we have, plus the two new pilot signings are new. ANY ASK OR RESPONSE YOU NEED FROM THEM Need their sign-off on a one-week extension to the public launch date. Sort the raw material into what's actually bad news (missed a deadline, cost more, a risk materialized), what's neutral status, and what's genuinely good news. Open the update with the bad news, if there is any, stated in plain declarative language — not softened with qualifiers like "slightly behind" when the notes describe something more serious, and not preceded by good news used as a cushion. If there's no real bad news this cycle, say that plainly as the opening line instead of manufacturing false urgency. For each piece of bad news, include what caused it and what's being done about it in the same breath, not as a separate section the reader has to hunt for — bad news without a stated response reads as an admission with no plan. Only after the bad news is fully stated, include neutral status and genuine good news, kept proportional to its actual significance rather than inflated to balance out the earlier bad news — a small win described with the same enthusiasm as a major one erodes credibility over time. Clearly separate what changed since the last update from unchanged background context, since a stakeholder reading multiple updates over time needs to know what's actually new this cycle, not a full restatement of everything they've already heard before. Close with the specific ask or response needed, stated plainly. WHAT NOT TO DO Do not use a euphemism to describe a real problem. Do not open with an apology in place of a clear statement of what happened. OUTPUT FORMAT An update: bad news first (or explicit "no bad news this cycle"), cause and response together, then proportional good/neutral news, what's new since last time, closing ask.
Customize
Optional — swap in your own details for the highlighted parts above.
Why this works
The instinct to lead with good news before delivering bad news is a natural social softening move, but it's precisely the pattern that erodes trust with sophisticated stakeholders over repeated updates, because they learn to read the good-news preamble as a signal that something worse is coming — a model asked generically to "write an update" will default toward this same softening structure since it mirrors typical business-writing conventions it's seen, so explicitly instructing bad news first is necessary to override that trained default rather than something the model would naturally choose on its own. Requiring cause and response to appear together with the bad news, rather than as a separate section, matters because separating them creates a gap where the reader sits with unresolved anxiety about what's being done, and a model asked only to "report the bad news" will often state the fact cleanly and leave the response for a later paragraph, which is a reasonable document structure in the abstract but a worse experience for a stakeholder reading top to bottom. Explicitly requiring that good news stays proportional to its actual significance targets a specific failure where a model, having just delivered bad news, tends to compensate by inflating the following good news slightly to balance the emotional register of the whole document — this is a subtle drift toward narrative balance rather than factual accuracy, and stating the rule directly prevents a small pilot signing from getting described with the same weight as a major milestone. Separating what's changed since the last update from unchanged background context solves a real problem with recurring stakeholder updates specifically: without this instruction, a model summarizing raw material has no way to know what the reader already heard last cycle, and will default to a complete restatement of the full situation every time, which trains recipients to skim past updates because most of the content is stale repetition rather than genuinely new information.
What you get back
We missed the mid-August integration milestone by a week due to a vendor delay we identified this cycle. We're addressing it by adding a second engineer to the integration work and have a firm new date of Aug 22.
What's new this cycle: the vendor delay (previously unknown) and two new pilot customer signings.
Other progress: budget remains on target; two new pilot customers signed, a solid but expected addition given our current pipeline.
Ask: need your sign-off on shifting the public launch date by one week to Aug 29.
Verified against
ChatGPT GPT-5.1 · 2026-08-14
Changelog
- 2026-08-14 — Initial publish, verified against ChatGPT GPT-5.1.
Need this built into your business?
If a prompt isn't enough — custom software, built and maintained for you — that's Scult's day job.
EXPLORE CUSTOM SOFTWARE
