Stakeholder updates in 10 minutes: one prompt, any audience

If your weekly update starts with "Hey all, quick update below…" and runs to twelve bullet points, nobody is reading it. The content is fine; the packaging is wrong. The problem is almost never a lack of information — it's that the update was written for the writer rather than the reader.

What this is

A three-step workflow: collect your raw notes, run one prompt, review the output as your audience would. You provide the facts; the model provides the shape. The result is a 150–200 word update that answers exactly the question your audience is actually asking — usually some variant of "is this on track, and do I need to do anything?"

This pattern is drawn from Anthropic's open-source knowledge-work-plugins repository, specifically the product-management plugin's stakeholder-comms skill, which was analysed in the March 2026 write-up by mager.co. The plugin was designed for Anthropic's Cowork desktop tool, but its underlying logic — collect context, specify audience, generate shaped output, validate — works identically with a manually pasted prompt in any LLM.

What you'll need

• Ten minutes and a messy list of what happened this week
• An LLM you trust with internal content — Claude, ChatGPT, Gemini, or your enterprise equivalent
• A clear picture of who is reading the update and what they care about most

Step 1 — Dump your raw context

Don't try to shape your notes first. Open a blank doc and spend two minutes writing everything relevant as terse bullet points. What shipped, what slipped, what's blocked, what's next, what surprised you. Include names and owners where you know them. Messy is fine — this is input, not output.

Example dump for a software project:

- frontend PR merged Tuesday, now in QA
- backend API three days behind, Tariq investigating
- client demo rescheduled from 19th to 26th (their request)
- competitor shipped similar feature last week, need to flag to leadership
- budget review call Thursday, need to confirm headcount ask
- design signed off on revised onboarding flow

Six bullets, two minutes. That's enough. You don't need full sentences or context — the model will ask if it needs more.

The prompt

Paste this above your bullet dump, filling in the three bracketed fields:

You are helping me write a stakeholder update. Here is my raw context for the week:

---
[PASTE YOUR BULLETS HERE]
---

Audience: [e.g. "my line manager and the VP of Product"]
Audience's main concern: [e.g. "is this project on track to ship by end of quarter?"]
Update type: [weekly / milestone / risk escalation]

Write a stakeholder update covering exactly these four points:
1. Overall status in one sentence — on track, at risk, or blocked, with a brief reason
2. What moved forward since the last update
3. The single most important risk or blocker, including who owns it and the next step
4. What is planned for the coming period

Format: plain paragraphs, no bullet points, no emoji. British English. Target length: 150–200 words.

If my notes are missing something you need for any of the four points, ask me one clarifying question rather than inventing a detail.

Why each piece earns its keep

Audience's main concern is the most important field. An engineering lead reading a status update wants to know whether the API delay blocks their sprint; a VP wants to know whether the launch date is safe. Without this line, the model produces a generic summary. With it, the entire framing shifts.

The four fixed points mirror what Anthropic's stakeholder-comms skill uses internally: status, progress, risk with owner, and next period. Keeping them consistent week-on-week means your readers build a mental model of your updates and can scan faster.

"Ask rather than invent" is the line most people skip. Without it, a model will confidently fill a gap — giving you a "the API delay is expected to resolve by Thursday" that you never said and may not be true. With it, you get "I don't see a resolution timeline for the API delay — do you have one?" That's a prompt to add a real fact, not a hallucinated one to delete.

150–200 words is a forcing function. Most status updates are three times too long because writers feel obligated to show their work. The word limit forces prioritisation — if the competitor's new feature isn't relevant to the reader's concern this week, it doesn't make the cut.

Step 3 — Read it as your audience would

Before you send, read the draft once with this question in your head: if I received this update and knew nothing else about the project, would I know whether to act? Look for three things:

• Invented specifics. If you see a date, number, or name you didn't put in your notes, delete it or replace it with something accurate.
• Wrong status signal. The model reads tone from your notes. If you wrote "API three days behind" matter-of-factly, it may rate the project as Amber when you know it's actually Red. Override it.
• Missing context only you hold. If the client rescheduled the demo because of internal restructuring — something your notes don't capture — the update won't mention it. Add it in one sentence.

The review should take two minutes. If it's taking longer, the model probably asked a clarifying question you should answer before regenerating.

Failure modes

• It won't catch political sensitivity. Flagging the backend delay with Tariq's name attached may be accurate and still be the wrong move in a particular organisational context. That judgement is yours.
• It won't know what's already been communicated. If you mentioned the demo reschedule in last week's update, the model doesn't know that. You may need to add "this was flagged last week" to avoid sounding like you're raising something new.
• It won't replace the relationship. A well-packaged update reduces friction and builds credibility over time — but it doesn't substitute for the direct conversation when something is genuinely going wrong.
• It won't work with vague inputs. If your bullet dump is "various things progressed, some blockers remain," the model has nothing to work with. The quality of the output is bounded by the quality of the input.

The broader pattern

The reason this works is the same reason the inbox triage prompt works: you're moving the cognitive load from "write clearly under ambiguity" to "verify that a draft is accurate." The second task is faster and easier for most people. You're not outsourcing the knowledge — you're outsourcing the shaping of it.

Anthropic's knowledge-work-plugins use this same logic at a system level, connecting the model to live project trackers, Slack threads, and wikis so the raw context is gathered automatically. The manual version here requires you to gather it yourself. The payoff is identical: ten minutes instead of thirty, and a draft you can trust enough to send after a quick read.