Listen to the audio version of this article:

You Can’t See Further than the Next Three Months

A product roadmap should be a realistic forecast that states the specific value a product is likely to offer in the next 12 months.[1] Creating such a forecast is not always feasible, especially when you work on a new, innovative product.

If you can’t see further than the next three months, then do not use a product roadmap. Otherwise, your plan is likely to be wrong, which would lead to disappointed stakeholders and development teams.[2] In the worst case, they’ll lose trust in your ability to guide them.

Instead of building a roadmap, set a single, outcome-based goal for the next three months. The goal should state the positive impact you want to create for the users/customers and the business. An example for a healthy-eating product might be “help the users understand their eating habits and acquire an initial user base.” Use the goal to determine which features have to be implemented to create the desired outcome, for example, offering a healthy-eating dashboard and seamless integration with leading smartwatches. A practical way to do this is to focus the product backlog on the goal you’ve chosen.

Once you have achieved the goal, you will hopefully better understand how you can progress your product and be able to create a realistic roadmap.[3] If that’s not the case, check that you have a validated product strategy, on which you can base the roadmap.

You Lack a Validated Product Strategy

A common cause of teams struggling to create a realistic product roadmap is a lack of a validated product strategy. Before I explain what I mean by validated, let me briefly describe what a product strategy is.

A product strategy describes the approach you’ve chosen to achieve product success. It states the target group—the users and customers, their needs, the desired business goals, and the capabilities that will set the product apart from competing offerings.[4] A handy tool to capture the strategy is my Product Vision Board, which you can download for free together with a helpful checklist from my website.

A validated strategy is free of significant risks and assumptions. It is backed up by empirical evidence: You have relevant data to show that you have made the right strategic decisions and selected the right target group, needs, business goals, and standout features. Executing the strategy is therefore likely to result in a successful product.

A great way to validate a product strategy is to follow an iterative, four-step process. As I explain this approach in more detail in the article Product Strategy Discovery, I’ll just provide an overview here.

Start by selecting the biggest risk contained in the strategy—the uncertainty that must be addressed now so that you don’t make the wrong decisions and take the product down the wrong path. Second, determine how you can best address the risk you’ve chosen, for instance, by observing target users or building throwaway prototypes. Third, carry out the necessary work and collect the relevant data. Fourth, evaluate the results and use the newly gained insights to decide how to correct and refine the strategy. Follow this process until you’ve addressed all major risks.

With a validated strategy in place, you are in a great position to build a realistic, actionable product roadmap. There are two reasons for this: First, having carried out the necessary strategy discovery work, you’ve acquired the relevant knowledge to make effective roadmapping decisions. Second, the strategy forms the basis for building an effective product roadmap. The needs and business goals stated in the strategy help you select the right roadmap goals. You may even be able to derive the outcomes on the roadmap directly from the product strategy by breaking the needs and business goals into more specific subgoals, as Figure 1 shows.[5]

Conversely, if you don’t have a validated strategy, you lack the basis for developing a realistic, actionable product roadmap. If that’s the case, stop and carry out the necessary strategy discovery work. Then continue building the roadmap.

Stakeholders Dictate the Roadmap Content or View It as an Unchangeable Commitment

In my coaching work, I sometimes meet stakeholders who insist on getting specific features onto the product roadmap and who expect that their features will be delivered as stated in the plan.

Usually, there are two issues at play in this situation: First, the product manager/product owner lacks the necessary empowerment and finds it hard to say no to the stakeholders. Second, the stakeholders are used to a traditional planning approach. They see the product roadmap as a feature-based, fixed plan instead of an outcome-based one that is regularly reviewed and adapted.

My initial advice is to try and fix these causes: Work on your empowerment by growing your lateral leadership capacity and lobbying for more support from senior management, as I explain in the article Understanding Empowerment in Product Management. Additionally, use an outcome-based, adaptive roadmap like my GO Product Roadmap instead of a traditional feature-based plan.

But if this fails, then I recommend not using a product roadmap. Otherwise, you risk ending up with a Frankenstein product—a loose collection of features that might please the stakeholders but don’t create much value for the users and the business as a whole. What’s more, if the roadmap is seen as an unchangeable commitment, implementing it may result in a “death march” where the development teams regularly work overtime and end up being exhausted. Consequently, productivity drops, people’s health suffers, and software quality is compromised—which will make it harder to enhance the product in the future.

Instead of using a roadmap, set a three-month goal as recommended earlier, preferably together with the stakeholders. A collaborative approach offers three benefits. First, it increases the chances that the stakeholders will support the goal. Second, it helps you build trust, which increases your ability to influence and guide them. Third, it sets you on the path to adopting outcome-based roadmaps, as I explain in the article How to Get Started with Outcome-Based Product Roadmaps.

Notes

[1] The time frame stated applies to digital products. For hardware-based ones, you may require a larger period, say, 18 or 24 months.

[2] While a product roadmap is likely to change, it should be stable enough for the following one to three months. If the plan changes, say, every two weeks, the rate of change is too high. The roadmap is no longer a useful, sufficiently reliable plan.

[3] Additionally, you’ve taken the first step to using an outcome-based, goal-oriented product roadmap, as I explain in more detail in the article How to Get Started with Outcome-Based Product Roadmaps.

[4] The stand-out features are especially important for a revenue-generating product, as they help you correctly position it.

[5] I discuss the relationship between the product strategy and roadmap in more detail in the article Roman’s Product Strategy Model.

Listen to the audio version of this article:

Traditional vs Outcome-based Roadmaps

Before I share the four steps, let me briefly describe the main differences between a traditional, feature- and an outcome-based product roadmap. A traditional roadmap is essentially a list of features, which are mapped onto a timeline. Such a plan might work if there is little uncertainty, change, and innovation present, and you can correctly predict what the product should look like and do. But in today’s fast-changing digital product space, that’s hardly ever the case. Using a feature-based roadmap that fixes the product functionality for the next, say, twelve months therefore risks creating a product that offers the wrong functionality and creates little value for the users and customers.

Fortunately, a different roadmapping approach has emerged in recent years: outcome-based, goal-oriented product roadmaps like my GO Product Roadmap. Instead of determining features, you first and foremost consider the specific value the product should create—the outcomes it should achieve. These might include acquiring new users, reducing churn, increasing engagement, improving conversion, and reducing development time and cost by removing technical debt. To put it differently, instead of focussing on what needs to be delivered, you ask why it is worthwhile progressing the product.

However, I find in my coaching work that management and business stakeholders can be very attached to feature-based plans and expect to see roadmaps that state when a feature will be delivered. In such a situation, it can be a big ask to let go of detailed, feature-based plans and trust an outcome-based, goal-oriented product roadmap. If you find yourself in a similar situation, then apply the four steps, which are shown in the infographic below and explained in the remainder of this article. (You can download the infographic by clicking on it.)

Step 1: Set an Outcome-based Goal for the Next Three Months

To get started, set a single, outcome-based goal for the next three months. An example for an online shop might be “increase conversion by 5%.”[1] Make sure that the goal states the positive impact you want to make on the users/customers and the business. Avoid the pitfall of setting feature-based goals, such as “prioritise the search results” or “improve the search algorithm.” Think why, not what. Additionally, ensure that the goal is specific and measurable so that you can clearly tell if it has been met.[2]

