The Product Roadmap
The beginning of the new year is for me as a Product Owner the moment when i work intensely on my roadmap for the upcoming year. The Product Roadmap is a strategic tool to steer the direction of the product development. Sprint Goals and User Stories are tactical tools which deal with the next reasonable thing to do to reach a strategic goal. In this post i explain the format i usually use to create my roadmap.
I see the roadmap on a level between the Product Vision and the Sprint Goals. The roadmap explains the next important goals that have to be reached to come closer to the vision. The single goal sets the focus for the next 2 to 3 sprints.
Usually i define concrete roadmap goals for the next quarter (3 month) and i prioritize them against each other to make clear what the team will be working on during that period. To be able to give a prospect of what could be important for the product after we have reached the next defined goals i also formulate some further ideas beyond this 3 month period.
Based on my experience i think it is useless to define detailed User Stories for the goals as long as they are not work in progress. This is the reason why i create only very large stories for the goals were the team does not currently work on. This leaves the opportunity open to react on changes as they occur and to let learnings influence the further refinement.
The goals on the roadmap define an expected result. Therefore they have to make clear what needs to be achieved in a way that the team is able to focus on them. In the past it worked for me to communicate the following three points per goal:
Defines as clear as possible what needs to be reached. This helps to give it a name when you are talking about it.
Describes the value for the product or the company when the goal is reached. This point makes clear why we think something should be done.
Lists 1 to 2 relevant KPIs which can be used to measure the success.
A short summary about the issues that have to be solved. This helps to better define the context of the goal.
I still believe that effort estimations are not worth the effort, but i think that it has several advantages to work with timings in the roadmap.
- It becomes possible to define the cost of delay and you are then able to decide if you think that the topic is worth the investment.
- When you have a fixed deadline it becomes possible to reduce the scope. This increases the chances that the team will come up with ideas to solve problems better, faster and/or smarter.
- It puts you in a position were you are able to communicate when the team will deliver.
I always define deadlines together with the development team. The question we try to answer together is:
“How much time do we want to give us to reach that goal ?”
It is important for me to get a commitment from the team for the timeline. I expect that the whole team tries to stick to the self-determined deadlines afterwards.
I think it is important to understand that a roadmap should never be written in stone. It is a working artifact that needs to be adopted every time when it is required. This could be the case, when we learned something during the development process that allows us to define the direction of the product development in a better way. For the expectation management it is required to avoid hiding informations. If the priority changes or we realize that we are not able to meet a deadline or we find a way to solve issues faster, it is required to communicate it.
It has worked for me in the past to talk with the development team at latest when we are close to reach a goal or close to a expiring deadline about the following questions:
- Is the next planned goal still the most valuable one ?
- Are we still committed to the timeline ?
- How can we improve the roadmap with what we have lately learned about our product ?
In total i think it is important to do the planning, which basically means talking to each other about the best product strategy.