The idea of a Product Roadmap is a simple one.
Provide a prioritised list of the New Products or Product Enhancements that the business will deliver to the market and show roughly when to expect them to be release/launched. Easy!
On the surface the process is a simple one too.
- List all products and enhancements.
- Prioritise products and enhancements.
- Schedule products and enhancements.
- Share the roadmap with others.
But here are some of the problems that we commonly hear that make the roadmapping process hard:
- Problem #1 – Not all of the items have been planned.
- Problem #2 – It is hard to see a roadmap at multiple time scales.
- Problem #3 – I need different versions of a roadmap for different stakeholders.
- Problem #4 – A lot of detail is required for a roadmap that is hard to show at a high level.
- Problem #5 – as soon as I am finished, the roadmap is out of date.
To address this we first need to think of the roadmap as two very separate processes:
- PLANNING and
They are both valuable on their own but unless they are both given proper consideration the results will not be effective.
In this post we will discuss the Roadmap PLANNING process and in a follow up post we will look at the Roadmap COMMUNICATION.
A Product Roadmap describes the business activities that individually and collectively support the organisations strategic goals. In this regard it represents more than just high level ToDo list. It needs to be a series of related activities where each one steps the organisation closer to it’s goal. But this is where the first challenge appears.
What are the business goals? Are they measurable in such a way that a single project or activity can contribute measurably to meeting them? For example, stating that in the next 12 months the business goal is to “increase customers” is not helpful. The 12 month goal needs to have a number like “increase customers to 10,000 by July 31, 2015”.
With just this simply stated goal there is a unifying direction that everything on the roadmap must contribute to.
Activity / Idea Capture
The next step is to start to capture a list of activities or ideas that the product management team are either working on, have some intention of working on or intend to explore in the future. If this is the first time you are preparing the roadmap have a brainstorming session with your team or other stakeholders to get their inputs. Allow no more than 1 hour for this capture process.
The first test of every item on the list should be to verify that there is a link between it and the Roadmap goal(s). Write a short sentence for each item describes how it will make progress to the Roadmap goals. Any activity or idea that cannot be linked should be removed from the list for review later.
It is now time to consider what should be worked on first, then second, then third and so on. Remember that a Product Roadmap is likely to change often and should be updated regularly, so don’t worry if the first attempt at prioritisation isn’t perfect. It can (and will) change but if you don’t start somewhere you won’t start at all.
When prioritising, consider:
- the progress to the roadmap goal.
- the effort required to meet the goal.
- any dependencies that are required first.
The result should be an ordered list, numbered from 1 to as many projects or ideas that you have on the list. There should only be one #1 priority, even if it is just by a breath. Multiple #1 priorities simply means that nothing is a priority.
You should now have a prioritised list of the high level activities that you believe will move the business closer to it’s strategic goals. The last step of the planning process is to position these against a timeline.
Begin by grouping these actions into 3 groups.
- Current – These are projects or activities that need immediate attention because they have already started or are expected to be delivered in near future. They should have delivery/launch dates that can be committed to.
- Planned – These will be projects or activities that need further work but have a high level of commitment to deliver. The time frame for a delivery of these will be an estimate, not a commitment, and in some cases may not happen at all.
- Future – Projects or ideas that seem to have merit but have not been developed enough to know for sure fit into this category. This is not a wish list of wild ideas. The contents of the Future list have still been through the prioritisation process. These items may stay in the future for some time but represent a place holder for an important activity that needs to have some resources applied to it to develop it further. There is zero commitment to deliver anything in this list, only a commitment to explore the ideas further.
You now have a prioritised list of all of the activities that you are considering to help your product meet it’s business objectives. You have prioritised and scheduled this list so it is clear now that you know where to start.
In the second part of this post we will look at a how to use this information as a powerful communication tool for the different stakeholders in the business.