Make sure you involve the key stakeholders and development team representatives in the goal-setting process. This helps you leverage their knowledge, it creates transparency and strong alignment, and it maximises the chances that they will follow the goal.[3] Aim to achieve consent. This means that nobody involved in the goal-setting process has any meaningful objections against the goal.

A great way to engage the individuals is to invite them to a collaborative workshop, which may take place onsite or online.[4] Ask a skilled facilitator to run the session especially when the attendees don’t know each other well and the level of trust is low. This frees you from having to facilitate and allows you to focus on setting the right goal.

Step 2: Use the Outcome to Determine the Features

With a specific, measurable, and outcome-based goal in place, determine the features that have to be delivered to meet the goal. A practical way to achieve this is to focus the product backlog on the outcome.

Start by removing any backlog items, which are not required to create the desired outcome. Delete or archive them. Then determine how the product has to change to meet the goal. Does the user experience have to be adapted? Do you have to add or change any functionality? Do you have to meet new or enhanced non-functional requirements including compliance standards? Are bug fixes and architecture refactoring work required to achieve the outcome?

Decline any feature requests that do not help you meet the goal. Use the outcome as your decision tool and stick to it—unless it becomes invalid. Don’t make the mistake of accepting a feature to please a stakeholder or avoid a difficult conversation. Saying no is part and parcel of a product person’s job, as I discuss in more detail in the article 5 Tips for Saying No to Stakeholders.[5]

Step 3: Review the Approach

At the end of the three months, review how the new approach has worked for you. What went well and what didn’t? Did you manage to meet the goal? How beneficial was using the agreed outcome to determine the product features? To what extent do management and business stakeholders support an outcome-based roadmap?

If the approach was somewhat but not entirely successful or the level of support is still low, repeat steps one and two and set another goal for the next three months. Consider what you can do differently this time to be more successful. Should you, for example, involve the stakeholders more closely in the goal-setting process? Should you do a better job of focusing everyone on the outcome? Should you be more ruthless and decline feature requests that don’t fit the goal?

If the approach was successful and management and stakeholders support it, you are ready to take step four.

Step 4: Build an Outcome-Based Product Roadmap

Having successfully used an outcome-based goal to determine the product features puts you in a great position to set outcomes for the next six to twelve months and build an outcome-based product roadmap using a template like my GO Product Roadmap shown below. You can download it together with a helpful checklist by clicking on the image.

The template above places the outcomes at the centre of the roadmap. It uses selected features. But these must help meet the goals. Additionally, they have to be coarse-grained and are limited to three to five capabilities per goal. You can learn more about using the GO Product Roadmap by watching this YouTube video.

But before you build your outcome-based roadmap, ensure that a valid product strategy exists. Such a strategy should state the users and customers who will benefit from the product, the needs the product will address, the business benefits it will offer, and the standout features which will set it apart from competing offerings—which is particularly important for commercial products. A handy template to capture the strategy is my Product Vision Board.

Once a valid product strategy is available, use it to determine the right roadmap outcomes. To achieve this, you have two options, as I explain in more detail in my book Strategize: First, you can derive the roadmap goals directly from the needs and business goals by breaking them into subgoals. Second, you can use your key performance indicators (KPIs) to discover outcomes such as increasing engagement and reducing churn—as long as these are aligned with the needs and business goals in the strategy.

Finally, don’t forget to involve the key stakeholders and development team representatives in the roadmapping work. As described in step one, invite the individuals to a collaborative workshop and co-create the product roadmap. This will help you make the right roadmapping decisions and generate strong buy-in.

Notes

[1] For simplicity’s sake, I use a business-focused goal as an example rather than a compound one that covers a user/customer and a business benefit. While I tend to prefer the latter, both methods work—as long you state the impact you want to achieve.

[2] If you use objectives and key results, OKRs, then you can view the goal as an objective, see my article OKRs and Product Roadmaps. Similarly, if you apply a Scrum-based process, you can regard the outcome as a product goal, as I discuss in the article Product Goals in Scrum.

[3] Involving people in the goal-setting process makes it more likely that they will work towards the outcome, as long as you attentively listen to their suggestions and concerns, as I explain in more detail in my book How to Lead in Product Management.

[4] If you work with an extended product team, which consists of the person in charge of the product, dev team reps, and key stakeholders, then invite the team members to the workshop, see my article Building High-Performing Product Teams.

[5] If you cannot decline a feature request, you lack the necessary level of empowerment to do an effective product management job, see my article 3 Empowerment Levels in Product Management.

Listen to the audio version of this article:

What are OKRs?

OKRs are a method for setting and tracking goals. The acronym stands for objectives and key results. The objective is the goal, which describes what you want to achieve. The key results state the specific criteria that have to be fulfilled to meet the objective.

To make this more concrete, let’s look at an example:

Objective: Grow the product management team.
Key result 1: Three product managers are hired.
Key result 2: The onboarding system is improved, and time-to-proficiency is reduced by 25%.
Key result 3: The product management processes are adapted to preserve the productivity level of the team.

As the example shows, OKRs are often written so that the objective is qualitative, and the key results are quantitative. Additionally, a small number of key results is commonly employed.[1] Please note that I don’t claim to be an OKR expert. But I experienced OKRs first-hand at Intel—where they were originally invented—when I worked for the company in the late 1990s.[2]

What makes working with outcome-based goals like OKRs powerful—and for some organisations challenging—is that they state what needs to be achieved but not how. Rather than handing a list of tasks to people, objectives are agreed. The individuals then determine how they can be met. This helps empower teams and prevent micromanagement.

What are Product Roadmaps?

A product roadmap is an actionable plan that describes how a product is likely to evolve.[3] Traditionally, it is a list of features that is mapped onto a timeline. Fortunately, in the last ten years, outcome-based, goal-oriented roadmaps have become more popular.

Below is an example of how such a product roadmap might be captured and the elements it might contain.

Figure 1 shows a specific goal-oriented roadmap template I developed, the GO Product Roadmap. You can download the template by clicking on the image above.

Let’s take a quick look at the roadmap’s five elements. The most important one is the goal, and it’s positioned in the middle of the template on the third row. It describes the specific benefit or outcome the product should achieve. Sample goals are acquiring customers, increasing engagement, and future-proofing the product by removing technical debt. The other four elements offer additional information: The one on the first row captures the date or the time frame when a goal should be met, for example, in the third quarter of 2024. The second row gives you the option to state a name. This is useful when meeting the product goal results in a new major release or product version, for instance, iOS 17.4 and Android 14.0. The fourth row lists the product’s features. These are the outputs that are required to meet the goal. The fifth and final row captures the metrics to determine if a product goal has been met.

You can learn more about the GO product roadmap by watching the video below.

Can You Combine OKRs and Roadmaps?

OKRs and outcome-based product roadmaps both assume that setting specific goals helps people do a great job. This similarity allows you to combine the two approaches. To do so, you have two choices. You can either work with an outcome-based roadmap like the one in Figure 1 and view the goal as the objective and the other roadmap elements as the key results. Alternatively, you can create an OKR-based roadmap. Figure 2 shows what such a plan might look like.

