10 Product Roadmapping Mistakes to Avoid

The product roadmap is a great product management tool. But it can cause significant issues when it is not used appropriately. This article discusses ten product roadmapping mistakes you should avoid to fully leverage your roadmap.

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.

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.