How to write release notes
Release notes serve four audiences with one ship: customers, support, exec, and the on-call dev. Write each one for its reader.
Why it matters
Most release notes only serve one of those four audiences (usually the dev), and the other three are forced to translate. The Tenhaw release kit produces all four, drafted automatically by the Release Planner agent, your job is to review and ship, not write from scratch.
Step by step
- Run the Release Planner agent. On the story (or stories) being released.
- Review the user-facing notes. Benefit-led, headline first. Cut every adjective.
- Review the dev changelog. Technical summary, breaking changes, migrations, dependency bumps.
- Review the exec one-pager. Outcome it ladders to + £ value + risk level + success metric.
- Review the rollout plan. Stages with % rollout, go-signal, rollback signal, feature flag name.
- Review the comms drafts. Slack message, customer email, in-app banner, support script, all copy-pasteable.
- Approve + render the printable PDF. For any meeting that needs the one-pager.
What good looks like
- Customer notes are benefit-led, not feature-led
- Dev changelog includes breaking changes + migrations
- Exec one-pager states the outcome and £ value
- Rollout plan has explicit go and rollback signals
- Support has a copy-pasteable macro for the inevitable inbound
How Tenhaw runs this
The Release Planner agent generates the full kit from one click on a Done story: user notes, dev changelog, exec one-pager, rollout plan, and copy-pasteable comms across Slack, email, in-app banner and support macro. A printable PDF renders in the E2B sandbox.
- Tenhaw Release Planner AI agent
- Tenhaw E2B sandbox (PDF render)
- Tenhaw release kit
In Tenhaw → story in Done → Run Release Planner. Renders the PDF in an isolated E2B sandbox via weasyprint.
Run this in your team
The Tenhaw product enforces every rule in this playbook so it doesn't sit on a wiki gathering dust. Try Tenhaw or book a working session with the founder.