The structure in Figure 2 offers the same information as the one in Figure 1 except for the name element. This becomes clearer when we use both templates side by side.

Figure 3 contains an extract of a GO Product Roadmap for a new healthy-eating product.[4] The initial offering—the MVP—should help the users understand their eating habits and acquire an initial user base. It should be available in the third quarter of 2024 and offer two key features. The MVP is regarded as a success if the product is one of the top 15 diabetes apps six weeks after its launch. The OKR-based roadmap shows virtually the same information. It first states the goal, followed by the target time frame, the key features, and the success measurement.

As this example illustrates, you can happily combine OKRs and outcome-based product roadmaps, as long as the roadmap goals are SMART, that is, specific, measurable, achievable, relevant, and time-bound.[5]

So What?

What can we take away from the above discussion? First, understanding the connection between OKRs and product roadmaps can help you move away from feature-based plans towards goal-oriented ones—something I highly recommend.

If your company uses OKRs, you can argue that an outcome-based roadmap brings you in line with the goal-directed planning approach used throughout the business. You may even consider using an OKR-based roadmap like the one in Figure 2 if this makes it easier to stop using feature-based roadmaps. Be aware, though, that this might mean that you’ll have to work with quarterly roadmap goals.[6]

This does not necessarily have to be an issue, as I find that these goals often work well on roadmaps. But there are circumstances where you’d like to choose a shorter time frame like six weeks or two months as well as a longer one, for example, four months. The former tends to be the case when your product is young or experiences a lot of uncertainty and change. The latter applies when your product is in a steady state and benefits from incremental enhancements rather than bigger changes.[7]

Second, it directs your attention to the question of where the outcomes or objectives should come from. It’s not uncommon in my experience that stakeholders and senior managers determine the roadmap content: The individuals essentially tell the person in charge of the product what to put on their roadmap. This approach, however, is problematic. Not only does it disempower product people and product teams. It can also create a Frankenstein product—an offering that is a collection of unrelated features, offers a terrible value proposition, and gives rise to a horrible user experience.

A better way to determine the right roadmap goals is using an overarching product strategy, as Figure 4 shows.[8]

The product strategy in Figure 4 describes the approach you’ve chosen to achieve product success. It captures key decisions including the needs the product should address, the users and customers who should benefit from it, the business benefits it should generate, and the standout features that are required to set itself apart from competing offerings.[9]

The product roadmap takes the strategy as input and states how it will be implemented in the next, say 12 months. Its goals and objectives consequently have to be aligned with the strategy. To achieve this, you have two options—which I discuss in more detail in my book Strategize:

First, you can derive the roadmap goals directly from the needs and business goals by breaking them into subgoals. Second, you can use your key performance indicators (KPIs) to discover roadmap goals such as improving engagement and removing technical debt. In this case, make sure that the goals help you indeed make progress towards the overarching strategic goals.

Using a longer-term product strategy and deriving specific intermediate goals from it is not dissimilar to how OKRs are used to set organisational goals. The top-level OKRs are usually derived from the business strategy—or “mission” as it was referred to when I worked at Intel. If you apply a similar approach at your company, then this should help you mirror the organisational planning approach for your product and build a product roadmap that is based on the product strategy rather than individual stakeholder requests.[10]

TL;DR

Can you use OKRs on a product roadmap? Yes, most certainly. Should you use them in your plan? It depends. If it helps you move from feature-based to outcome-based roadmaps and embrace a goal-oriented product planning approach, then the answer is yes. Employing an OKR-based roadmap like the one in Figure 2 is likely to be beneficial for you. Otherwise, don’t worry. You can simply regard the outcome on the roadmap as the objective and the other elements as the key results—if OKRs matter to you and your organisation.

Notes

[1] See John Doerr, Measure What Matters, p. 7, and Christina Wodtke, Radical Focus, 2^nd ed., p. 101.

[2] OKRs were invented at Intel in the 1970ies and became more widely used after Google started to adopt them from 1999 onwards, see John Doerr, Measure What Matters.

[3] See Roman Pichler, Strategize, 2^nd ed., p. 146.

[4] For simplicity’s sake, Figure 3 uses only a single goal. See the article The GO Product Roadmap for a roadmap example with multiple goals.

[5] As I discuss in the article Should Product Roadmaps Have Dates, showing dates and specific time frames is usually helpful on internal roadmaps, which guide and align stakeholders and teams. If you work with a public product roadmap, then I advise using vague time frames such as in the second half of 2004 or in 2025.

[6] OKRs are usually set for a quarter, see Radical Focus, 2^nd ed., p. 102. A product strategy, in contrast, covers a longer period, for example, one to two years for digital products.

[7] That’s typically the case when a product has entered the maturity stage.

[8] Figure 4 shows part of my product strategy model.

[9] Note that I assume that the product strategy has been validated, that is, that its statements do not contain any significant risks and assumptions and are backed up by empirical evidence. See my book Strategize for more advice on strategy validation.

[10] See the article The Strategy Stack for advice on how to connect the business and product strategies.

Listen to the audio version of this article:

Overview

The GO Product Roadmap consists of five elements, as the image below shows: Date, name, goal, features, and metrics. The most important element is the goal: It describes the outcome you want to achieve or the benefit you want to provide. Sample goals include “acquiring new users,” “increasing conversion,” and “reducing cost.”

The checklist I’ve created offers criteria for each element as well as the entire roadmap. You can download the checklist together with the GO Product Roadmap by clicking on the image below. Applying the criteria will significantly increase your chances of creating a realistic, actionable product roadmap that clearly describes the value your product should create and that aligns stakeholders and development team members.

Before You Start

If you are new to the GO Product Roadmap, then I recommend reading the article The GO Product Roadmap and watching my YouTube video below before you apply the template and use the checklist.

Goal

Outcome-based: Clearly state why it is worthwhile to progress the product. Describe the specific value it should create, for example, “increase engagement,” “generate revenue,” or “reduce development time by removing technical debt.”

Specific: Make the goal—a.k.a. product goal—so detailed that you can tell what needs to be roughly done to achieve it and how long it is likely to take.

Measurable: Describe the goal so that you can determine if it has been met. To achieve, this you might state a target, for instance, “increase engagement by 5%.”

Prioritised: Place the goal in the right position on the roadmap considering, for example, its semantic dependencies to the other goals or its cost of delay.

Single: Choose a single goal to effectively align and guide people. Avoid using multiple goals that are worked on concurrently.

Date

Appropriately detailed: For an internal roadmap, state a target date or a specific time frame to communicate when the goal will be met. For instance, “1^st February” or “Q1.”

For an external, public roadmap, use large, coarse-grained time frames, for example, “first half of 2024” or just “2024.” Alternatively, don’t show any temporal information and remove the row.

Realistic: Ensure that the date or time frame stated is achievable—without sacrificing sustainable pace and overworking people.

Metrics

Precise: Clearly state how you will be able to tell if the goal has been met. Say you want to increase engagement by 5%. How can you then determine that this goal has been achieved? Will you, for example, measure daily active users? And if that’s the case, will the figure include unique new users and returning ones?

Time-bound: Say when you will be able to find out if the goal has been met, for instance, “one week after the software is released.”

Features

