stakeholder-updates
Stakeholder Updates
Write updates that earn trust by being clear, honest, and worth reading.
How to use
/stakeholder-updatesApply stakeholder update constraints to this conversation./stakeholder-updates <context>Draft or review an update for the described situation.
Constraints
Structure
- MUST lead with the headline: what's the one thing the reader needs to know?
- Status, blockers, and asks MUST be separated clearly
- SHOULD use the format: progress since last update, what's next, where you need help
- NEVER bury bad news in the middle. Lead with it or call it out explicitly.
- MUST keep updates under 5 minutes of reading time
Signal Over Noise
- MUST include only information that changes a decision or requires attention
- NEVER pad updates with activity metrics that don't matter ("we had 12 meetings this week")
- SHOULD quantify progress against milestones, not describe effort
- MUST tailor detail level to the audience: executives want outcomes, peers want details
Escalation Judgment
- MUST flag risks early, not when they've already become problems
- SHOULD frame risks with: what's happening, what's the impact, what you're doing about it, what you need
- NEVER surprise stakeholders. If something might go wrong, say so before it does.
- MUST distinguish between "FYI" and "I need you to do something"
Honesty
- MUST be accurate about project health. Green/yellow/red MUST reflect reality.
- NEVER use "on track" when it isn't. Stakeholders lose trust once, and it's hard to rebuild.
- SHOULD acknowledge uncertainty when it exists rather than projecting false confidence
- MUST own bad news directly without blame-shifting
Anti-Patterns
- The Wall of Text: long narrative updates nobody finishes reading
- Perpetual Green: everything is always "on track" until it suddenly isn't
- Activity Reporting: listing what you did instead of what it means
- The Sandbag: hiding problems until they're too big to ignore
- Asking for help buried on page 3 where nobody sees it
More from dragoon0x/product-skills
prd-writing
Write product requirement documents that engineers want to read and can actually build from. Covers structure, scope discipline, and the balance between clarity and over-specification. Use when writing PRDs, reviewing spec quality, or when engineering keeps asking clarifying questions.
1freemium-vs-paid-gate
Decide whether a product should offer a free tier, free trial, or go straight to paid. Structured decision framework based on economics, distribution model, and competitive landscape. Use when launching a new product or reconsidering your pricing model.
1error-recovery
When things break, guide people forward instead of leaving them stranded. Error message copy, retry patterns, graceful degradation, and recovery flows. Use when building error handling or failed state UIs.
1cta-patterns
Design calls-to-action that people actually click. Covers button copy, placement logic, urgency without manipulation, and progressive commitment. Use when reviewing pages for conversion potential or when CTA copy feels generic.
1onboarding-flow
Design first-run experiences that create the aha moment fast. Reduces time-to-value by sequencing actions, progressive disclosure, and contextual guidance. Use when building signup flows, product tours, or empty states.
1user-psychology
Apply motivation, friction, and trust patterns to product decisions. Maps cognitive biases and behavioral triggers to specific UI and copy choices. Use when reviewing flows for drop-off points or when something feels right but doesn't convert.
1