Release planning (part 2): Learn how to build a Product Roadmap

Why do we need a roadmap?

Whenever you take a road trip, you make a plan to get there, you choose specific routes and certain stop points to provision yourself or simply to rest. A roadmap is not so different. It is a visual representation of the Product Strategy, without it, you might derail from your objectives.

The roadmap is dynamic, so a living artifact, it doesn’t set in stone deadlines and neither the features, it represents the current knowledge (what you know so far and what goal you want to reach) and is constantly updated by input from other stakeholders and the current market conditions.

Think of it as a football game, the product roadmap represents a football formation and as a football formation, it is constantly in flux according to what the other team is doing ( read here market ).

I’ve mentioned briefly the product management vacuum in my previous post regarding the difference between a product owner and a product manager, here.

For us to have a brief overview of the input for the product strategy, I’m going to share here again the image of the product management vacuum.

As we can see, the Product Vision which is the goal of a Product Roadmap, is dictated by the Corporate/Business Strategy.

Having the business strategy in mind we define a roadmap and with this roadmap we will be able to:

• Align stakeholders on the Product Vision;
• Define the strategy on how this Product Vision is met;
• Make it transparent to everyone how you’re going to achieve value.

Prerequisites to a roadmap

A roadmap requires is the visual representation of a strategic plan and every strategic plan has 4 important components:

• Where we currently are? (Context)
• Where do we want to get to? (Goal)
• How do we get there? (Implementation)
• How do we measure our progress? (Metrics)

The first point is in regards to our current context: what is our product, what is our current market value, who are our competitors, who are our customers, what have we achieved so far.

The goal is our product vision, what problem we’re trying to solve, for which customers, what differentiates us from our competitors, and which future market share do we want to achieve.

The implementation part is tied directly to our release plan (a type of roadmap, read below), this is more focused on the WHAT part, meaning the actual solution together with…

Metrics: if the product vision is a subset of the overall business strategy, then the metrics are based on the release expressed either as SMART or as OKRs.

So going further with our prerequisites we will need:

1. Context: here you can use a metric based on your product current lifecycle stage you’re in ( read more here ) or combined analysis of Porter’s five forces (read more about it here and here), a SWOT analysis ( detailed in an upcoming post ) or as we’ve done in our below example, a combination of multiple indicators. Usually, business and financial metrics are provided by the business/corporate strategy, the metrics for your customer value you can take them from previous releases and product increments;
2. Goal: This is where you want to get, the product vision for a given timeframe, usually expressed as a statement with a model below ( MedicalApp example from part 1 here ):

Our vision for our product for next year is to get more engagement from our patients’ customer segment and because of that, our goals concentrate on the attainment of original specialized content by providing customer education and more doctor-patient interaction. Based on our vision and goals, our overarching strategy is to achieve a uniquely differentiated market position.

This strategy will enable us to focus on segments, where we will attain a market share of 25%, a 38% improvement over where we were at the end of this year. Our product investments will focus on targeting mobile technology, which will enable the flexible and rapid development of new features that allow us to deliver a profoundly distinctive user experience.

Given our forecast of increased competition in this area, we will focus more on offering the same features our competition offer and at the same time distinguishing our self with new technologies.

By doing so, our customer value proposition will allow us to improve our pricing power over the competition, with a 30% premium increase over other available products. Furthermore, because we will more effectively differentiate our products from the competition, we can direct our promotional investments to educate our customers through our promotional content and advertising programs, as well as enhanced sales training. With all of these, we expect to increase revenue by 36% over the next three years, with a corresponding increase in profitability.

Product roadmapping: example of Product Vision for our MedicalApp

3. Implementation: Here we’re going to adopt a forward-looking mindset, by focusing on WHAT we can do to reach our Product Vision mentioned in Step 2. Here is the place to document our release schedule by using a Release Roadmap or a Now, Next, Later Roadmap (examples under each section);
4. In this step, we will focus on those metrics that are mentioned in Step 2, and on the goals needed to reach our Product Vision, we define the leading indicators for each of our releases, such as we’ve done in our Goal Oriented Roadmap

Going forward with our Product Vision from step 2, mapped for the upcoming 3 years, we map our assumptions and define this strategy the same as we’ve done for step 1 above, but this time forward-looking.

Think of these metrics as lagging metrics for which we will define leading metrics in our roadmap examples below.

Because this is high level, you will want to review this and track progress on a quarterly basis.

Best practices

In order to succeed with the roadmap, there are some common guidelines that should be followed:

• The roadmap should be somewhere visible for everyone;
• It should be reviewed frequently, at least once per iteration, and updated if necessary;
• It should not present fixed dates, instead, use timeframes and ranges.

The act of setting up a roadmap, is more important than the actual roadmap itself. The process will make priorities clear and align everyone on the same strategy.

Not having fixed dates but rather frames will let you keep your flexibility in reaching a market date. When to release is also part of the strategy, as we will discuss below.

A note about dates

During this post I will mention dates and releases. It is important to understand that these do not represent a guarantee, nonetheless dates are important for some of our stakeholders, such as:

• Service and Support;
• Sales;
• Marketing;
• Management Sponsor.

