SaaS release notes prompt

When to use it

Use this when you need customer-facing release notes for a product update and want an actionable draft rather than vague bullet points. Replace the fictional details with your team's real issue tickets and delivery facts before publishing.

The prompt

## Role
Act as a product manager writing customer-facing release notes. Apply professional judgment to present functional changes clearly and concisely.

## Context
KiteMetrics, a lightweight web analytics tool, is releasing version 2.4. This sprint includes three changes: custom date range filtering on the visitor dashboard, CSV export for event logs, and a bug fix resolving miscalculated bounce rates on single-page sessions. The export feature is limited to 50,000 rows per download. The release goes live this Thursday to all paid tiers.

## Objective
Translate these technical changes into plain-language release notes that explain what changed, why it matters, and any usage boundaries users must know.

## Audience
The primary users are product managers and growth leads who check updates to understand workflow impacts. Make the content clear, practical, and scan-friendly without unnecessary engineering jargon.

## Requirements
Draft a 250–350-word release notes document. Include a brief summary banner, three structured sections (New, Improved, Fixed), and clear action steps for accessing each capability. Specify the 50,000-row limit on CSV exports explicitly. Add a short verification table noting which UI paths must be validated before release.

## Constraints
Do not invent unlisted features, API endpoints, performance benchmarks, or upcoming roadmap promises. Rely strictly on the supplied sprint details. Label any operational assumptions clearly.

## Tone & style
Be direct, informative, and precise. Use active voice, short paragraphs, and bullet points. Avoid marketing hype, excessive enthusiasm, and internal developer jargon.

## Output format
Present the customer-facing release notes first under clear Markdown subheadings. Follow with an internal checklist of verification steps and flagged assumptions.

## What to avoid
Avoid vague statements like "various bug fixes and performance improvements", unverified time-saving claims, and technical commit logs copied verbatim.

## Success criteria
An end user can immediately understand the three changes, know where to find them in the app, and recognise the export limitation.

## Clarifying questions
Ask up to three focused questions only if critical technical context is missing. Otherwise, proceed with the provided details and list any assumptions clearly.

Why it works

• The scenario gives the model concrete facts and boundaries instead of asking it to invent a brief.
• The requirements specify the actual deliverables and the important edge cases for this task.
• The constraints make unsupported claims and unapproved commitments harder to slip into the result.
• The success criteria turn review into a practical check: an end user can immediately understand the three changes, know where to find them in the app, and recognise the export limitation.

Make it yours

Build a tailored version with PromptDeck by replacing the fictional scenario with your own context, audience, and constraints. Keep the verification steps so the final result reflects what you actually know.