How to Plan a Product Release

What’s the occasion?

There are many reasons for releasing product. Here’s just a few:

• You’re releasing an existing product onto a new platform (such as Android)
• You’re releasing a new idea into market for the first time
• You’re releasing an existing product onto a new platform (such as Android)
• You’re introducing new features to current customers
• You’re introducing new features to new or different customer segments
• You’re re-releasing your current product using different technology (often called “replatforming”)

All of these scenarios constitute a product release, or several releases (more on that later), but not all require the same level of planning.

I’m going to focus this discussion on how to plan a “major” release, which I’ll define as “a new product or a major rebuild that renders much of the old experience and features obsolete.”

Note: Releases are different from versioning, which is a method of numerically codifying releases once they ship. At The Development Factory, we follow Semantic Versioning when versioning our product releases, which offers further delineation between “major” and “minor” releases.

Why plan?

A release planning session is a descendent of the product roadmap. That means that the company should first decide what initiatives it wants to deliver on (and when) and then set aside time to plan each (major) product release.

Setting aside time to plan a whole product release might seem unnecessary or even anti agile.

If you’re a busy business stakeholder you might hope the product team can just look after this on their own.

If you’re part of the engineering team, you might think the release details can be adequately covered during sprint planning.

I know that none of us want more meetings, but it’s critical to understand that planning a release holistically and inclusively is essential for establishing shared goals and shared knowledge that can span the product development timeline and better ensure a successful product launch.

You’ll want to be sure you have the right representation in the room when you begin your release planning.

Being “inclusive” here means ensuring that key representatives from different departments and with different skill sets are in attendance. What we’re looking for are individuals who can contribute meaningfully based on their expertise and unique perspective, but in service of the collective mission.

Being inclusive also has its limits. Try to have not less than 4 people and no more than 7 or 8 in the room. Otherwise the discussion may never get off the ground.

Extra credit to your hiring plan if the group of folks you include happens to be gender and racially diverse!

Starting with Why

If you don’t have a product roadmap or you’re not using that tool as effectively as you could be, that’s OK. You can still plan a product release without a roadmap.

Good product roadmaps identify why the release is important to the business.

Start your release planning session by revisiting or discussing why the release matters.

What do you hope will happen for the business once the product has been released?

By when?

How will you measure that success?

Take care to assess team alignment at this stage. Is everybody in agreement about why we’re doing this?

The release planning session is an opportunity to get buy-in from your team. This is especially important given that most of the attendees will lead the efforts of actually building the product.

Establishing shared purpose in a collaborative way will also empower those individuals to spread the message to other team members beyond the release planning session.

Who is it for?

A release planning session is a perfect forum for pulling out your user personas -another important vehicle for creating shared understanding- to keep the room focused on who the product is for and why it matters to them.

Remember: Your users’ goals are not likely to be the same as your business goals.

Users might be segmented broadly based on roles they will play with the product. For example, a “host” versus a “traveler.”

Or you might be concerned with nuances within user types. For example, a “superadmin” versus a “contributor.”

One data point that will be helpful to have on-hand is the behavioral patterns of your users. Specifically, how often are they expected to use the product or feature? Is their use specific to certain times of day or moments in their life?

These details may seem trivial, but you will soon discover they play an important role in prioritization.

If you don’t have documented user personas (they don’t have to be fancy but they should exist in a format more explicit than the mind’s eye), you might need to budget additional time to discuss and align about who the users are before advancing to feature planning.

Tip: If you don’t have user personas, try to capture the user insights discussed during your release planning and then document and share after.

Note: Customer personas help us understand who buys our product and why, user personas help us understand who is using the product and with what intent.

What does it do?

Finally.

Finally we can start to bring the product to life by discussing features.

Guide the discussion about features by considering the following questions:

What is the task the user wants to accomplish?

Which user(s)?

Why do they want to complete that task?

How often will they want to complete that task? Hourly? Daily? Weekly? Quarterly? Only once?

How valuable will this feature be?

The matter of value is perhaps the most important.

Value is a transaction, not a declaration. It’s a tacit agreement between users and products and it’s typically measured by retention, revenue, and referral – all currencies of satisfaction.

There are lots of ways to contemplate value and your team should have some data for this coming into the planning session.

I like the Kano Model for defining feature value, but tagging your features as “high” “medium” and “low value” is fine too. What’s important is that that team is in agreement about how important any one particular feature may be to users.

If we openly hypothesize about value during our release planning, we’ll have metrics we can readily track after release in order to validate our ideas. That’s how product development transitions into product management.

Map it

I love story mapping as a method for quickly and collaboratively mapping out the features of a release.

Story mapping can be done physically, using cue cards or post-its and wall space, or it can be done digitally using tools like Stories on Board. A digital format will make refactoring an easier process, but the interactivity of physical story mapping really affords every participant an opportunity to connect with the plan.

Start by mapping the story of your product from beginning to end. For example: First the user can login, then the user can invite friends, then the user can visit the news feed.

It’s helpful to frame features actionably using verbs. In my example above I’ve emphasized the action.

Actions should be mapped left to right, in the relative sequence they will occur.

With software, users don’t always follow the same sequence of actions. Don’t get too hung up on this. Sometimes I have my morning tea before I shower, and sometimes after, but I always complete my morning routine before I start my workday.

Once you’ve horizontally mapped the primary actions of your product story, you can add detail to each action by mapping elements vertically.

An example of elements (features, really) that relate to the login action might be “can reset password” and “must verify email address.”

Arrange these vertically below the primary action to which they most relate and in order of criticality or customer value.

The sprawl of your story map shows how even “simple” products can represent a lot of functionality.

Slice it

In Scrum, the goal of every sprint is to release a potentially shippable product increment (PSPI).

Whether you follow Scrum or not, you want to be thinking about delivering fully functional bits of your software (that create customer value) with each release.

At the same time, we want to avoid reverting to Waterfall, by requiring too many (or all) features in your story map to be included in a single release.

This is where slicing (and the story mapping process in general) helps tremendously.

Simply draw a horizontal line below all the features you must include in the first release. This is made easier because you already stacked the vertical cards in descending order of priority or value.

Be brave and lop off the items that can wait. We once waited over six months to ship a forgot password function in service of higher value features.

You can apply one or several “slices” to your release plan following the same method. This is precisely how a single product plan can translate into several release points.

Now port all those stories into your project board (try Jira or Pivotal Tracker) and you’re ready for production.

Summary

Release planning is an opportunity to bring detail to the whole product and its various inherent workflows upfront, and in collaboration with key team members.

It is not possible to determine every detail about the implementation during a release planning session, nor is it advisable. That’s what sprint planning is for.

But rather than cobbling up to a whole product one release at a time, breaking down the vision upfront through release planning provides that big picture everybody craves and a constant, shareable reference point throughout product development.

Do you want to learn how to lead effective release planning sessions? Contact us today to learn more about our product management workshops and training.