📊 Stakeholder Updates

Sprint Review Summary for Non-Technical Stakeholders

Summarizes a sprint review in business language for non-technical stakeholders. Built for PMs who attend sprint reviews and need to translate the output for sales, marketing, and customer success.

This prompt converts sprint review content into a business-friendly summary highlighting customer impact, business outcomes, and upcoming commitments. It strips engineering jargon and reframes technical work in terms non-technical stakeholders can act on.

When to use this prompt

Use this after every sprint review where non-technical stakeholders (sales, CS, marketing) need to know what shipped and what is coming next. You will need the list of shipped work, any known customer-facing impact, and the priorities for the next sprint. The prompt intentionally avoids technical language that creates false urgency or false confidence for business teams. It is most useful when your org has a large sales or CS team that needs to know when to communicate feature availability to customers. Skip it if your sprint review audience is already engineering-aligned.

The Prompt

Role: Product Manager Variables: {{sprint_name}}, {{shipped_items}}, {{metrics}}, {{next_sprint}}, {{audience}}

You are a product manager writing a sprint review summary for a non-technical audience (sales, customer success, marketing). Your job is to translate engineering output into business language.

Sprint name: {{sprint_name}}
Shipped this sprint: {{shipped_items}}
Key metrics movement: {{metrics}}
Upcoming next sprint: {{next_sprint}}
Audience: {{audience}}

Produce the summary with these sections:

1. HEADLINE (1 sentence) — The single most important thing that happened this sprint, stated in customer impact terms. Lead with the outcome.

2. WHAT CUSTOMERS CAN DO NOW — 3-5 bullets. Each bullet is a user-facing capability that is now available. Use present tense and action verbs. Do not mention internal system changes.

3. WHAT CHANGED UNDER THE HOOD — 1-2 sentences at most. Describe technical improvements that have no direct customer impact but that unblock future work. Do not explain the mechanism.

4. METRICS — 2-3 key numbers that moved this sprint. Each with previous value, current value, and one-sentence interpretation.

5. WHAT TO TELL CUSTOMERS — 2-3 talking points sales and CS can use. Each should be a specific customer situation and the message to deliver (e.g., "If a customer asked about X in the last 3 months, tell them Y is now available").

6. COMING NEXT SPRINT — 3 bullets max on the next sprint's focus. Be clear about what is committed vs. aspirational.

Rules:
- Replace all jargon. "API" becomes "integration." "Refactor" becomes "internal cleanup."
- Do not promise things that have not shipped.
- If something shipped behind a feature flag, say "available for a small beta cohort" explicitly.

Example Output

HEADLINE: Mid-market billing admins can now find overdue invoices in seconds instead of minutes, unlocking faster collections conversations.

WHAT CUSTOMERS CAN DO NOW
- Sort invoices by overdue status directly from the main dashboard.
- See a clear visual badge on any invoice past its due date.
- Draft a reminder email from an overdue row with one click.
- Access the new view on all existing plans at no extra cost.

WHAT CHANGED UNDER THE HOOD
We improved how we compute overdue status so customers in different time zones see consistent results. This also makes future automated reminders possible.

METRICS
- Median days to collection: 18 down to 13 in beta cohort.
- Dashboard time-on-page for billing admins: 8 down to 5 minutes.
- Beta NPS for billing admins: 32 up to 36.

WHAT TO TELL CUSTOMERS
- If a customer asked about invoice sorting in the last 90 days, tell them the new overdue-first sort is now available in beta.
- For mid-market prospects concerned about collections workflow, the one-click reminder draft is a new differentiator worth demoing.

COMING NEXT SPRINT
- Bulk invite CSV import (committed).
- Localization of overdue labels for French and German (committed).
- Automated reminder emails (exploratory only).

Recommended Tools

Notion projects is the best home for sprint review summaries because non-technical stakeholders can comment directly and the history is preserved. Google Workspace (Docs or Gmail) works for teams that prefer email delivery. Productboard ties the summary to the roadmap so CS can see commitments in context. Use Productboard if your roadmap is already there; otherwise Notion is simpler.

Notion Projects76/100 Google Workspace73/100 Productboard73/100

Frequently Asked Questions

When should I use this prompt?

Run it within 2 hours of the end of every sprint review, while context is fresh and before the team disperses. The summary is most valuable when it reaches sales and CS before they have customer conversations the following day. Do not use it for internal-only technical sprints where nothing user-facing shipped; in that case, a brief 'nothing user-facing this sprint' note is enough. If the majority of your shipped work is always invisible to customers, reconsider your sprint cadence or how you communicate progress to business teams.

How do I handle features shipped behind feature flags?

Always call them out explicitly as 'available for a small beta cohort' or 'available to internal users only.' Never say a feature 'shipped' without qualifying the availability, because sales or CS will communicate something misleading to a customer. The difference between 'shipped' and 'available' matters enormously to customer-facing teams. If you are unsure whether a feature is available to a given customer, say so and ask them to check with you before telling customers. Trust evaporates fast when CS promises features that are not actually live.