Release plans...or fancy to-do lists

The naive list

I must say, creating a release plan beforehand has become one of the biggest improvements in my life as a product person. I used to have just a checklist with quite generic stuff like:

  • Ensure flags are set
  • Check UI doesn't break for smaller devices
  • Get the docs in place
  • Align with Marketing on the release post

This list was simple, but for simple features, it would make the trick. I would use it on every single feature release but after a while, the features to be released become full products themselves and this naive list was not up to the job anymore.

Becoming a template

One of the main flaws was the lack of project-specific information, it was a one-for-all solution. The first improvement was to start linking project-specific items.

It would include links to GitHub, Slack, documentation, etc. But would still be a simple list that tells you if everything was ready for a release. People would usually interact with it in a read-only way, or not interact at all.

Moving into a live and opinionated list

This list was failing as a communication tool, it was a personal to-do list that I would check stuff, and communicate when everything was ready. More organized, yes, but still a personal list.

The breaking point was to start writing the release plan from scratch with the team. Separating the release in stages the team found useful (e.g.: internal, private beta, public beta, general availability), and giving the list some context.

What do I mean by context? A little text explaining the reasoning behind this stage, what are the goals it has, and when we expect to have it ready. It would open the door to a lot of discussions, like, why something is marked as a requirement for an internal release when it's not relevant to its goal.

A collaborative release plan

The result is a release plan that is created in a collaborative way between all the stakeholders, anyone who reads it should be able to understand why it is the way it is, and also get enough context to propose changes to it.

Release plans work the best when they are live collaboration tools. When everybody understands what's the current goal, they can focus on unblocking the biggest leverages, and push back unnecessary nuisance.

Don't hesitate in setting some time apart to discuss what the goals for each release stage are, and never forget to write them down and share them broadly.

Final thoughts

A release plan should not be a read-only checklist to be filled, it should give a sense of direction and purpose to the team, and set the expectations for the rest of the people.