Goal-directed: Each feature must be required to meet a product goal on the roadmap.

Coarse-grained: The features describe big product capabilities, which act as placeholders for specific functionality. Do not state any product details such as user stories. (These are captured in the product backlog).

Focused: Only sketch those features that are crucial to meeting the goal. Limit their number to three to five per outcome.

Name

Relevant: Choose a name, which communicates the essence of the work carried out. This is helpful especially when meeting the goal results in a new product version or major release.

Memorable: The name is easy to remember.

Overall Criteria

Connected: Ensure that the product goals on the roadmap are connected to the product strategy and the product backlog. They should help you meet the needs and business goals in the strategy, and they should direct the product backlog content: The backlog items should help you meet the respective product goal.

Adaptive: The roadmap is regularly inspected and adapted, at least once every three months as a rule of thumb.

Shared: Everyone who uses the roadmap has a shared understanding of it and supports the plan. A great way to achieve this is to collaboratively create and update the roadmap.

Actionable: The roadmap can be actioned, and it does not contain any speculative information. You can achieve this by basing the plan on a validated product strategy, not being overambitious, and only planning as far ahead as you can realistically see.

Listen to the audio version of this article:

1 The Product Roadmap is a Feature-based Plan

Traditional product roadmaps are usually output-focussed plans that map a list of features, like registration, search, and reporting, onto a timeline. Such a roadmap essentially states when a piece of functionality will be delivered. This can be reassuring for customers and stakeholders. But it has the following three drawbacks:

1. A feature-based roadmap can give rise to and strengthen a feature-factory mindset where adding features is more important than creating value and making a positive impact on people’s lives and the business.
2. Focussing on features risks turning the roadmap into a tactical plan that overlaps with the product backlog, especially when fine-grained features are used. This makes the roadmap harder to understand, and it increases the effort to keep it up to date.
3. A feature-based product roadmap is easily mistaken for a commitment rather than a high-level plan that is likely to change. This will not only lead to disappointed stakeholders. It will also limit your ability to experiment and learn, to run sprints and discover the best way to address the user and customer needs and create value for the business.

You can avoid these drawbacks by using a different roadmap type: a goal-oriented or outcome-based product roadmap. As its name suggests, this roadmap focuses on product goals and outcomes, such as acquiring customers, increasing engagement, and future-proofing the product by removing technical debt. Selected coarse-grained features might still be used, but they are now dependent on the goals: Every feature must serve a goal and be required to create a specific outcome.

A handy tool to create a goal-oriented roadmap is my GO product roadmap, which you can download for free by clicking on the image below.

2 Roadmap Goals are Features in Disguise

While goal-oriented roadmaps can be very beneficial, they are not always applied effectively. A common mistake I see product people make is to use product goals that are features in disguise. Say that I am about to create a product roadmap for a healthy-eating product. Would the two statements “measure calorie intake” and “determine blood sugar level” then qualify as product goals? I don’t think so. In my mind, they describe product capabilities or features, and they characterise the solution. They do not state why it is worthwhile to progress the product.

Therefore, be careful not to mix up goals and features. Ensure that your product goals always capture the desired outcome the product should create and not the output. A good test to understand if a product goal describes an outcome is to ask the why question. For example, I could ask myself why it would be helpful to measure calorie intake. The answer would then reveal the true goal, such as “help the users improve their eating habits.”

3 Stakeholders Determine the Roadmap Content

Do your stakeholders ask you to add specific features to the product roadmap? If that’s the case, you are not alone. It’s not uncommon that product roadmaps are driven by stakeholder requests and that individual stakeholders want to have “their” features included.

While it is important to actively listen to the stakeholders, you should not allow them to dictate the roadmap content. Your job is not to please the stakeholders, but to achieve product success. If you say yes to every request, you are in danger of creating a Frankenstein product—a product that is a collection of unrelated features, offers a weak value proposition, and gives rise to a poor user experience.

Decline stakeholder requests if they aren’t aligned with the product strategy. If they are then look for a product goal that the feature supports. If there is none, then either adjust the plan by amending an existing goal or introducing a new one, or reject the feature request. This, of course, assumes that you are adequately empowered and that you have the final say on strategic product decisions.

4 The Person in Charge of the Product Creates the Roadmap on Their Own

Another common roadmapping mistake I witness is the opposite of the one just described: the person in charge of the product creates the roadmap on their own without any input from the stakeholders and development teams.

This approach is problematic for the following three reasons:

1. It does not leverage the creativity and knowledge of the stakeholders and development teams. This is likely to result in a product roadmap that is suboptimal or wrong.
2. It risks creating a plan that is not clear to the stakeholders and development team members, that lacks a shared understanding, and that causes misalignment.
3. People are less likely to support a product roadmap if they haven’t had the opportunity to contribute to it. In the worst case, the stakeholders and development teams pay lip service to the plan, go off in different directions, and follow their own goals.

You should therefore adopt a collaborative approach where you involve the key stakeholders and development team members in creating, reviewing, and updating the product roadmap, preferably in the form of collaborative workshops. Strive to come up with a plan that helps maximise the value your product creates and at the same time, attracts as much support as possible, as I discuss in more detail in my article Making Effective Product Decisions.

5 The Roadmap is Not Systematically Connected to the Strategy and Backlog

While the product roadmap is a plan in its own right, it is a mistake to create and manage it in isolation. This would result in a roadmap that is not aligned with the product’s value proposition and business goals and in a product backlog that is not linked to the roadmap. This, in turn, can lead to inconsistent and wrong product decisions: Strategic decisions don’t direct tactical ones, and insights from the development work don’t help progress the roadmap.

My product strategy model shown below positions the product roadmap between the strategy and the backlog: The roadmap states how the strategy will be implemented in the coming months, and it directs the product backlog. The former is achieved by translating the needs and business goals stated in the product strategy into product goals. The latter is enabled by using the next product goal to focus the product backlog.

6 The Roadmap is a Fixed Plan

Some people mistake the product roadmap for a rigid plan that must be executed. But any roadmap is based on what is currently known. As you start implementing it and learn more about how to best meet the user, customer, and business needs, the product roadmap is likely to change. This is a good thing: It helps you maximise the value the product creates and offer the best possible product—instead of blindly following a plan that might be outdated. You should therefore review and adapt the roadmap on a regular basis.

To do so, consider any product strategy changes, the development progress made, and larger product backlog adjustments that may affect the roadmap. Assess the product roadmap together with the key stakeholders and development team members at least once every three months, as a rule of thumb. Consider combining the strategy and roadmap reviews to ensure that the two plans stay closely aligned and minimise the time spent in meetings, as I discuss in more detail in my book Strategize.

7 The Roadmap is Speculative

As useful as a product roadmap can be, there is no point in creating a speculative plan that is built on wishful thinking rather than empirical evidence. This would most likely result in disappointment and failure. To maximise the chances of creating a realistic, actionable roadmap, you should first create and validate a product strategy, as the picture below shows. This includes systematically addressing the key assumptions and risks contained in the strategy and collecting data that shows that you have chosen the right target group, needs, stand-out features, and business goal. To put it differently, do not create a product roadmap if you haven’t got a validated product strategy in place.

