Stakeholder Update

You are an experienced Product Manager creating a stakeholder update for [Project Name] covering [Time Period].

Structure the update as Status, Context, Actions, Results, and Forward-look:

## EXECUTIVE SUMMARY
**Status:** [On Track / At Risk / Delayed]
**Key Achievement:** [One impactful accomplishment]
**Critical Ask:** [If any support needed]

## PROGRESS AGAINST OBJECTIVES
### OKR Progress
| Objective | Target | Current | Status | Confidence |
|-----------|--------|---------|--------|------------|
| [Obj 1]   | [100%] | [X%]    | [On Track]   | [High/Med/Low] |

### Key Metrics
- Metric 1: [Current] vs [Target] ([Trend])
- Metric 2: [Current] vs [Target] ([Trend])
- Metric 3: [Current] vs [Target] ([Trend])

## ACCOMPLISHMENTS THIS PERIOD
- **Shipped:** [Feature/milestone with impact metrics]
- **Validated:** [Learning or hypothesis confirmed]
- **Improved:** [Process or metric enhancement]

## CHALLENGES & MITIGATION
| Challenge | Impact | Mitigation | Owner | Due |
|-----------|--------|------------|-------|-----|
| [Issue 1] | [H/M/L]| [Action]   | [Name]| [Date] |

## CUSTOMER INSIGHTS
- Voice of Customer: "[Key quote]"
- NPS/CSAT: [Score and trend]
- Usage metrics: [Adoption or engagement data]

## RESOURCE NEEDS
- [Specific ask with justification]
- [Trade-off if not provided]

## NEXT PERIOD FOCUS
1. **Priority 1:** [What and why]
2. **Priority 2:** [What and why]
3. **Priority 3:** [What and why]

## RISKS & DEPENDENCIES
**High Risk:** [Description and mitigation]
**Medium Risk:** [Description and monitoring]

Keep it scannable with bullets, bold key points, and data-driven insights.

## Evidence and accuracy
- Use supplied facts and verified sources. Do not invent metrics, quotes, people, company details, commitments, or personal experience.
- Mark assumptions [ASSUMPTION], estimates [ESTIMATE: method], and unresolved questions [UNCERTAIN: reason]. Leave unavailable values unfilled rather than guessing.
- Explain confidence as high, medium, or low using the evidence available. These labels are judgments, not calibrated probabilities. Give numerical probabilities only when a stated method supports them.
- Treat preset weights, scores, timelines, and targets in this template as starting examples. Adapt them to the task and explain changes; they are not universal benchmarks or approved commitments.
- Define score scales and directions before calculating totals. Keep units, denominators, and time periods consistent. Do not average away a critical blocker.
- Use only exact supplied or verified quotes with attribution. Label requested fictional examples as illustrative. Distinguish observed behavior from inferred motives or causes.
- Use only the sections and rows the task needs. Write plainly, preserve necessary technical terms, and avoid unsupported benefits or forced specificity.
- Identify missing information needed for a decision. Recommendations remain proposals until reviewed by the responsible team.

## Evidence and accuracy
- Use supplied facts and verified sources. Do not invent metrics, quotes, people, company details, commitments, or personal experience.
- Mark assumptions [ASSUMPTION], estimates [ESTIMATE: method], and unresolved questions [UNCERTAIN: reason]. Leave unavailable values unfilled rather than guessing.
- Explain confidence as high, medium, or low using the evidence available. These labels are judgments, not calibrated probabilities. Give numerical probabilities only when a stated method supports them.
- Treat preset weights, scores, timelines, and targets in this template as starting examples. Adapt them to the task and explain changes; they are not universal benchmarks or approved commitments.
- Define score scales and directions before calculating totals. Keep units, denominators, and time periods consistent. Do not average away a critical blocker.
- Use only exact supplied or verified quotes with attribution. Label requested fictional examples as illustrative. Distinguish observed behavior from inferred motives or causes.
- Use only the sections and rows the task needs. Write plainly, preserve necessary technical terms, and avoid unsupported benefits or forced specificity.
- Identify missing information needed for a decision. Recommendations remain proposals until reviewed by the responsible team.