They will have certain activities, such as scheduling a marketing campaign, driving sales and scheduling communication, assuring budgets, and so on.

Sticking to a roadmap is ideal, but along the way, experience has shown that things happen, keeping an open mind and adjusting and making compromises in the time, budget, scope trifecta is advised to keep as close as possible towards our business strategy goals.

Types and formats of Roadmaps

Roadmaps come in all shapes and sizes, they can have different names and show different things, but in regards with content and strategy, they roughly fall into groupings such as:

If we’re talking about strategy:

• Short-term;
• Long-term.

If we’re talking about the level of content:

• High-level;
• Low-level

Story Map

As we’ve seen in my previous post, a Story Map is a prioritization tool that has two dimensions and is user-focused. Each theme and epic is focused under a specific persona and then we begin breaking down stories for those epics. The stories are prioritized top to bottom, with the first few of them going under the first release as an MVP while the rest in subsequent releases.

This can be called a long-term low-level view, because we can tell for several releases into the future, which User Stories ( not features or epics or themes ) go into which release, meaning a very detailed representation of what needs to be done.

The problem with this approach is the level of granularity, so having US in releases will not help you focus on customer value/business value. Why? Remember the strategy that we’ve enunciated above? Let’s take an example macro-metric Channel and Customer Usage Index. We’re planning on launching a mobile application and have 20% of our current users migrated towards our mobile app.

Can you pinpoint exactly which US accomplishes a part of that goal? Exactly! Being so broken down into development stories, it will be hard to translate the leading metrics from epics to each subsequent story.

Another caveat about this approach, is that it cannot be used on its own, it is missing the time dimension. You cannot roughly say when the releases will be: in this quarter or the next.

Let’s make a new StoryMap for MedicalApp according to our strategy and vision:

As you can see, we’ve prioritized mobile development and premium contents according to our vision, also added later on, integration with social media networks and opened ourselves to a monetization scheme based on a referral program so that we boost our customer base.

But at the same time, you can notice that there are no metrics attached to the releases.

Now let’s look at how a Release Roadmap looks like with the above example.

Release Roadmap

The Release Roadmap is a long-term low-level view of the releases, that satisfies the vision for the Product Roadmap, within a year.

Here we can also put metrics attached to releases and also include the time dimension. Given the above, this focuses on Step 3 from our strategic planning, meaning: Implementation, the what part.

As you can see from above the releases have been prioritized from the Story Map, by using:

1. The velocity of the teams involved;
2. Quoted US with US points per Release in the Story Map;
3. The number of Sprints needed to do a Release.

Here if you ask yourselves how the roadmap was done, specifically why “Release 1” was made for 6 sprints, it was taken as an example.
But, to go forward and add detail to this example we will use the story map with the total User Story Points per release:

The velocity for our team for the last 5 sprints was between 20-24, so for each release we will have:

1. 112 / 20 (min velocity) = 5.6 ( rounded to 6 );
2. 80 / 20 (min velocity) = 4.4 ( rounded to 4 );
3. 48 / 20 (min velocity) = 2.4 ( rounded to 2 ).

The Release Roadmap is usually done for 3 to 6 months ahead, going with 6 sprints for each platform with one team with 20 points velocity minimum, we think we can deliver the MVP for each platform in the first two quarters.

Also, notice there are no metrics attached to this Roadmap as well. This can be covered later on with another type of Roadmap
( The Goal-Oriented Roadmap ).

Keep in mind the releases put down on the release roadmap are not set in stone, what matters is the Product Vision. If it respects it, keep it, if not pivot.

Now, Next, Later Roadmap

The Now, Next, Later Roadmap is focused on features, so you can tell this is a more short-term low-level focused roadmap.

It doesn’t contain any dates and it doesn’t contain any other metrics. Here’s how a Now, Next, Later might look for our MedicalApp example:

Also as you can see, there is no indication on how much effort this takes to be done, just an overall view of what needs to be done in the upcoming timeframe.

Goal-Oriented Roadmap

The Goal-oriented Roadmap or how is commonly known as GO Roadmap focuses on high-level goals. It tracks metrics and follows goals to be reached that follow closely the Product Vision.

The GO Roadmap doesn’t track features (so is not focused on output) but rather how these features and releases focus on the Product Strategy. (Outcome focused). It might or might not have dates. This type of roadmap might be used in tandem with another roadmap to further add detail to what needs to be done in order to attain our goals.

Conclusion

Any product roadmap is actually a visual representation of the business strategy. It helps by guiding and aligning the stakeholders on what needs to be done to attain specific goals from the business strategy. No single roadmap gives you a full picture and it is important to understand that they should be reviewed frequently and adapted based on the progress towards specific business goals.

Keep in mind that specific business goals are more important than keeping to a roadmap, so if on any stage of any roadmap you notice a deviation from the plan put in place, you will need to take corrective actions and pivot.

In a world of complex problems and a rapid marketplace, a plan is there only to give you a baseline from where to pivot if needed.

Useful Links

• A simple top-down representation of how Business Strategy is tied with releases;
• An informative read from Roman Pichler on building roadmaps;
• Roman Pichler’s book, “Strategize“;
• Steven Haines book, The Product Manager’s Survival guide