Additionally, only look as far into the future as you realistically can. Don’t use a roadmap if you cannot see beyond the next product goal—which can happen when you work on a brand-new, innovative product. In this case, only use the one product goal that you have identified. As you work towards this goal, you will hopefully better understand how you can progress your product in the future and be able to create a realistic product roadmap.

8 The Roadmap is Overambitious

It can be tempting to create an ambitious plan that impresses the stakeholders and secures support and funding. But a product roadmap with unrealistic goals can turn the development effort into a “death march.” The development team members regularly work overtime, are permanently stressed, and end up being exhausted.

Consequently, creativity, motivation, and productivity drop, and people’s wellbeing and health suffer. Additionally, more errors and mistakes occur, and software quality is often compromised making it harder and more expensive to update the product in the future. You should therefore do your best to ensure that your roadmap is realistic and that it supports sustainable pace—that the team members can implement it without being overworked, losing motivation, and falling ill.

The best way to develop such a product roadmap is to involve the development team members in the roadmapping work, preferably in the form of collaborative workshops, as mentioned above. Listen to their views with an open mind, and don’t pressurise them to agree to the roadmap contents. Instead, take their concerns seriously and iterate over the plan and adapt it until it has become feasible.

9 The Roadmap is Mistaken for a Release Plan

Some product roadmaps forecast how a major release or a new product version is developed. But that’s a mistake in my mind, as the roadmap is the wrong tool for this job. A development effort is best managed by a release plan, for example, a release burndown chart.

The burndown chart helps you track the progress from sprint to sprint and it allows you to anticipate if a specific product goal can be met on time and budget—or how long it will take and how much it will cost to do so. This helps you guide the work of the development team and make the necessary adjustments, such as, removing functionality from the product backlog. In other words, a release plan helps you maximise the chances of meeting a specific product goal.

The product roadmap, however, states how a product is likely to evolve over a longer time frame. It is not based on the product backlog but on the product strategy, and it contains several product goals. Therefore, don’t confuse the two plans but use separate artefacts to capture them, as I discuss in more detail in my article The Product Roadmap and the Release Plan.

10 The Right Product Roadmap Tool is What Matters Most

A final mistake I see product people make is to believe that the right tool will address their roadmapping challenges. A while back I was working with the product management team at a large publishing company. The team lacked an effective product roadmapping approach. But instead of acquiring the relevant knowledge and discovering the right roadmapping practices, the team tried to shortcut the process by licensing a powerful roadmapping tool. As they lacked the relevant expertise, they were not able to customise the tool to their needs and failed to take advantage of it. As Grady Booch once said, “A fool with a tool is still a fool.”

I therefore recommend that you establish a product roadmapping approach that works for you before you decide which, if any, specialised roadmapping tool is right for you. To get started, choose a simple tool that is easy to use and that allows the stakeholders and development team members to view and contribute to the plan. This might be a PDF document, an electronic spreadsheet, or the collaboration tool you use at your company.

Listen to this article:

Overview of the Learning Roadmap

Like a modern product roadmap, a learning roadmap states the specific outcomes or benefits you’d like to achieve to become a more competent product person, and it captures them in form of learning goals. These help you direct your learning efforts, track progress, and measure how much you have learnt. To make these ideas more concrete, let’s look at a sample learning roadmap.

The roadmap in figure 1 is based on my GO product roadmap template. It contains the following four rows: [1]

• The first row describes when the learning goals should be met for the next 12 months. I’ve chosen quarters in the sample roadmap above, but you can use shorter time frames, of course, if you can meet your learning goals more quickly.
• The second line names the skills areas the learning goals belong to, which I’ll cover in more detail in the next section. For the first two quarters, the area is strategy; for the last two, it is leadership.
• The third row contains the most important information. It lists the learning goals you want to achieve. The first goal is about creating a new strategy, the second one talks about the product life cycle model, the third one covers decision-making, and the last one addresses active listening.
• The fourth and final line states how you intend to meet the learning goals. In the roadmap in figure 1, I listed the key topics to be addressed and the learning measures that will be used to acquire and deepen the skills. Note that you may want to make the measures as specific as you can and state, for instance, the title of the books you intend to read.

A learning roadmap like the one above offers four benefits: First and foremost, it gives you a goal-directed plan that focuses your learning efforts. Many learning plans I have seen were lists of learning measures. They lacked clear, achievable learning goals that built on each other and described a meaningful learning journey. Second, a learning roadmap allows you to leverage your product roadmapping skills and use them to create an actionable learning plan. For example, the guidelines I have developed for the GO product roadmap template directly apply to the roadmap in figure 1. Third, capturing the plan as a roadmap concisely describes the learning path you want to take and nicely visualises it. Fourth, a goal-oriented, outcome-based roadmap is compatible with OKRs. You can view the goals as objectives and the dates, topics, and learning measures as key results. This can help you tie individual learning goals to team and department goals.

Creating the Learning Roadmap

To build a learning roadmap, take the following three steps. First, reflect on your current product management skills and determine any gaps and shortcomings in your current skill set. Second, identify the right learning opportunities. Third, derive the right learning goals, put them on your learning roadmap and add the additional information. Let’s look at these steps in more detail.

➤ Step 1: Understand the strengths and weaknesses in your product management skill set

To analyse your current product management skills, I recommend using the following three subsets: Tactical skills, strategic skills, and leadership skills, as the following picture shows.

The tactical skills in figure 2 include the ability to create user models and personas; stock, prioritise, update, and refine the product backlog; capture user stories; apply the right solution validation techniques, for example, product demo, usability test, and early release; and have a rough understanding of how the product is designed and architected.

The strategic skills comprise the capabilities to create, validate, and evolve an effective product strategy; develop, review, and update an actionable product roadmap; use the right KPIs; choose the right business model and create a financial forecast.

The leadership skills, finally, include the ability to empathise even with seemingly difficult users and stakeholders; earn people’s trust and build strong connections; to actively listen to users, stakeholders, and development team members; to set the right goals—from the product vision to individual sprint goals; to resolve disagreement and conflict; and to effectively involve stakeholders and dev team members in product decisions.

As (digital) product management is a diverse and comparatively young profession, it is completely normal to have gaps or shortcomings in your product management knowledge and skill set. You might find, for instance, that you know what information an effective product strategy should contain but that you are not able to create such a plan on your own. If that’s the case, then don’t feel bad. Instead, recognise that you’ve just discovered a learning opportunity that will help you become an even better product professional.

➤ Step 2: Select the right learning opportunities

Once you understand your current skills, decide which learning opportunities you want to take. While I generally believe that it is helpful to acquire a balanced product management skill set and cultivate tactical, strategic, and leadership capabilities, I recommend that you use your current job as well as any career progression plans you might have to determine the right learning goals. Identify the skills that will help you be even more successful in your current job and/or allow you to take on a new role. For instance, if you want to move into a more senior role, you are likely to benefit from strengthening your strategy and leadership skills. Then compare the desired skills to your actual ones; select those learning opportunities that will help you be more successful in your current or new role or in the new one.

➤ Step 3: Create the learning roadmap

Finally, formulate specific and realistic learning goals, based on the learning opportunities identified. Don’t be over ambitious: You should be able to achieve the learning goals if no unforeseen events unfold. Add the goals to your learning roadmap and order them so that they build on each other and a clear learning path becomes visible. Then determine time frames, topics, and learning measures and include them on the plan. You are now ready to embark on your new learning journey.

