Stakeholder Update Writer: Turn Messy Project Notes Into a Clear Status Email
Why this prompt matters
Project managers spend an average of 54 minutes per week writing status updates — and most of that time is not spent writing, but deciding: what to include, what to leave out, how to frame a delay without triggering alarm, and how much technical detail a non-technical executive actually wants. Bad status updates cause two kinds of damage: ones that are too vague leave stakeholders anxious and prompting for follow-up, while ones that are too detailed get skimmed and missed. A professional managing 2–3 active workstreams and sending weekly updates to multiple audiences could reclaim 90–120 minutes per week by using a structured prompt instead of writing from scratch each time. More importantly, consistently well-structured updates build stakeholder confidence — the kind that makes approvals faster and difficult conversations easier.
What we use it for
You have 20 minutes before the weekly stakeholder update is due, and your project notes are scattered across three Slack channels, a half-finished Notion page, and your head. You know what happened this week — but translating raw project reality into a clean, appropriately calibrated email for a mixed audience of executives, engineers, and an external client takes longer than it should. This prompt does the structural heavy lifting so you can spend your time editing and verifying rather than drafting from scratch.
Prompt
Act as an expert project communications specialist with deep experience writing executive and stakeholder updates across software, consulting, and operations environments. I need to send a status update about a project I am managing. Here is my context: - Project name: [PROJECT NAME] - Project phase: [DISCOVERY / DESIGN / BUILD / LAUNCH / POST-LAUNCH / MAINTENANCE] - Audience: [E.G. "My direct manager and two skip-levels" OR "External client executive sponsor" OR "Cross-functional stakeholders including Marketing, Legal, and Engineering leads"] - Audience's technical level: [NON-TECHNICAL / MIXED / TECHNICAL] - Update cadence: [WEEKLY / BIWEEKLY / MONTHLY / AD-HOC] - Preferred length: [BRIEF (100–150 words) / STANDARD (200–350 words) / DETAILED (400–600 words)] - Tone: [FORMAL / PROFESSIONAL-CASUAL / EXECUTIVE-BRIEF] My raw notes for this period: [PASTE YOUR NOTES HERE — bullet points, Slack messages, meeting summaries, whatever you have. Don't clean them up. Just paste.] Transform my notes into a structured status update using exactly these sections: **Status:** [One-sentence summary with a clear RAG indicator: GREEN / AMBER / RED and what it means for this project] **Progress Since Last Update:** [3–5 bullet points covering what was accomplished. Lead with outcomes, not activities. "Completed X, which unblocks Y" not "We worked on X."] **What's Coming Next:** [3 bullets covering the most important near-term work, with target dates where known] **Blockers & Risks:** [If none: write "None currently." If any: name each blocker, who owns resolution, and the deadline impact if unresolved] **Decisions Needed / Asks:** [Any explicit asks of the reader — approvals, inputs, introductions, unblocking actions. If none, omit this section entirely.] Constraints: - Match the technical depth to the stated audience level — never explain basic concepts to a technical audience, never use unexplained jargon for a non-technical one - Every bullet must be specific: name the thing, the person, or the number. No vague statements like "good progress was made." - Keep the Status line to one sentence — it should be scannable in 3 seconds - If notes indicate a risk or blocker that the sender did not explicitly flag, surface it anyway — your job is to protect the reader from surprises, not to make the sender look good
Result
Input scenario: Mira is a product manager at a 200-person B2B SaaS company. She pasted the following raw notes: "finally got legal to sign off on the DPA with our EU data processor, took three weeks longer than expected. Dev completed the GDPR consent flow on staging — needs QA. One bug found in the cookie banner (severity: medium, assigned to Dev). Marketing wants to push the launch date earlier but we can't — dependencies still open. Next week: QA sprint on consent flow, fix cookie banner, brief the sales team on what changes. Launch still tracking for July 14. Biggest risk: if QA finds more bugs, we slip to July 21." Audience: VP of Product + CMO (both non-technical). Preferred: Standard. Tone: Professional-casual.
Status: AMBER — GDPR compliance build is on track for July 14, but QA scope this week will determine whether that date holds.
Progress Since Last Update:
- Legal approved the Data Processing Agreement with our EU data processor — a three-week negotiation that was the last regulatory prerequisite before launch.
- Engineering completed the GDPR consent flow and deployed it to staging, moving us into the QA phase as planned.
- One medium-severity bug identified in the cookie banner; assigned to Dev with a fix expected before the QA sprint begins.
What's Coming Next:
- QA sprint on the full consent flow — targeted completion by June 27.
- Sales team briefing on customer-facing changes to the sign-up and data settings experience — scheduled for June 26.
- Go/no-go decision on July 14 launch date — expected by June 28 once QA results are in.
Blockers & Risks:
- Launch date risk: If QA uncovers additional bugs beyond the known cookie banner issue, the launch date may shift to July 21. We will have a clearer picture by June 28.
- Note on the launch date request: Marketing has asked about moving the date earlier. That is not possible given open QA and sales enablement dependencies — holding at July 14 as the earliest viable date.
Decisions Needed:
- No decisions required this week — but please be available for a quick async decision on June 28 if QA results require a date call.
You have 20 minutes before the weekly stakeholder update is due, and your project notes are scattered across three Slack channels, a half-finished Notion page, and your head. You know what happened this week — but translating raw project reality into a clean, appropriately calibrated email for a mixed audience of executives, engineers, and an external client takes longer than it should. This prompt does the structural heavy lifting so you can spend your time editing and verifying rather than drafting from scratch.