A product release is the launch of a new product or feature set into the market, or for use within your organization. They can happen frequently (daily or weekly) or just occasionally (quarterly or annually). Your product release rhythm will depend on a few factors, such as the maturity and stability of your business, and what resources are available to you. Nevertheless, the sophistication of your deployment process will also impact your product release rhythm.
Contents
Different circumstances may prompt a product release, but not all scenarios require the same level of planning.
In this article, I’m going to focus the discussion on how to plan a “major” product release. I’ll define that as “a new product, or a major rebuild that renders much of the old experience and features obsolete.”
Where Do Product Release Plans Fit in the Product Planning Process?
Product Managers plan product releases by the product roadmap.
A feature brief is an essential bridge of information between the product roadmap and the product release plan. Ideally, Product Managers draft and share the roadmap before release planning.
However, it is possible to jump straight into product release planning without first writing a feature briefly.
If you’re a busy department leader, setting aside time to plan a whole product release might seem daunting. What’s more, it may be something you hope can happen without you. I don’t recommend this.
We know that nobody wants more meetings. Still, planning a product release holistically is essential for establishing shared goals and shared knowledge with the delivery team. Why is that? Because it can span the product development timeline and better ensure a successful product launch.
Release planning begins with having the right representation in the room.
Besides yourself, you’ll want to invite key personnel from different departments and with complementary skill sets. Extra credit to your company’s hiring plan if the group of folks you gather is also racially and gender diverse! If not, take note and make a separate plan for changing that.
For maximum effectiveness, try to have not less than 4 people and not more than 7 or 8 in your product release planning sessions.
Start with Why
If you don’t have a product roadmap or feature brief, that’s OK. You can still plan a product release without those documents, you’ll just need to ask and answer more questions as part of the process. Of course, planning then will require more time.
Start your release planning session by discussing (or revisiting) why product release matters.
Ask questions like:
- What do we hope will happen for the business once this product has been released?
- By when do we anticipate seeing these results?
- How will we measure success?
Take care to assess team alignment at this stage. Is everybody in agreement about why this project has been prioritized on the roadmap?
The release planning session is an important collaboration and a critical opportunity to get buy-in from your delivery team. A well-managed release planning session will empower the participants to further communicate and reinforce relevant details to other team members throughout delivery.
Know Who the Release is For
A release planning session is a perfect forum for referencing your buyer or user personas. It will allow the room to stay connected to who the product is for and why it matters to them.
Users might be segmented broadly based on functional roles. For example, in the case of Airbnb, a “host” user versus a “traveler” user requires different functionality from the product.
Or you might be concerned with permission-based user types. For example, in the case of a media website, an “editor” versus a “contributor,” where may require approvals before publishing a post to the website.
One set of data 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 the day or key moments in their life or calendar year?
These details may seem trivial, but you will soon discover they play an important role in determining the order in which features can be released.
If you don’t have documented user personas (they don’t have to be fancy but they should be written down), you might need to budget additional time to discuss and align who the users are before discussing feature details.
If you don’t have user personas at all, plan to capture the user details discussed during your release planning session, so you can document and share them for the next session / in the future.
Customer or buyer personas help us understand who buys our product and why.
User personas help us understand who is using the product and with what intent.
In B2C businesses, customers and users may be the same. In B2B, oftentimes they are not.
Discuss How the Product or Feature Should Work
Now we can start to bring the solution to life by discussing features and functionality.
Guide the discussion about features by considering the following questions:
- What is the task the user wants to accomplish?
- Which user(s) want to accomplish this task?
- Why do they want to accomplish this task?
- How often will they want to complete this task? Hourly? Daily? Weekly? Quarterly? Only once?
- How valuable will this feature be?
When discussing value, consider this:
Value is a transaction, not a declaration. It’s a tacit agreement between users and products that is typically measured by retention, revenue, and referral – all currencies of satisfaction.
One framework I like for assessing feature value is the Kano Model, but simply categorizing your features as “high,” “medium,” and “low value” is fine too. Make sure all the participants are operating from the same definitions of what each category means.
Remember that the features and experiences that create value for customers don’t necessarily create value for the business. This is one of the fundamental tensions of product management.
The goal of feature planning is to make choices that are good for both sides, as much as possible.
Map it
I love Jeff Patton’s story mapping technique as a method for quickly and collaboratively planning out the features in a release.
Story mapping can be done in person, using cue cards or sticky notes and lots of wall space, or it can be done digitally using tools like Stories on Board.
A digital format such as what StoriesOnBoard offers makes the map easier to edit and the process more accessible for geographically distributed teams.
Start by mapping the high-level actions your user can take in the product from beginning to end as if you were telling a story.
For example: First, the user can log in, then the user can invite friends, then the user can visit the news feed.
Actions should be mapped left to right, in the relative sequence they will occur.
—
Try this:
Grab a stack of sticky notes.
Write down one activity you typically do in the morning before you leave for work. Now write down another on a different sticky note. Repeat the process until you have about four or five stickies.
Now try to organize those stickies in a line from left to right, starting with the first activity you do and ending with the last activity.
You’ve just mapped the high-level details of your morning routine! Now you’re ready to try the exercise as a way of describing what your product can do.
—
With software, users don’t always follow a linear sequence of actions. Don’t get too hung up on this. Just as sometimes you have your morning tea before you shower, and sometimes after, in the end what’s relevant is knowing that your morning routine is made of up fundamentally different activities than your workday or evening routines are.
Once you’ve horizontally mapped the primary actions of your product story, you should capture more specific details and variations on that action.
Here’s an example:
- Primary action: Login
- First method: Login using your email address and password
- Alternative method: Login using Apple ID
Arrange variations or added details vertically below the primary action to which they most relate, and in descending order of criticality or customer value.
If you’re new to software development, story mapping will help you visually connect with just how much detail goes into planning even “simple” products.
Slice it
In Agile software development, the goal of every sprint is to release a “potentially shippable product increment.”
This means you want to be thinking about delivering fully functional bits of your software (“whole stories”) with each release.
At the same time, you want to resist stuffing too many (or all) features on your story map into a single release.
This is where slicing the story map into multiple releases helps you to decide which features to ship in what order, and where “release planning” gets its name.
To slice your story map, simply draw a horizontal line below all the feature details you must include in the first release. This is easy because you already stacked the details and variations in descending order of priority or value.
When slicing, be brave enough to challenge (and then defer) items that can wait. This part is a bit like purging your closet. It’s hard to throw away the first couple items but once you get going you quickly become less sentimental and realize there’s a lot of blazers you just don’t need anymore.
I once waited over six months to ship a “forgot password” function in service of shipping a greater quantity of innovation features first. You can do that too!
You can slice your story map several times following the same method outlined above. This approach will show you how you can plan to ship continuous updates to your customers over some time. In some cases leaving a feature out of a release may only delay its launch by one or two weeks.
Time to Build
Another benefit of a digital tool like Stories on Board is that you can magically port all the stories from your map directly into software project management tools like Jira or Pivotal Tracker with a single button.
Now your team has everything they need to begin the product delivery process!
Learn about planning and developing better products using StoriesOnBoard and Trello:
Note: This article originally appeared in The R2D Method: Six Lessons for How to Get from Product Roadmap to Code Deployment.
About the Author Drawing from experience as an expert educator, thought leader, and product management consultant, Suzanne Abate’s hypothesis-driven approach identifies the right questions to ask and the best paths to discovering the answers. As the co-founder of TDF, a product coaching and consultancy based in Los Angeles, California, she’s coached enterprise organizations including AT&T, Target, Marriot, and Blue Shield, and has helped dozens of startups launch and scale their ideas in market. Suzanne’s built a career on expanding approaches, accessibility, and conversations in product management, and loves working with those who want to achieve great things. You might recognize her voice as the host of the 100 PM podcast, for which she is also the creator.