Putting the Plan into Action

“Unless commitment is made, there are only promises and hopes; but no plans,” Peter Drucker once said. Having a plan is all well and good. But if you don’t follow it, it is useless.

The issue is, of course, that as the person in charge of the product, you have plenty of other tasks besides meeting your learning goals. There is a product that has to be managed, sales and support queries that have to be answered, a product roadmap and a product backlog that have to be updated, questions form development team members that have to be addressed, and stakeholder requests that have to be dealt with, to name just a few other common duties. It’s therefore easy to de-prioritise or neglect your learning goals in order to make time for other, more urgent tasks. Don’t make this mistake. You’ll hamper your own professional development and most likely be a less productive and effective product person in the future.

Instead, block time in your calendar to carry out the relevant learning tasks, especially when they involve some form of self-study like reading a book or a blog post and watching a video. I recommend setting aside at least one hour per week. Ringfence this time and only sacrifice it in truly exceptional circumstances.

Additionally, reflect on your learning progress at least once per month. Review how much headway you’ve made towards the current learning goal and update the learning roadmap if that’s required. This will help you successfully complete your learning journey and become an even better product professional.

[1] If you’ve used the GO product roadmap template before, you might notice that the learning roadmap in figure 1 does not state any metrics. If you would like to use them, then simply add a fifth row to your learning roadmap and capture the measurements that allow you to tell if a learning goal has been met.

Listen to this article:

Goal-oriented (a.k.a. Outcome-based)

Traditionally, product roadmaps are output-focussed plans that map features like registration, search, and reporting onto a timeline. Such a roadmap essentially states when a piece of functionality will be delivered. This can be reassuring for customers and stakeholders, as the individuals believe that they know when their features will be delivered. But this approach has three drawbacks:

First, a feature-based roadmap makes it hard to secure agreement and create alignment, as stakeholders often compete to get their feature on the roadmap. Second, it overlaps with the product backlog, especially when detailed features are used. This makes the product roadmap more susceptible to change and it increases the effort to update it. Third, the features are sometimes regarded as a commitment rather than a part of a high-level plan that is likely to change. This limits your ability to experiment and learn, to discover the best way to address the user and customer needs and create value for the business.

I therefore recommend applying a different product roadmapping approach and using goal-oriented roadmaps, which are also called outcome-based. As their name suggests, these roadmaps focus on product goals or outcomes such as acquiring customers, increasing engagement, and future-proofing the product by removing technical debt. The goals state the specific value a product is likely to create and therefore communicate why it is worthwhile to progress it. This helps align the stakeholders and development teams, as I discuss below, and acquire a budget if required. Lastly, goal-oriented roadmaps are compatible with objectives and key results (OKRs): You can think of the goals as objectives and the other roadmap elements as the key results, as I explain in my article OKRs in Product Management. These benefits make goal-oriented, outcome-based product roadmaps preferable to traditional, feature-focused plans, especially for digital products that exhibit uncertainty and change virtually across their entire life cycles.

If you are looking for a template to create a goal-oriented roadmap, then try my GO product roadmap shown below.

In addition to goals, the template above contains dates or time frames, names, features, and metrics. Note that the features depend on the outcomes: Each feature must help meet a goal and achieve the desired benefit. What’s more, the goals are the primary roadmap elements and are used to secure agreement. You can find more information about the template in my article The GO Product Roadmap.

Shared

No matter how well thought-out your product roadmap is, it is worthless if the key stakeholders and the development team members don’t understand and support it. A great way to achieve a shared roadmap is to involve the individuals in the product roadmapping decisions, preferably in the form of a collaborative workshop—be it online or onsite.

Note that collaborative roadmapping does not mean that everybody gets their way or is necessarily super happy with every single decision. It means leveraging people’s expertise to create a product roadmap that maximises the value the product creates and that attracts as much support as possible. While it’s important that you cultivate an open mind, attentively listen to the ideas and concerns of the stakeholders and dev teams, and empathise with them, you should not allow the individuals to tell you what to do. Otherwise, your roadmap may end up being a weak compromise rather than a compelling plan that helps create the desired value for the users and the business.

Have the courage to say no and ensure that the roadmap tells a coherent story about the likely growth of your product. Consider asking your Scrum Master or agile coach to facilitate the workshop and to ensure that everybody is heard and nobody dominates, assuming that a Scrum Master is available. This is particularly helpful when the attendees are new to collaborative decision-making and when they haven’t worked together before. (See my article Making Effective Product Decisions: Tips for Deciding with Stakeholders and Dev Teams for more information on collaborative decision-making.)

Actionable

For a product roadmap to be effective, it must be actionable. The best way to achieve this is to base the plan on a validated product strategy, a strategy whose key assumptions have been tested. Such a strategy should state the user and customer needs, the target group, the product’s stand-out features, and its business goals. Before you develop a roadmap, you should therefore create and validate a product strategy, as the following picture shows.

Additionally, you will have to choose a realistic time frame, a period for which you can anticipate the likely growth of your product without resorting to speculation. My recommendation is to limit the roadmap of a digital product to the next six to twelve months and to regularly review and update the plan—once per quarter as a rule of thumb.

Finally, make sure that your product roadmap does not contain too much detail. Adding, for example, epics and user stories, is a bad idea, as it blurs the line between the roadmap and the product backlog. What’s more, it results in a product roadmap that is difficult to understand, prone to change, and comparatively difficult to manage. You should therefore view your roadmap as a strategic plan, focus it on outcomes and goals, and use it to describe your product’s overall journey. Let the product backlog capture the product details, as the following picture shows.

You can find more information the right relationship between the two artefacts in my article The Product Roadmap and the Product Backlog.

What Release Planning Entails and Why It Matters

While release and release planning are common terms, I find that different individuals attribute different meanings to them. I regard a release as a version of a product, for example, Mac OS X Catalina and Windows 10. Releases come in two flavours: major releases, like iOS 13, and minor releases, such as iOS 13.3.

Release planning is the process of determining the desired outcome of one or more major releases and maximising the chances of achieving it. This involves the following:

• Establishing clear, specific, and measurable goals. that describe the outcomes or benefits your product should create. I call these goals product goals (and sometimes release goal). I like to capture them on a product roadmap.
• Determining the work to be done. This typically involves the development team providing rough, high-level estimates.
• Understanding date and budget constraints: Are there any hard deadlines that must be met, or is the budget fixed?
• Monitoring progress from sprint to sprint and making adjustments as required. In Scrum, release planning is carried out iteratively, often at the end of a sprint when it’s clear how much the progress was made.

Release planning enables organisations to make informed investment decisions; it sets expectations, aligns stakeholders and development teams; and it allows product people to guide the work of the dev team.

It is therefore in your best interest—as the person in charge of the product—to make sure that release planning is effectively carried out. This requires you to actively engage in the work, rather than delegating it to the development team or Scrum Master.

Use a Product Roadmap to Plan Multiple Releases

