Clear communication is paramount for a Product Manager, and roadmaps, whether we like them or not, are among the most important communication tools at our disposal.
I believe roadmaps are extremely useful for any product-focused organization. However, they need to be built and used correctly to fulfil their role effectively - the visual representation of our Product Strategy.
That said, a roadmap should be a simple and high-level visual representation of where we’re at, and the path to creating a valuable viable product. It is a snapshot of our product strategy’s progress.
In this essay, I’m sharing some basic principles I use to build a roadmap.
First and foremost, roadmaps should be simple, strategy-focused, and always up-to-date. The key to simplicity is a clear understanding of our audience and goals. This enables us to adapt the information presented, fine-tune our message, and guide the discussion effectively.
When I’m building a roadmap, my main audience is usually the board of the company or C-Level executives and other leaders in the organization, and my objective is to update them on the progress of our Product Strategy to create a valuable viable product.
What a product roadmap is not
Despite the clear role of the roadmap, I still encounter a weird obsession in our industry to use it as a detailed list of features, estimates and time allocation. And worse, it is used to measure value, viability and progress, based on the number of features shipped on time.
Ask around in your company—ask the CEO, the Tech Lead, the CTO, the CFO and a lead designer what a roadmap is. You’ll likely encounter one of two scenarios:
- The majority believes a roadmap is a tool to show the features being built/launched and the estimated time for each.
- Everyone has their weird definition and we have no consensus.
From CEOs to developers, everyone uses the roadmap at some point, but each team views it within their isolated silo, with different goals and audiences, without a shared understanding.
These misaligned expectations by themselves create significant problems within our product organizations.
But there are many other risks, usually ignored.
Building a yearly or even quarterly roadmap with detailed features doesn’t make sense because our strategies are hypotheses. Most roadmaps focused on features and estimates fail not due to incorrect estimates or poorly described features, but because we plan features without knowing if they will contribute to creating a valuable and viable product. If we lock into specific features, we ignore a critical aspect of our strategies: they are hypotheses based on numerous assumptions. Thus, this becomes a vanity exercise, giving only the illusion of control and progress. Furthermore, this approach tends to shift our team’s mindset, viewing progress as a checklist of features and timelines rather than learning to optimize our strategy to our goals.
Therefore, sticking to a feature list just to meet a planned timeline can seriously impair our ability to adapt and incorporate new insights, which is the point of the whole process.
As a visual representation of our product strategy, the roadmap should not contain complex details and features but instead give everyone a clear picture of our priorities, how they are progressing and the path to creating a valuable viable product. Based on the previous essays, we now have all the information we need to successfully build this useful and dynamic visual tool.
Building the Roadmap
Another important thing to clarify in our organizations is “Who owns the roadmap”?
This is a no-brainer, whoever owns the product strategy, owns the roadmap. Ownership is about responsibility. We must work with all stakeholders to prepare for the quarter and understand what is achievable, and the roadmap’s purpose is to unify communication around product strategy.
When creating a roadmap, remember it is meant for alignment on product strategy, a clear picture of priorities, progress and the path to a valuable viable product. However, be cautious as roadmaps can create misexpectations and resistance to change when new insights emerge and assumptions are incorrect. If our product strategy is a learning exercise and will change, so should our roadmap. All stakeholders need to be aware of this. The roadmap is a reflection of the product strategy, not the other way around.
Here is the most simplistic version of a Roadmap that I usually present at the beginning of the quarter for each strategy:
The focus is on the priorities and impact, not the number of features implemented. This should lead the discussion. Are we working towards delivering a valuable viable product? Are our strategies valid? Are our tactics working as intended? If not, how do we course correct? Our fieldwork and the feedback loops should give us the answers to those questions to present to our audience. So always be prepared to answer those.
All stakeholders should be ready to see the roadmap changing, particularly if our tactics are not creating the desired impact on proxy metrics and GEM metrics. With leadership, we discuss if we are working on the right priorities, and discuss our strategies based on the most recent updates, rather than discussing features. Rule of thumb tactics and features are the product team’s responsibility to work with engineering and design as they are the most capable people to address those.
If our leadership wants to discuss tactics, it is fair, but that should not be their focus, as their knowledge is more valuable on strategy, company goals and product vision. If they want to see the progress and details of our tactics, I usually point them to Trello, JIRA (Confluence) or Asana, where we have the implementation details documented. This is about discipline and ownership.
Building the roadmap this way will allow us to focus on priorities and impact, rather than feature launches. This is critical. As we validate our hypotheses, we can update our roadmap with more accurate timelines for addressing the problem or opportunity being pursued, because now we know what we need to build to create impact. However, the focus should remain on results, not on implementation details.
Ultimately, a strategy is not complete just because changes were made to the product, it is complete when the desired outcomes are achieved.
Monthly Product Strategy Update
Each month, I like to provide clear updates on our product strategy in a meeting with the roadmap being shared accompanied by data-rich analyses of what we learned, and the necessary updates to our product strategy document. This helps our organization to understand priorities and focus discussions on the path to create a valuable viable product. So in these updates instead of focusing on the timing to ship a feature, we focus on what we’ve learned, and the impact we are having on the strategy we decided to pursue, if we progress as planned, do we need to re-prioritize anything or if we need to course correct based on what we’ve learned and why. Embrace the debate, encourage it even! We get precious feedback from these discussions.
An example of the agenda for this meeting, using the roadmap as a visual support:
- Presentation of our Product Strategy: Company goals, Product Vision, and ongoing strategies.
- Key learnings and progress from last month’s priorities.
- Opportunities to pursue this month and the cross-functional coordination required.
Usually, in this meeting, we have the C-Level and leaders of the company (product, marketing, growth, engineering and design).
Depending on the stage of our organization, it might make sense to have quarterly updates rather than monthly. As I usually work with startups where pretty much everything is changing all the time, strategic alignment is critical every month.
This approach empowers teams to make their own decisions as the process unfolds. Instead of predicting features for the next six months or estimating timelines for the year, the main objective is to ensure the roadmap is updated and tackles the main challenges to create a valuable viable product.
Involving Stakeholders
In smaller teams and startups with one single product team, I fine-tune the roadmap for presentation and active discussion with the company C-Level, the ultimate target audience. In larger organizations with multiple product teams, I involve them directly in contributing to the roadmap and in the meeting, with each team responsible for a strategy sharing what they’ve learned and their progress. In both cases, this allows the teams to be highly aligned and loosely coupled. Everyone knows our overall strategy and their role and goals through context, making it easier for them to make decisions without the burdens of constant approval.
For example, if we want to improve growth and one of our main strategic hypotheses is “Order Confirmation,” we work with our product and engineering team to streamline the confirmation process and visualize that effort. While having an informed opinion about timings and tactics is important, the endgame is not the timing or the tactics themselves but the impact on the user and the objectives. Teams completely own their strategies and work towards their goals, the implementation details and decisions are up to them. This provides clear objectives for each team, focusing on impact rather than features.
Conclusion
The way you create your roadmap should help you communicate effectively, not just check a box on the process and never update again until the end of the quarter. If your team works best with a feature list roadmap, that’s fine. However, there are too many risks with that approach.
From my experience, I see products thriving in an environment where the roadmap is focused on the opportunities to pursue, the problems to solve, and the path to create a valuable viable product, rather than features to build.
Always look for tools that help you communicate and don’t just adopt practices because they are entrenched in our culture. Roadmaps are all about strategic alignment and communication, not a to do list.
Updated Index of all articles released so far:
The Non-Technical Founders survival guide
How to spot, avoid & recover from 7 start-up scuppering traps.
The Non-Technical Founders survival guide: How to spot, avoid & recover from 7 start-up scuppering traps.
