[minti_blockquote]The Product Roadmap is a high level plan for stops we intend to make on our way to our Product Vision.[/minti_blockquote]
Roadmaps can exist in many different shapes and forms and there are some general considerations that need to be considered when you develop your roadmap.
- Purpose
- Planning horizon
- Planning dates
- Flexibility
- Internal or external
- Who decides
- Different alternatives
Purpose
The purpose of a roadmap is to align people around higher level ideas for the future. When working in sprints or a continuous flow of value it is easy to lose sight of the bigger efforts and direction unless it is explicitly discussed and planned.
Planning horizon
How far into the future should your roadmap span? The most common set-up seems to be a 1-year roadmap that is created at the end of the year before. But it might not always be the right choice. In general, the higher the uncertainty, the shorter the roadmap should be. For example consider the following two scenarios (I have experienced both):
- A 500 manyear effort to build and replace existing systems, with significant need for work on the customer side as they incrementally implement parts of the system on their side
- A small start-up in a very fast moving market where one great customer meeting might replace what was based on a good customer meeting the week before
In the first scenario I believe it made sense to have a rough roadmap for the entire effort so both parties could plan accordingly. Of course it is pretty much impossible to follow such a roadmap, but it at least gives an idea, and you have a baseline to replan from. In this scenario the uncertainty in what was needed was not that high since there was an existing system to replace.
In the second scenario I believe the roadmap shouldn’t be longer than 3 months, maybe even shorter, since things and priorities could be changing pretty much monthly (and for good reasons).
I think the planning horizon should be context dependent. One year could be a good default starting point. It would very rarely be longer, but on occasion it can make sense. In a fast moving market, with a relatively new product it is likely a waste of effort to try to plan that far out into the future, so the length should be shortened.
Planning dates
I have worked with roadmaps without dates, with rough quarterly indications and with dates.
In general I think it is better to not have dates unless there is a strong reason to. A lot of managers argue that dates keep the teams focused and make them more productive. There is some truth in this, but quite often the downside outweighs the upside. The downside that could be for example technical debt, stress and reduced employee satisfaction. And since the roadmap is often a bit further out it has a lot of uncertainty built in. With dates in it it is easy to get into a vicious circle of a lose-lose game where developers are “punished” (for example with stress) when missing dates so more time is needed to plan and estimates need to get padded and so on.
Flexibility
A roadmap should in general be seen as a living document. Anything longer than a sprint is too far to be seen as a proper commitment. Of course it can be possible to plan multiple sprints with good results, but it usually requires more effort and padding than it is worth.
One of the challenges is to make everyone understand that the roadmap is not cut in stone.
Internal or external
Most of the time it is best to use the roadmap as an internal tool. Occasionally it can be worth the extra hassle of keeping the customers informed. But remember that you might than also need to update them when the roadmap changes and it will be much harder to keep a good level of flexibility.
Who decides
According to Scrum by the book the roadmap would be decided by the Product Owner. In reality it is hard to conceive that this a good approach in the most common scenarios. The only time that really makes sense is when the product or products are completely independent on everything else and the Product Owner can truly be a mini-CEO of the product.
For example, in a small start-up with 20 people and one product it would be a bit absurd if the CEO agreed with the boards and investors on a roll-out plan in certain countries and the Product Owner decided on a roadmap that were more supportive of other countries. Of course this would be a sign of poor collaboration, but in this scenario it would make the CEO almost completely powerless if the Product Owner had complete decision rights over the product.
Another example is in somewhat larger company with a couple of hundred employees and five different products that are supporting each other. In this scenario there would need to be alignment between the different products if the company wants to be successful. Agile zealots might argue that every product should be independent, but quite often 1+1 can be a lot more than 2, which makes the extra coordination worth the effort.
In general, most of the time, I believe decisions around a roadmap should be taken in some kind of leadership team. The composition of that team might be different depending of the context, but it should rarely be one person who decides on his own.
It is not only the roadmap for development of the product that is best decided in a leadership team. For example, the sales strategy should also be decided in the leadership team. All parts have to be thoroughly aligned for a company to be truly successful.
Different alternatives
Different alternatives for things to put in a roadmap are primarily:
- Hypothesis
- Themes
- Goals
- Features
Over the years I have come to appreciate the Hypothesis driven approach most. Even when uncertainty is fairly low, it can provide clarity to phrase items on the roadmap as hypothesis. For example, sometimes you know exactly which feature you want to do. It might be clear what it will be and what need it will satisfy, for example because you are copying something that your competitors already have. But you can still frame a hypothesis, for example around which customers you believe will use it.
Here is one example of how a roadmap can be phrased (basically what I did in a previous company, but we only showed features on the roadmap, not the rest of the info).