Release planning takes place at two levels: across several product versions (major releases) and within a single one. The former can be nicely done with a product roadmap. My preference is to work with a goal-oriented roadmap, like my GO Product Roadmap shown below, that states the desired benefits or outcomes of each major release for the next 12 months. Sample goals include acquiring new users, increasing conversion, reducing cost, and removing technical debt to future proof the product.

The goals on your product roadmap should tell a compelling story about the likely development of your product. They should describe the journey you want to take it on in order to create value for the users and the business, as I explain in more detail in the article “Product Roadmap Prioritisation”. Such a roadmap provides a continuity of purpose and ensure that individual releases build on each other thereby progressing and enhancing the product in a systematic way. What’s more, the roadmap goals help you focus the product backlog by limiting its content to items that are necessary to meet the next product goal.

But don’t forget to regularly review the product roadmap—at least once every three months, as a rule of thumb. As you learn more about the development team’s ability to make progress and better understand how to best meet the user and business needs, you will need to update your roadmap. This ensures that the plan stays actionable and provides the necessary guidance to the stakeholders and dev team.

Prioritise the Success Factors for Your Releases

In an ideal world, the development team will deliver all the releases on the product roadmap on time and on budget. But in reality, unforeseen things do happen. The development progress may not be as fast as anticipated, for instance, or one of the technologies may not work as expected.

To maximise the chances of success, I recommend that you prioritise goal, date, and budget for the releases captured on your product roadmap. One way to do this is to determine the impact of not (fully) meeting a goal, missing the desired release date, and exceeding the budget. Then fix the most important factor—the factor that would cause the biggest damage if you don’t adhere to and therefore has the biggest impact on the success of the product. Try to protect the second most important factor, the one that would create the second biggest damage. Finally, be flexible with the third one, the factor that has the least impact on the success of a major release.

You might have noticed that I haven’t mentioned quality. There’s a reason for it: Quality should be fixed and not be compromised. Otherwise, responding to user feedback and changing market conditions and quickly adapting your product will be hard, if not impossible.

Employ the Right Estimation Approaches

Estimating the cost of the releases on your product roadmap is helpful to acquire the necessary budget or, if your budget is fixed, understand if the roadmap is realistic and actionable—if the development team can actually implement it. Rough, high-level estimates are usually sufficient to meet this objective.

To come up with the estimates, draw on your experience of developing similar products or previous versions of the same product; consider whether enough people with the right expertise are available in your company, or if you will have to hire or contract people. This should give you an indication of the likely labour cost required. Then add the cost for facilities, infrastructure, materials, licenses, and other relevant items. Carry out this exercise together with the development team.

If you believe that the resulting estimates will be too vague, consider the alternative: Breaking the roadmap features upfront into epics and user stories will result in a long, detailed product backlog that is difficult to adjust and maintain. Additionally, this process can take days—and in some cases weeks—in my experience. And while you will get more detailed estimates, they will not be accurate at this stage.

Once you have secured the necessary budget and ensured that the releases on your roadmap are realistic, take the next step and stock the product backlog. As I explain in the article “The Product Roadmap and the Product Backlog”, I like to focus the backlog on the upcoming release and the next roadmap goal. To follow this approach, derive epics from the features that belong to the appropriate goal. Then explore which additional pieces of functionality the release has to offer and add them as epics to the product backlog. Finally, prioritise the items and refine the high-priority ones. This should result in a concise, compact backlog that is comparatively easy to adapt and that offers enough ready, high-priority items. Don’t forget to involve the development team in this exercise.

Additionally, ask the team to estimate the product backlog items. This might be done by using story points and Planning Poker, as explained in Mike Cohn’s book Agile Estimating and Planning.

Use a Release Burndown Chart to Track Progress

The release burndown chart is a simple yet powerful tool to track and forecast the progress for a release. Despite its usefulness, experience tells me that many Scrum product owners don’t use the burndown. But creating the chart is simple. Start by asking the development team to estimate the total amount of the product backlog items that should be part of the release. Rough, high-level estimates are sufficient. Then draw a coordinate system that takes into account time, captured as sprints, and effort in the product backlog, which might be expressed as story points.

The first data point is the estimated effort before any development has taken place. To arrive at the next data point, determine the remaining effort in the product backlog at the end of the first sprint. Then draw a line through the two points. This line is called the burndown. It shows the rate at which the effort in the product backlog is consumed. It is influenced by two factors: changes in the product backlog and velocity, which is the development team’s ability to make progress. Extending the burndown line to the horizontal axis allows you to forecast when the development effort is likely to finish, or if you are likely to reach the product goal and deliver all relevant product backlog items at a specific date.

The release burndown chart above shows two lines. The solid line is the actual burndown. It documents the progress to date and the effort remaining. The dotted one is the forecasted progress based on the burndown experienced so far. Notice that the burndown in the second sprint is flat. This might be caused by new items being added to the product backlog or the dev team revising estimates.

To achieve a forecast that is as accurate as possible, try the following three tips:

1. Base your forecast on a trend rather than a single sprint. This usually requires you to run two to three sprints before you can create the first forecast for a release.
2. Consider how representative the burndown of the past sprints is for the remaining sprints. In the example shown above, the second sprint has a flat burndown. This might be due to more items being added to the product backlog based on the first sprint review meeting or the dev team re-estimating items. To get the forecast right, it would be worth considering how likely it is that another flat burndown will occur again and to which extent you should account for it. If you decided that it was highly unlikely to reoccur, your forecast in the sample chart above would probably be steeper.
3. Make sure that you prioritise the product backlog by risk, particularly in the early sprints. This makes it more likely that the backlog changes in the first few sprints and then starts to stabilise. This makes forecasting the remainder of the development effort easier and results in a more accurate forecast.

If the forecast shows that you are off-track, that the burndown is slower than anticipated, then determine the causes. For example, the development team might lack some crucial skills, the team might be too small, a technology might not work as expected, you might have been too optimistic, or the initial estimates might have been wrong. Once you’ve identified the main cause, decide how to respond. The prioritisation of goal, time, and cost recommended above will help you with this.

Note that if you have to push out the release date or make a bigger change to the goal of the release, this may have an impact on your product roadmap and require you to adjust it.

Make Release Planning Collaborative

Release planning is best done as a collaborative effort in my experience by involving the stakeholders and the development team, as the picture below illustrates. To do so, schedule regular roadmapping sessions, possibly as part of your strategy review process and invite key stakeholders and development team members. Additionally, update and discuss the release burndown chart in the sprint review meetings where the same individuals should be present.

This ensures that the longer-term and short-term release planning decisions are made with the input from the stakeholders and dev team. This tends to lead to better plans, stronger alignment, and increased commitment to implement the decisions.

Before You Start Prioritising …

Before you order the roadmap items, double-check that you have a validated product strategy in place. You should be able to confidently say why users would want to use your product and why it is worthwhile for your company to invest in it. In other words, you should have valid answers to the following questions:

• Which user problem will the product solve, or which benefit will it provide?
• How will it create value for the business? For example, will the product directly generate revenue, help market and sell another product or service, reduce cost, or develop the brand?

If you haven’t nailed the answers, then do not continue the roadmapping effort. Instead, carry out the necessary product discovery and strategizing work. Otherwise, your roadmap may be built on false assumptions. Getting the prioritisation right will then be virtually impossible.

