A Strategy for Release Planning

Imagine you’re building an internal business tool for your global company. This new tool will improve and streamline the work of hundreds of your coworkers. It’ll also give the business better visibility into how your bottom line is being built. You’re close to having a minimal usable product to ship, so what’s next?

Because We Said So

One option is to just ship the thing, use your power within the organization to force adoption, and voila! I mean, it’s going to improve their work lives — if they would just start using it. They’ll see!

I may be exaggerating, but I’ve often heard similar sentiments from clients that are building internal tools: “They’ll have no choice but to use this!” In my experience, this breeds resentment from users, poor adoption rates, and even an increase in effort for someone to get their work done.

The second option is to create a thoughtful, intentional roll-out to your global user base. Here’s how I’ve helped clients build a plan to do just that.

1. Define Release Activities

The first step is to figure out what exactly your team should be focusing on during the release phase. There are a lot of ancillary activities that go into a release, not just pushing code out.

Some common examples are:

  • Identify users that can influence others to increase adoption.
  • Communicate to the organization about what this thing is and why it is beneficial.
  • Stress test the system by allowing access to a limited set of people (the Soft Launch phase).
  • Follow-up with initial users (survey, phone calls, etc.).
  • Train initial users.
  • Communicate expectations for future releases/milestones.

2. Work Backward

The second step in the process is to work backward. Decide on a go-live date, then build a timeline backward to encompass all of the activities leading up to that date. Then extend the timeline for activities that come shortly after the launch.

This exercise can tease out a lot of interesting things. It forces the team to answer questions like: What will we have built by the go-live date? Who do we need to communicate within the organization? When do we need to have a release candidate ready?

Let’s say you opt for a two-week soft-launch, where we get the product into a limited set of users’ hands and then prioritize working on feedback, bugs, production infrastructure improvements, etc. That means we need to have our minimal usable product ready at least two weeks ahead of that. Maybe your team wants a week of internal testing with a release candidate, so that bumps the release candidate date up another week.

3. Set Ownership

The next step is to make sure that all of the activities defined as part of the release plan are owned by a single team member. It’s the best way to make sure nothing falls through the cracks. Determine who is responsible for coordinating with the developers to set the exact scope of the release candidate. Determine who is responsible for drafting emails and communication to the organization.

4. Follow Up

Once you have a timeline and have assigned ownership to everything that needs to be done, schedule a thirty-minutes weekly check-in to make sure the plan is being executed. It’s a great chance to ask questions, get clarification, discuss activities that may be missing, etc.

It’s much easier just to assume that because things were assigned, the owners are getting things done. But you’ll find it’s much more valuable (for your stress levels, too) to set this time aside.


That’s how I’ve successfully formed and executed a release plan in the past. I’m always looking for ways to improve and would love any feedback or suggestions on what you do differently.