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:

1. Inspiration and Vision: A roadmap is meant to help others see the vision of what we're doing. This is one of the most critical purposes of a roadmap because without a coherent vision, no product will be successful and no team will be functional. 
2. Communication: A roadmap is a communication device. It is meant not only to inspire, but also to allow users and business partners to know what is coming up and where the focus will be. It helps take the overarching vision and make it understandable and clear. Many groups simply need to know what's coming in order to prepare for it. And a roadmap is a great way to accomplish that.
3. Discussion: The roadmap is meant to help facilitate discussion about the direction and focus of what we're doing. Hopefully once we've created the vision and opened the channels of communication, we can have the right discussions about the problems we're solving and the outcomes we're focused on. This is critical because we also want to get feedback on our roadmap. It can be the first "test" of our strategy ensuring that we've prioritized correctly. That feedback can be invaluable in ensuring direction and buy-in.
4. Alignment: And of course, once we've had the critical discussions, the purpose is to get alignment around our product strategy and outcomes. A roadmap facilitates all of this communication and planning to ensure our product team is focused on achieving the right outcomes for our users and our business. It helps align our product teams and our stakeholders so we're working toward a common purpose and goal.

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.

Key Principles

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. 

1. Focus on Outcomes: As mentioned above, the key purpose of a roadmap is to convey the benefits and outcomes of our product development. So any roadmap we create should focus on the value we're providing and how we can measure it.
2. Understand the Audience: You will likely have a variety of groups interested in your roadmap. Each audience may need different things. Executives may be more interested in financial implications of the product development while customer support needs to know what new things are coming so they can be prepared for questions. This may entail tailoring the details of the roadmap to the audience (though I'd avoid maintaining completely separate roadmaps and just focus on different things for different groups where possible).
3. Keep it Clean: Don't get too bogged down in details in the roadmap. As mentioned above, it's not the place for the project plan. It's not the place for extensive details. They will only confuse users and stakeholders and raise lots of questions. It's about the shared understanding. Stakeholders who are intent on getting into details can refer to the project plans or backlogs if necessary, as part of a separate conversation.
4. Convey the Vision: Ultimately the roadmap is about telling the story of your product and getting alignment on the direction. Make sure that it is a cohesive narrative. Often this can be done in a simple, visual format. But in other cases having a longer form narrative may be appropriate.
5. Keep it Updated: Since the roadmap is a living document, make sure that it stays updated. There is no quicker way to lose the value of the roadmap than to let it become stale. If it is going to be the vision and direction of the product, make sure that it stays that way and that everyone is continually bought into that direction, especially as changes happen. 

An Example

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.