As a Product Owner, you are responsible for Product Backlog management, stakeholder management and forecasting. Therefore, you will probably use a variety of tools and techniques to track progress, manage expectations and keep people informed. One of the tools that may come in handy for you is a product roadmap. Applying product roadmaps effectively can be challenging however. The concept of a product roadmap however, is that it is a high-level, strategic plan, that describes the likely development of the product over the next period of time. The roadmap should support the products' purpose and vision and it helps the Product Owners to keep their stakeholders aligned. The roadmap also makes it easier to coordinate the development of different products and it fosters transparency in order to manage customer expectations.
In a lot of organizations, I see that Product Owners are focused mostly on developing features and therefore, a lot of roadmaps are also dominated by features and functionalities to be delivered. The disadvantage of focusing on features too much, is that there are always too much features that would add value, therefore creating a lack of focus on the vision and goals. By focusing on the features too much, the roadmap will turn into an overloaded product backlog, instead of a high-level, strategic plan for the products' future development.
In my everyday practice, I've seen a variety of product roadmaps that were used. Although these three different roadmaps all have different pros and cons, I've seen all of them add value for Product Owners in their daily work. Personally, I always use a combination of these three roadmap practices. I mostly use the Storymap in the beginning of a products' development, because I want to create insight for the stakeholders in the products' features.
Goal Oriented product roadmap (GO product roadmap)
What I personally like a lot about the GO product roadmap is that it facilitates a lot of focus on the goals you want to achieve as a Product Owner, much more than the actual work to be done (the features). Although the GO product roadmap offers the possibility of adding features, I like to start with the end goals in mind, and I believe every Product Owner should do so. The GO product roadmap and focus on goals enables value steering (steering on outcome) instead of steering on work packages (steering on output). Since you are responsible for the product vision, strategy and roadmap as a Product Owner, I believe this is a valuable asset of the GO product roadmap.
Another aspect of the GO product roadmap I like a lot is that it supports you in thinking about the most valuable features that enable the achievement of your goals. Since Agile is also about "Simplicity - maximizing the work not done" (Agile principle #10), I like the concept that there is only a small amount of space in the model, to force you to think about the top three most important features for a release. What I also like a lot, is that in one glance, you can get an overview of you products' development over the next upcoming releases, which comes in very handy to manage your stakeholders!
Depending on the organizations' context, I sometimes leave out the dates and release name sections of the GO product roadmap. I do this since I've seen quite a lot of stakeholders in the past, who saw the dates in the roadmap (which were forecasts from my perspective) and they concluded that they would certainly receive the functionality on the date that was in the roadmap. Since we're working in complex environments which change and since people change their minds overtime, this didn't always work out very well. Therefore, depending on the context, I sometimes use and sometimes don't use the date and release sections, to stimulate interactions and to prevent the wrong interpretations of the items on the roadmap. In these cases, I often combine the GO product roadmap with the Now-Next-Later product roadmap.
Now-Next-Later product roadmap
The now-next-later product roadmap is a visualization I like a lot, because it's really easy to understand for everyone. All stakeholders understand the concept of this model, since it's easy to understand that you are working on the stuff in the "now" part, the "next" part is what is coming up soon and the work to be done in the "later" part is further away in time and still has to be prioritized.
The negative aspect of this roadmap from my perspective, is that it is focussed more on the features, rather than the goals/objectives you would like to achieve as a Product Owner. Besides that, the model doesn't offer much room for including KPI's, releases or dates. Since dates and timelines are important information to stakeholders (in most of the situations I have been in) this may be something you need to consider when applying this type of roadmap. On the other hand, it may just as well be an advantage that the now-next-later product roadmap doesn't include dates, since this offers you the opportunity to interact with your stakeholders, instead of them reading the data from your roadmap.As mentioned earlier, I often like to combine the now-next-later product roadmap with the GO product roadmap, which adds more value for yourself and your stakeholders.
Story map
The story map is a really nice type of roadmap that I often use in the beginning of new projects or products. The story map is an excellent way to create a nice overview of all the features you and your stakeholders can think of, which will be important to your product. Although the idea is not to create an unlimited list of all the features and functionalities that will likely be developed somewhere in the future, it does provide a nice starting point to facilitate creative ideas for your product. What I like most about the story map is that it provides an overview of all the user activities that need to be covered by the system, which in turn enables you to create small and valuable user stories, which can be developed and delivered incrementally and iteratively.
Another aspect I like a lot about the story map is that it starts with the user activities, and thus taking a users' perspective on the product. I really like this concept, since it helps you with brainstorming about the product from a users' perspective, after all, we develop our products for our users and customers right?
The main downside of the story map that I've seen in practice is that it creates the illusion that all the features for the product will be developed. Since we're being Agile, it is not our goal to create a complete plan or breakdown for the product, so my advice is to use the story map at the start of your new product development project, but also make it very explicit to stakeholders that you will not neccesarily develop all of the stuff in your story map. So manage these expectations well!
11 Tips for Agile Product Roadmaps
I hope these different roadmap types are useful for you, but remember: "Being Agile is not about processes and tools but about individuals and interactions". Therefore, and thanks a to Roman Pichler for offering some inspiration, I would like to share the following 11 tips with you about creating Agile product roadmaps:
- Start with your product vision (tip: use Roman's Product Vision board);
- Describe and validate your product strategy;
- Focus on goals and benefits, by creating a goal oriented product roadmap (or one of the other types I've explained before);
- Tell a coherent story about the likely growth of your product and don't oversell it;
- Keep it simple! Resist the temptation to add too much details to your roadmap;
- Actively collaborate with stakeholders to ensure buy-in;
- Have the courage to say no, to prevent an overload of features in your roadmap;
- Think twice about adding timelines, dates or deadlines to your roadmap;
- Make sure your roadmap is measurable, by adding measurable goals and KPI's;
- Create a rough estimate for each feature (#people + required skills) to determine the viability of a feature;
- Review and adapt your product roadmap on a regular basis.
Thanks for reading, if you have any feedback to share please do, and good luck with creating your product roadmaps!