# Stakeholder Communication Walkthrough — Learn by Doing ## Before We Begin **Diagnostic:** Who are you writing for? Think of one person who gets your project updates. What do they *need* from you—and what would they skip? How does your audience change the message? **Checkpoint:** You can name at least two different audiences for the same project and one way your update would differ for each. --- ## Step 1: Draft a Status Update **Task:** Pick a project (real or hypothetical). Write a 6–8 line status update using the structure: What happened, What's next, Blockers, Risks. Apply the pyramid principle—lead with the conclusion (RAG + one-sentence TL;DR). **Question:** If your reader only saw the first line, would they get the right takeaway? What would they miss? **Checkpoint:** Update has RAG, TL;DR, and all four sections. First line is the conclusion. --- ## Step 2: Map Stakeholders **Task:** List 5 stakeholders for your project. Plot each on a power/interest grid. For the "manage closely" quadrant, write one sentence: what do they need from your updates? **Question:** How would your update change if you were writing for the "manage closely" vs "keep informed" quadrant? What would you add or remove? **Checkpoint:** 5 stakeholders plotted; "manage closely" needs are stated. --- ## Step 3: Communicate a Delay **Task:** Imagine your release is slipping by 1 week due to a third-party API delay. Write a 4–5 sentence message to an executive. Include: the fact, the cause, what you're doing, and what you need (if anything). **Question:** What might you be tempted to soften or hide? Why is stating it clearly better? **Checkpoint:** Message is direct, includes cause and plan, and has a clear ask or next step. --- ## Step 4: Tailor for Two Audiences **Task:** Take one status update. Create two versions: (1) For an executive—3–4 bullets, pyramid style. (2) For an engineering lead—more detail on technical blockers and dependencies. **Question:** What's different? What would be wrong with sending the exec version to the eng lead, or vice versa? **Checkpoint:** Both versions exist; exec version is shorter and outcome-focused; eng version has technical detail. --- ## Step 5: Apply RAG Thoughtfully **Task:** You have: (A) One minor bug in edge case. (B) Key developer out for a week. (C) Scope creep request from stakeholder. Assign RAG to each and justify. Write one sentence for each on how you'd communicate it. **Question:** When is Amber more appropriate than Red? When might Green be misleading? **Checkpoint:** RAG assigned with rationale; communication approach stated for each. --- ## Step 6: Design a Cadence **Task:** For your project, define update cadence for: core team, product/eng leads, and executives. Specify: frequency, format (written/call), and what each gets. **Question:** What happens if executives get daily updates? What happens if they get monthly? Where's the right balance? **Checkpoint:** Cadence defined for 3 levels; format and content appropriate to each.