Introduction
Welcome back to The R2D Method, a guided series for how to implement the essential planning and delivery processes of successful software businesses.
This is lesson three of a six-part series.
If you missed lesson one (on product roadmapping) or the previous lesson (on how to write feature briefs), you can register here.
Today we’ll examine the last key activity of product planning:
Release Plans.
Lesson 3: Release Plans
A release is the launch of a new product or feature set into the market, or for use within your organization.
Releases can happen frequently (daily or weekly) or just occasionally (quarterly or annually).
Your release rhythm will depend on a few factors, such as the maturity and stability of your business, and what resources are available to you. The sophistication of your deployment process will also impact your release rhythm.
We’ll discuss code deployment best practices in lesson six.
There are many reasons for a release. 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 new features to current customers
- You’re releasing new features to new or different customer segments
- You’re re-releasing your current product using different technology (often called “replatforming”)
Different scenarios may prompt a product release, but not all scenarios require the same level of planning.
We’re going to focus this discussion on how to plan a “major” release, which we’ll define as “a new product or a major rebuild that renders much of the old experience and features obsolete.”
Where Do Release Plans Fit in the Product Planning Process?
A release planning session is an activity that follows from the product roadmap.
A feature brief is an essential bridge of information between the product roadmap and the release plan, and should ideally be drafted and shared before release planning.
However, it is possible to jump straight into release planning without first writing a feature brief.
If you’re a busy department leader, setting aside time to plan a whole product release might seem daunting and may be something you hope can happen without you. We don’t recommend this.
We know that nobody wants more meetings, but planning a release holistically is essential for establishing shared goals and shared knowledge with the delivery team that 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 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, which requires more time.
Start your release planning session by discussing (or revisiting) why the 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 in order to keep the room 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 one may require approvals before publishing a post to the website.
One set of data that will be helpful to have on-hand are 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 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 about 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 one and 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 we like for assessing feature value is the Kano Model, but simply categorizing your features as “high,” “medium,” and “low value” is fine too, just 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 in feature planning is to make choices that are good for both sides, as much as is possible.
Map it
We 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 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 login, 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 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 requiring too many (or all) features in your story map to be included in 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 made 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.
We 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 a period of time, and 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, and that’s where we’ll begin our next lesson.
—
Keep an eye on your inbox next week for Lesson 4: Epics and User Stories
Not yet registered for this course? Sign up here
Would you like us to guide your team through a remote story mapping session? Book here