Launch · Core
Plan a release
A release plan makes sure everyone knows what is going out, when, who is affected and what happens if it goes wrong. Releasing small changes gradually keeps the risk low.
About 1-2 daysChanges yearlyLast reviewed 4 November 2026
Who this applies to
- Skills it builds
- Delivery and execution
- PM types
- All
- Product types
- All
- Starting points
- All
- Ways of working
- All
- Experience
- All
- Size of organisation
- All
Steps, by experience
Beginner (under 1 year)
- Write one page that says what is in the release, who it affects, the goal and what is not included.
- List everyone who needs to know: support teams, stakeholders, other teams who depend on you, and users if their experience changes. Plan what each group will hear and when.
- Agree with your engineers how the change goes live. Releasing to a small share of users first (sometimes called a canary or phased release) lets you spot problems before everyone sees them.
- Agree how you will know it is working: the dashboards and alerts to watch, and who watches them in the first hours and days.
- Agree a rollback plan: what would make you undo the release, who decides and how long it takes.
- Check the go-live list with the team the day before: tests passed, support briefed, monitoring ready, comms scheduled. After release, check your measures and share how it went.
Intermediate (1 to 4 years)
- Publish a release page covering scope, goal, audience, non-goals and timeline.
- Plan stakeholder, support and user communications.
- Agree a gradual rollout, monitoring, owners and rollback criteria with engineering.
- Run a go / no-go check and a short review after release.
Experienced (5+ years)
- Publish the scope, audience and comms plan.
- Plan a gradual rollout with monitoring and named owners.
- Agree the rollback criteria and who makes the decision.
- Hold a go / no-go meeting, and book a post-release review.
Who can do this
Owner: Product manager
Can be delegated to
- Delivery Manager: Coordinate the release timeline, go / no-go meeting and dependencies
- DevOps / SRE or Tech Lead or Backend Engineer: Set up the gradual rollout, monitoring, alerts and rollback
- Content Designer: Write user-facing release notes and messages
- QA / Tester: Confirm testing is complete and run smoke tests after release
Reviewed by: Tech Lead, Delivery Manager, DevOps / SRE
Tool examples
- Jira
- Create a version (release) and attach the stories to it, so the release notes and progress come from one place.
- Confluence
- Use a release planning page: background, goals and non-goals, team, timeline, comms and rollback plan.
- GitHub
- Ask engineers to tag the release, so you can see exactly what went out and roll back to the previous tag if needed.
- Vercel
- Every pull request gets a preview link for checking before it goes live, and you can promote an earlier deployment back to production if something breaks.
- AWS
- Ask DevOps whether the service can shift traffic gradually to the new version, so problems only reach a small share of users.
- Azure
- Ask DevOps about deployment slots, which let you test a release in production conditions and swap back quickly.
Definition of done
- Release scope, audience and timeline published
- Stakeholders, support and users told what they need to know
- Monitoring and named owners in place for the first days
- Rollback criteria and decision-maker agreed
Common pitfalls
- Releasing everything to everyone at once
- Support teams hearing about changes from users
- No agreed point at which you would undo the release
If you lead the team
What good looks like: Everyone knows what's going out, when, who's affected and how to roll back.
Ask your PM
- Who's affected by this release, and do they know?
- How do we roll back if it goes wrong?
Warning signs
- Releases surprise support or customers.
- There's no rollback plan.