Best Practices for Effective Roadmaps

A lot of product managers have a love/hate relationship with roadmaps. Many times with good reason, as misinterpretation of a roadmap can sometimes cause more problems than the roadmap serves to solve. It remains true however that roadmaps, if used right, can be a very useful tool to communicate progress in product development.

There are many techniques available to create and present roadmaps. However, there are certain best practices that can be applied regardless of the actual technique or tool that is used.

What is a roadmap?

A roadmap is a strategic plan to guide the development of a product in order to meet a set of business objectives.

It is not a predetermined future state but a well thought-out intention, based on what we currently know and what our best guesses are on what the future will bring. It should be clear to all stakeholders that the roadmap is always subject to change, with items that are planned further away in the future being more probable to change than the ones that are closer to the present.

In essence, a roadmap is a communication tool that can be used to spread the word about how a product is going to evolve and why.

Here are some of the most useful best practices to have in mind when creating a roadmap.

It’s not about the features

Planning for features is actually akin to prescribing complexity. Consider this: when talking about planning using features we typically use the verb ‘add’ (i.e. add a feature).

On the other hand planning for outcomes enables the decoupling of the implementation specifics (the features) from the problem at hand. Instead of adding functionality, a problem could be solved by modifying an existing feature or even by removing it altogether, making the product simpler to use.

Moreover, the importance of a feature is usually understood by the person or group that requested them. In their view it serves to solve certain pain points, in a specific way that may or may not be aligned with the bigger picture of where the organization is moving to. The prioritization of such a feature is more difficult to justify to all stakeholders across the organization, especially if their features have been pushed back to make room for this one. However, the prioritization of a business outcome with a tangible result is easier to be communicated to a broader audience.

Connecting the dots

Every item on the roadmap should connect directly or indirectly to the mission of the company.

This means creating a clearly visible connection between the company’s true north, the master purpose behind everything that should be done, and the actual work that is planned.

There are two prerequisites for maximum impact of this: that this shared purpose is communicated and understood by everyone and that teams have been granted enough autonomy to take tactical decisions for non-company ending situations.

If these two prerequisites are met — and they should in a healthy product-driven organization — this clear connection of how a particular roadmap item connects to the overall company strategy can give teams the visibility required to take decisions that are consistent with the company strategy, removing the bottleneck of having every team decision checked by senior management.

It is a team sport

The creation of the roadmap should be a team activity and not an individual person’s job.

Sure, the product manager is the organizer and facilitator of the exercise but it is the stakeholders that can provide the real insights, whether they are the people in the field, the executives or the development team.

So, do not treat the roadmap creation as a closed door exercise where the product managers review the open tickets, get estimations and put them in order.

Involve stakeholders and team members and get their input about each request. Actively listen to what they say and try to diagnose the real need behind the requests. Ask why, again and again to get to the root cause of the problems that drive their requests and discover what business outcomes can be achieved by fixing them. Document and share this knowledge, the why and the expected business outcome behind each request.

Enabling active participation of stakeholders not only will create better shared understanding of the real issues that need to be solved, but you will also get buy-in from the teams about the work that needs to be done.

Experiments

Introduce experiments in your roadmaps. Experiments are a valuable tool to gather data that can help validate the assumptions behind the expected outcomes before any major effort is spent. I am not referring to one-off experiments that are done only when absolutely necessary or only when there is enough time (as usually there isn’t).

What I am suggesting is a mentality shift in product development with the aim to regularly have better data available before making any non-trivial investments.

Consider the following scenario: Major effort was spent towards developing certain functionality but the results after the roll out do not live up to the expectations. What happened? Maybe the predicted outcome was based on an assumption that is not true for all the market segments that we target. Or, it may be that our users think differently about a certain case from the way we do in the safety of our office.

Taking a pragmatic approach where the assumptions behind any major decisions are tested in the field enables better decision making.

Do not obsess about prioritization

Many teams spend a lot of time in the prioritization phase, especially if certain roadmap items are complex or if there is not enough data to decide. If the team is unsure about how to prioritize a large item then break it down into incremental deliverables and use the feedback loop from each deliverable in order to guide decisions for the next ones.

Just make sure that your roadmap sets clear expectations for the short term, a glimpse of what is most probable to happen for the mid term and a general direction for the long term.

Hold retrospectives

Hold frequent retrospectives to evaluate past prioritization decisions. Primary questions to ask include: Did we deliver what we set out to? And did this actually translate to actual customer value?

Seeking the answers to these questions will lead to secondary questions: Did the assumptions behind the predicted outcomes were correct? Were they based on data?

Evaluating the outcomes of each decision and seeking the why behind them will yield powerful insights. Taking the time to document and communicate them to the organization can act as a driver for organizational learning.

Also, evaluate the effectiveness of the process itself. As we cherish feedback loops that help to improve our products, we should be also establishing feedback loops that help to improve our product development process. Along with the assumptions and business results related to the roadmap creation, also evaluate the process of creation itself. Is there any bottleneck in the process that can be removed? Is the process fit for engaging all relevant parties for feedback? Is the process well defined and documented? Or, do we have too much process?

Testing and improving the rules of roadmap creation essentially means moving from single-loop to double-loop learning, ensuring that future roadmaps can be created more efficiently and eventually leading to better business results.

Final words

Creating a roadmap is a great opportunity to communicate the vision for the product and lay out the steps to get there. There is no silver bullet — a one size fits all process — as each organization’s context is different. Yet there are certain approaches that tend to work well regardless of the size and maturity of the company.

Following best practices and keeping a learner’s mindset to adjust things as you go will help create impactful roadmaps that generate alignment behind a common company vision and enable product success.

Originally published at my blog on September 2018.

Thanks for taking the time to read this article. If you liked it please give it a couple of claps 👏 .