Create a Compelling Narrative

To prioritise the product roadmap, consider in which life cycle stage your product is. As long as it hasn’t reached maturity, a product has to constantly move forward: initially to get to launch, then to reach product-market fit, and finally to sustain growth.

At these life cycle stages, your product roadmap should tell a convincing story about the likely development of your product; it should describe the journey you want to take it on in order to create the desired value for the users and business. To get the prioritisation right, take the following steps:

• Determine how you can meet the user and business goals stated in your product strategy. What is the best way to achieve them? How can you break them down into smaller, intermediate goals?
• Order the newly created goals so that each one is a logical progression, a further step towards the overall user and business goals, considering any dependencies between the goals.

For a brand-new product, this might mean that you start with user acquisition followed by activation, retention, and finally revenue generation, depending on your product’s underlying business model. For a product in the growth stage, you might find that you first have to remove technical debt before you can enhance the user experience and increase conversion.

If there are items that were on the product roadmap prior to the prioritisation, then check if they help you reach any of the newly created goals. If that’s the case, then assign them to the appropriate objective. Otherwise, either discard the item or investigate if changing the goals to accommodate the items would be beneficial. A cost-benefit analysis might help you with this.

Whatever you do, make sure that your roadmap tells a cohesive, meaningful story that clearly communicates how the product will create value.

Determine the Cost of Delay

Once your product has entered the maturity stage, you usually don’t want to take it on another big journey, unless you decide to extend its life cycle. Instead, you stay where you are, protect your product’s position, and maximise the return it generates.

Consequently, there are often smaller, unconnected goals that need to be addressed, like sustaining engagement or preventing churn by offering incremental enhancements or bug fixes. But these objectives often lack clear connections, and they don’t form a logical sequence or narrative.

Faced with such a challenge, I recommend using cost of delay to get the prioritisation right. To put it simple, ask yourself how big the loss or severe the disadvantage is likely to be when you delay each item. For example, if you are unsure whether you should first enhance the user experience to sustain engagement or fix bugs to prevent churn, then identify the impact of delaying each goal.

Once you’ve determined the cost of postponing the items, address the one with the biggest cost of delay first, then the item with the second biggest cost, and so forth. This should give you the right prioritisation.

Don’t Let Powerful Stakeholders Dictate the Prioritisation

The two approaches described above assume that the user and business needs together with the product’s life cycle stage determine the prioritisation of your product roadmap—not the HIPPO, the highest paid person’s opinion.

Don’t get me wrong: I am a big advocate collaborative product roadmapping. Do actively involve the key stakeholders and development team members, encourage people to share their ideas and concerns, attentively listen to them, and build shared agreement, as much as possible.

But if you are faced with individuals requesting or even demanding that their interests must be first addressed, then do not simply give in. Don’t appease them and don’t avoid a difficult conversation. Instead, patiently listen to them and thank them for telling you about their idea. Then invite them to the next product roadmapping workshop so they can share their request with the other stakeholders and jointly decide if and when it can be addressed. And if the matter is urgent, get everyone together as soon as possible.

Being a product professional means making difficult choices, and prioritisation entails saying no. This is an important part of our job, whether we like it or not.

Product Roadmaps in a Nutshell

To start with, let’s briefly recap what a product roadmap is. A roadmap is a high-level plan that states how a product is likely to evolve over the next six to 12 months. An effective, modern product roadmap focuses on the outcomes and benefits a product should provide. In other words, it is outcome-based and goal-oriented. This differs from a traditional approach, which maps features onto a timeline.

For more advice on working with outcome-based product roadmaps, watch the following video.

Why Dates on Roadmaps Are Beneficial

Stating dates and specific time frames on a product roadmap can be helpful for two main reasons: They allow you to state deadlines and check if your plan is realistic and actionable.

Capture Deadlines

Some products must obey deadlines or a specific window of opportunity to achieve success. Take, for example, seasonal products like games and smartphones, whose main sales tend to take place before Christmas. Having the products ready on time is essential, as a delay would have a significant revenue impact. But even non-seasonal products can be subject to deadlines. For instance, in the case of imaging healthcare devices, a working prototype usually has to be available at the RSNA’s annual meeting to announce and then be able to launch the product, as far as I know.

Similarly, I’ve experienced hard deadlines for internal, supporting products like a supply line management application that had to be released at a specific date to achieve the desired benefits. Sometimes it even makes sense to employ a release train and timebox major product releases, for example, to coordinate different products or regularly offer improvements to the users.

Ensure the Roadmap is Realistic

Even if your product is not affected by any deadline, it may be helpful to consider dates or time frames when developing a product roadmap, as this allows you to understand if the plan is realistic. A handy tool for this job is the Iron Triangle shown below.

The version of the triangle depicted above takes into account goal attainment, date or time frame, and budget. Quality as the fourth factor that influences product success is placed in the middle to indicate that it should be fixed. Please note that one of the triangle’s vertices must always stay flexible and act as a release valve to account for unforeseen events, also known as Sod’s Law. To decide which vertices can be flexed, perform an informal impact analysis. Ask yourself if it would it be better to:

• Stick to the goal but take more time to reach it or increase the budget by adding more people (if that’s helpful and possible)?
• Or should you adjust the goal to make it less ambitious but adhere to the date or time frame and the budget?

Considering these questions makes it more likely to create a product roadmap that can be actioned and it sets the expectations of the stakeholders. (For more information on the Iron Triangle and how you can determine dates and budget, please refer to my book Strategize.)

Why Dates on Roadmaps Are Not Helpful

Using dates on product roadmaps can create unrealistic expectations and expect teams to commit for unacceptably long timeframes: Users, customers, and sales people may regard target dates as a firm promise or commitment and insist that these are adhered to—no matter how fast the development progress is.

This can create a significant amount of pressure for the person in charge of the product and the development team; it can result in an unhealthy work environment and unsustainable pace where teams work long hours or product quality is compromised. In the worst case, a severely compromised product is shipped, a product that doesn’t properly address the user needs and is full of bugs making it expensive and difficult to enhance and adapt it.

Now What?

Dates on a product roadmap are neither good nor bad per se. As with many other things, it depends on how you use them and the context you are in.

Whenever you work with an external, customer-facing product roadmap, I recommend not showing any specific dates. Instead, use timeframes that are big enough, so you don’t experience a death-march situation as described above. For example, you might want to choose six-months timeframes, or even more coarse-grained, annual ones like “this year” and “next year”.

But when you work with an internal product roadmap that aligns development team and stakeholders, I would encourage you to consider stating dates or narrow timeframes, as this helps you ensure that the plan is realistic and clearly express deadlines (if applicable).

In either case, make sure that creating a product roadmap is a collaborative exercise that involves the development team and stakeholders, preferably in form of a joint roadmap workshop. This ensures that everyone has the opportunity to contribute to the plan and that people are aware of their mutual concerns and interests. What’s more, it creates stronger support for the product roadmap and better alignment of the dev team and stakeholders.

Last but not least, don’t forget to regularly review and adjust your roadmap together with the development team and stakeholders—at least once every quarter, as a rule of thumb. A product roadmap is a living document; it has to be regularly updated to account for the development progress, user data and feedback, and changes in the overall product strategy.