Product Roadmaps: Love, Hate (& Hate)
If I could pick one thing to kill because of the problems it causes, roadmaps might very well be at the top of the list. And it's not that I don't like roadmaps, or at least the principle of product roadmaps. It's the misunderstandings that they bring. Sometimes the misinterpretation of a roadmap actually causes far more problems than the roadmap sets out to solve. Why is that? And what can we do?
Purpose of a Roadmap
The first thing is to really understand the purpose (or purposes) of a product roadmap. Fundamentally, a roadmap is a strategic document used to create the overarching product vision, articulating the value you're delivering to users and the business in order to gain support and alignment.
I break this down into a few key categories:
All of these pieces are crucial, because a roadmap is a living document. The purpose of a roadmap isn't to create an artifact that we can refer people to or post on a page somewhere. The items above are a continual loop as we learn iterate. By creating the vision, having the right conversations with users and stakeholders, and adding the learning that we get as we progress, we can continually refine our direction and plan for the future.
So Where Does This Go Wrong?
The purpose of the roadmap sounds great. Who doesn't want to inspire their users and stakeholders while ensuring everyone is strategically aligned? Why would anyone want to kill that? Where does this go wrong?
A roadmap is not a project plan. Far too often a roadmap gets confused for a project plan. A roadmap isn't meant to be the detailed execution of specific projects. It's not meant to commit to dates for releases or timelines for features. There is certainly a place for that level of specificity, but it isn't the roadmap, especially as we look several quarters into the future.
A roadmap is not set in stone. This is probably one of the biggest problems that many of us have faced. Far too often a plan is put in place at the beginning of the year with themes or focuses for the entire year. And we get stakeholders or users who view the roadmap as a commitment to those specific items, even if we find we need to pivot along the way. This problem is exacerbated when the roadmap becomes a project plan with specific features called out far in advance and commitments to them made with dates. See this article for more about keeping a product mindset.
A roadmap is not a list of features or requirements. A roadmap should be strategic. It should be focused on the vision and direction of the product, and the problems we're solving. It is about the value we're delivering, not necessarily the features. While it certainly is okay to talk about features on the roadmap, especially the near-term features that we're confident in committing too, it's important to caveat specific features with the understanding that the features are meant to solve a problem or achieve an outcome. We aren't simply delivering a wish-list of features.
Now that we're clearer on what a roadmap is and isn't, what can be done? How can we craft roadmaps that fulfill the needs of users and stakeholders while still allowing us to learn and iterate along the way?
No two roadmaps need to necessarily be the same. And I won't advocate for any specific template over another here. I've used variety of different types of roadmaps and they all have benefits and drawbacks. There are a few key principles that are true of most roadmaps.
What I have done with my roadmaps, and what (fortunately) seems to be becoming more and more common, is something like below (this is very simplified, but has the key ingredients):
One of the key features is the focus on themes. This has been critical in aligning the product team behind a common goal. It's also incredibly useful for discussion and alignment. When we introduce the themes, it opens the door for discussion around the possibilities. For example, if the goal is to launch to a new group of users, the themes may be focused around the key items needed for that group to successfully adopt. Knowing that this new group of users needs the ability to create portfolios then becomes a theme, with potential features or ideas that we can implement in order to make that happen.
The exciting thing about this structure is that it doesn't tie us down to any specific path initially. The goal is clear and the metrics are clear, but how we get there is open for discovery and experimentation. We aren't tied to a specific feature if that's not the best way to solve the problem. In the case of portfolios I mentioned above, the solutions may involve building that functionality, integrating with other applications, or finding some other way to fulfill that need for the user. A portfolio may not be the right answer at all, which is why we do discovery around the theme.
Of course, as we get further down the road, our level of specificity decreases. We simply can't know a year in advance what the solution to those problems will be. Or even what the most important opportunities will be at that time. We can certainly have some ideas and don't need to be afraid to share them, but we can't tie ourselves down to a particular course so far in advance.
A good roadmap helps paint the vision and strategy for the product. It outlines the key goals, often by quarter, and shows themes or opportunities that the team will be focused on.
If you're interested in diving deeper into roadmaps and alternatives to the way roadmaps have been done for a long time, I'd highly suggest Product Roadmaps Relaunched, which has a lot of great tips on better ways of doing roadmaps.
Ultimately a roadmap is about creating a shared understanding with our team, our users, and our stakeholders. It is not about creating a document in a specific format or with specific pieces. Part of that shared understanding needs to be that we will learn and iterate as we go. We're focused on solving problems, not releasing features. And while we may have talked earlier about a specific feature, if we can find better ways to solve problems and deliver value, many of the specifics may change as we go. Our roadmap is meant to help facilitate that understanding between groups and ensure alignment. It is about the vision and the value of what we're delivering. So hopefully more roadmaps can become helpers, rather than hindrances, in getting us to those end-goals. Roadmaps can be a critical tool for progress in product development. Even if we have a love/hate (& hate) relationship with them sometimes.
My personal musings on a variety of topics.