Treat your Roadmap as a Compass
Updated: Jan 25, 2020
How to effectively build and manage your roadmap and your stakeholders’ expectations.
The Roadmap Challenge
I recently participated in a meetup of very experienced product management leaders arranged by ProductX. We discussed roadmaps and the challenges surrounding them. Even though all of these product managers have years of experience it seemed like the challenge is still fresh as in their first days.
The major reason for this challenge is that the roadmap is not just a tool for a product manager to properly plan. The discussion around the roadmap is an opportunity for the whole organization to influence the product and what is going to be implemented. On top of that, your roadmap is also your commitment to your customers. As such, it creates a lot of emotional, and sometimes irrational discussions.
As a product manager your role is to make sure the discussion is productive and generate the right results. In this article I will try to give some guidelines on how to better achieve that.
Involve your Stakeholders
There are many methodological processes to create a good roadmap, but before diving into the details, I would like to start with the psychological part. You may want to remember that product management is about people and trust. Your roadmap is worth nothing if it is not accepted by the organization.
It all starts with how you perceive your stakeholders. Don’t manage your stakeholders from your ego. Your stakeholders should be part of the roadmap building and not just appear at the end of the process as approvers. Make sure you treat them with the utmost respect and because you need their valuable input.
If you manage the process right you will not need their approval. It will be built-in into the process. Managing the roadmap properly together with your stakeholders’ expectations will give you the freedom to work and make changes as you need within the boundaries of the agreed roadmap.
When you build the initial roadmap, sit personally with each stakeholder to get their input. Modify the roadmap based on their input if needed. By the time you get to the review meeting, everybody is already usually happy with the roadmap. The purpose of the meeting becomes not to approve the roadmap, but to properly review it and make sure that nothing important has been missed.
Start from Vision and Strategy
A roadmap must be connected to the company vision and product strategy. Before diving into the initiatives to be achieved, you must have a concrete vision and strategy. Hopefully you are also involved in shaping that strategy. If a strategy does not exist for your organization and product make sure to create it.
A strategy may involve revenue, new vertical markets, strategic customers, new platforms, variable margin, and many more aspects. While there definitely may be roadmap items that surf bottom-up, if you want to make an impact, you should make sure that your roadmap is mostly built top-bottom and serve the product strategy.
Continue with Goals and Metrics
You probably already have a big backlog in your mind that you just need to pick from. Stop. Don’t go there. Take your time. Your next step should be to define goals that serve your strategy. Try to define between three to five goals. Not less. Not more.
A goal may be an increase of daily active users, cost reduction, market expansion, launch of a new product, and anything else that ties into the strategy. Your goals must be measurable and you should definitely set proper metrics in order to track them. If your company works with something similar to OKRs (more on OKRs in How Google set Goals), your goals and metrics sit very well within that process.
Prioritize your goals. Prioritizing them would help you later in prioritizing your roadmap.
Plans with Problems and Initiatives
Now that your goals are set, you can start building your roadmap. Don’t include features in your roadmap; include big initiatives. Plan with problems. Execute with solutions.
An example of an initiative tied to a goal may be “certifying for GDPR” to meet a goal of “expanding into the European market”. This initiative may hide many features behind it that can be discovered during work, and should not be the concern of your stakeholders because they trust that you will take care of the details.
Working with initiatives that are defined as business problems enable you to have a better discussion with your stakeholders and your customers. It usually results with a roadmap of 10-15 items instead of a roadmap of 100 items that nobody can comment on.
It also gives you the freedom needed to work within these initiatives without breaking commitments. It enables you to be autonomous, empowered, and aligned with the business.
Commit as Little as you can
While the need for commitment is well understood, it usually creates a lot of problems. Hard commitments hold you back from being able to do react quickly to the market changes or to make the compromises you may need to make.
Unreasonable commitments are the reason why so many projects fail and everybody gets frustrated. It results in a situation in which a product manager presents a roadmap that they know cannot be met. It is a kind of “lie” that everybody understands but still plays the game.
You should treat your roadmap as a compass that guides you. Differentiate between committed initiatives and best effort initiatives. You should usually not commit to more than 30%-50% of your roadmap.
Tie the initiatives to the goals. The priorities you have already set for the goals should help you prioritize the initiatives.
When you set the right expectations between you and your stakeholders nobody is disappointed. You state clearly that some initiatives are committed and they can expect them on time, and others are best effort. Things may change based on what is discovered during work or because of market changes and changes in priority.
It is also about what not to do
Include in the roadmap not just what you plan to do, but also what you plan not to do. It is as important as the other list. In the process of building the roadmap there were many candidates that are very important and did not make it into the finals because of focus.
Stating the thing you do not plan to do ensures that they will not try to get back in every month. They were already discussed and decided to be postponed.
Stating what you plan to do and what you plan not to do and why, makes sure the whole team stay very focused on what needs to be done to follow the strategy.
You usually build a big roadmap every year. This is when you define your strategy and yearly goals and metrics. It is usually not possible to plan all initiatives a year ahead.
Your roadmap would probably contain a vague direction for most quarters and concrete initiatives a quarter ahead. I recommend rethinking the roadmap and whether it still fits the goals and market changes once a quarter. It is a good opportunity to review again where we stand with all stakeholders.
The roadmap should be visited once a month to see where we stand. It is a good opportunity to make a status update on what is still on time and what is delayed. This way your stakeholders are not surprised and continue to back you up.
Plan for Impact
It is very easy even in a roadmap to fall into fixing small things and just maintaining the product out of inertia. Make sure to look at your roadmap from the perspective of the market and customers.
I recommend that you make sure that at least one initiative in each quarter is one that can be used for a press release. At least one initiative should be one that changes the story you tell your customers.
A roadmap should be your north star by which you navigate your product and a tool to get your stakeholders input and backup.
Make sure you properly communicate that and separate commitments from actual efforts. You should commit as least as you can and deliver as much as possible.