Why typical product roadmaps fail – how to overcome their flaws

Roadmaps are ubiquitous. Everybody working in product development has encountered one. If you are a project manager, product owner, or product management professional you probably maintain a roadmap that you are using regularly to communicate timelines, priorities, and strategy. 

Also, you are likely unable to predict the future. 

Typical roadmaps give the impression that we are able to exactly do that, predict what will happen. It is because of this contradiction that roadmaps are inherently flawed. Nevertheless, they can be very useful. 

This conflict between being flawed but necessary is the reason I want to dive into the topic of roadmaps today. I will expand on why they are such a flawed tool, why we still need them, and give some actionable advice on how to deal with the situation. 

Upfront, a small note, within this article I am referring to roadmaps in software companies and some of the topics covered will only apply to those. However, much of the writing is applicable to roadmaps in all kinds of circumstances.    

Email address:

Leave this field empty if you're human:

The flaws of roadmaps

In many companies a typical roadmap consists of a sequence of features on a timeline. It is output driven with due dates at which certain features will be available. These features are often prescribed by leadership, sales, or other stakeholders. 

As such, output focused roadmaps often signal a specific type of company culture with little experimentation and product discovery work. This is problematic because much of what we develop will not work technically or it won’t be successful in the market. Even if we make it work, we often need more than one try to get the intended impact. 

We often don’t even know if the requested features solve the business problem we want to address until we deploy them. We think that the team producing the output of Feature A will lead to a higher conversion rate, for example. We are often not sure of that until we actually ship it. 

This means that the typical, feature driven roadmap is inherently wrong the moment it is created. We cannot predict the future and a typical roadmap suggests we can. 

This is problematic because it causes one of three things (or a combination of the three). 

1. The team reliably misses deadlines or milestones, leadership loses trust, and we get frustration all around. 
2. The person responsible for the roadmap constantly wastes time and effort updating the roadmap and explaining those changes to key stakeholders. 
3. The team adds more and more buffer when they estimate work packages to ensure that the due dates are kept. 

All three outcomes are unsatisfactory and cause waste. Neither enables using the roadmap as an efficient planning tool. 

Despite these flaws, roadmaps are still widely used in product development organizations. Why should we continue to use them?

Why we still need a roadmap

Roadmaps are useful communication tools that can greatly help in product development and in running a business. A roadmap can be extremely supportive in communicating a high-level overview of a project or product and align stakeholders around a shared vision.

In the end, the leaders of a business want to know that the teams are working on what is truly important. A roadmap fills exactly that need by demonstrating what the team has planned. Ideally it consists of exactly those items that serve the needs of the business. In this way it creates trust. 

Furthermore, companies need to be able to plan. Sometimes, there are actual commitments and hard deadlines we need to keep. This can be the case when we have commitments to external parties or when we are building something so complex that we have many teams that are dependent on the deliveries of one another. 

In this case – I would argue that it probably doesn’t happen all that often – we actually need the deadlines or milestones. It is imperative that we achieve them. A roadmap can show if we are on track to do exactly that. 

How to make roadmaps more effective

So, typical roadmaps that are output or feature based are inherently flawed because we cannot predict the future. We still need roadmaps to communicate and to be able to coordinate the actions of an entire company, though. How do we deal with this conflict? 

Three things stand out to me in ensuring the effectiveness of roadmaps.

• Building trust
• Outcome based roadmap
• Avoiding exact dates

Building trust

The problem is that those of us responsible for a roadmap often can’t unilaterally decide to change its nature. For this reason trust between leadership and the product team is so important. Communication – a key skill for any Product Owner, project, or product manager – is crucial here. 

Constantly sharing the progress of what the team is working on and what it learned with key stakeholders goes a long way. Regular one on one check-ins with those stakeholders are always a good thing. Inviting them to the sprint review is also a great way to share and gather feedback. 

It also makes a lot of sense to involve the stakeholders in the planning process to ensure their buy-in and support, setting realistic expectations when doing so. We need to foster the awareness and understanding that in software development much of what we develop will not work (on the first try). We need to jointly understand that we cannot predict the future. 

However, we also need to convince leadership that we understand the business problems and that we are working to solve them. Remember, one of the main reasons for a typical feature driven roadmap is that our leaders want to be sure the teams are working on the right things. 

Demonstrating that you have understood the needs of the business and being able to articulate how you think to address them will go a long way to securing the trust. Earning this trust should give you more freedom in creating the roadmap on your terms instead of having the features prescribed by leadership. 

Outcome based roadmap

If you have earned the trust and are in the envious position to shape your roadmap as you like, I strongly advise to use an outcome based roadmap. 

Instead of a list of features that – according to someone’s opinion – we hope will solve a business problem, e.g. increase the conversion rate, we fill the roadmap with the actual business goals, i.e. increase conversion rate by X%. 

We still demonstrate that we are spending our precious resources wisely on the right goals. At the same time, we leave it up to the experts, ideally in a cross-functional product team, to decide how to achieve this goal. In this way, the outcome based roadmap recognizes that we cannot predict the future and opens the door for experimentation in product discovery. 

The team feels a greater sense of ownership for the product when they are given this added responsibility. It leads to higher motivation, better solutions, and a happier atmosphere. 

Changing from output to outcome based planning necessitates a change in mindset that is difficult to achieve. Much is related to trust between the leadership and product team. I realize that it is not often the reality that we are able to have a fully outcome based roadmap. 

I suggest being pragmatic and continuously pushing in the direction of the outcome based roadmap. If a powerful stakeholder is insistent on adding a specific feature to the roadmap, so be it. You might just have to add it. (Maybe it’s also possible to create an experiment using this feature as one of several options for achieving a desired outcome.)

Wherever possible, though, we should replace outputs in our roadmap by business outcomes we want to achieve. The effort spent in arguing for that will pay dividends down the road.

Avoiding exact dates in the roadmap

In recognizing that we cannot predict the future, I encourage you to avoid exact dates wherever possible. Only the actual actual deadlines are hard commitments that we need to keep. 

Whenever you’re tempted to put a date on a milestone ask yourself if this exact date is when it REALLY needs to be done. If the answer is a hard yes, great! Assign a date to the milestone and make sure you achieve this date. If you’re unsure or the answer is no, don’t put an exact date. 

Without dates I suggest keeping a less granular roadmap. You could break it down by month or quarter and highlight the outcomes you plan to achieve during that period. The Now-Next-Later format is also a great way to acknowledge the constantly changing circumstances.

You are probably still going to be asked for dates by senior leaders. If you really have to provide them, go for it. Give a date that according to the team’s best estimation is realistic. Of course, you will try to attempt to achieve this date. 

You have to always explain the caveat that you are not in the business of predicting the future, though. 

Outcomes over outputs is the key

The product roadmap describes the path from where you are now to realizing the vision you have formulated for your product. 

As such, roadmaps can be an extremely useful tool for communicating the overview of where the product development is headed. However, the typical feature or output based roadmap is inherently flawed. Pushing for one that includes outcomes is a change in mindset and a worthwhile endeavor. 

The outcomes for the business in terms of motivated teams, better solutions, and in the end happy users are definitely worth it.

Coverphoto by Slidebean auf Unsplash