When having to come up with a roadmap, Product Managers often structure it like a project plan. However such roadmap formats do not reflect modern, agile product development and do not serve as effective strategic roadmaps for startups. This article introduces five alternative roadmap formats that you can use to improve strategic product planning within your company and to communicate your product goals to your stakeholders.
The problem with traditional product roadmaps
This article is based on the premise that quarterly timelines filled with features dont make for great strategic product roadmaps. Yet they are frequently used as the go-to format by management and product teams.
The problem with such roadmaps is that they are linear and one-dimensional. They suggest that the product team knows exactly what needs to be done in the future, and that its only a matter of correct estimation and timely execution. But these are in fact release plans, not product roadmaps. They do not reflect the core concepts of modern product development, such as uncertainty, discovery and small pivots. Such roadmaps often force Product Managers to focus their time on project management, stakeholder management and estimation rather than product strategy and discovery. The result is often a roadmap that tries to accommodate too many items and a lack of focus on the most important strategic initiatives for the product team.
Roadmaps have not been adapted to agile product development
While the disciplines of product management and software development have evolved significantly, our roadmaps remain unchanged. Its striking that most product management tools and roadmap templates propose the same linear timeline format, and I frequently see Product Managers revert to them. Even those tools that acknowledge the problems with traditional roadmaps still use the same old visual format. Most of the proposed alternatives Ive seen are just features mapped over time.
By their very nature, such product roadmaps are not agile. They impose a large amount of friction to making pivots, because you need to either re-allocate all existing items on the roadmap or remove those previously established commitments, causing friction with other stakeholders.
How roadmap creation typically happens
When product managers are being asked to come up with a roadmap, they assemble the stakeholders and collect requirements. Solution ideas originate from workshops, brainstorming sessions or customer requests. The product team then proceeds to prioritise and subsequently map these requirements onto a timeline, gathering input from engineering to make what you could call at most an educated guess for a feasible timeline. A roadmap is created and presented to management. And if management signs off and the product team has great planning and development capabilities, they might actually produce all the requested features within a reasonable time framebut they will most likely not pursue the best product strategy.
So what went wrong here? The main issue with this approach is that it considers roadmapping to be a one-off activity, rather than a continuous process. It therefore forgoes the opportunity to continuously incorporate research insights into the product development process. Secondly, this roadmap is built purely based on stakeholder opinions and the knowledge status quo. It doesnt encourage the product team to validate the hypotheses that these opinions are based on and embrace new opportunities discovered in the research process. Finally, a behavioural problem with this approach is that such a roadmap entices the team to push back all future items when development is delayed, rather than to stop and evaluate whether the roadmap is still justified based on what has been learned in the meantime.
This article proposes five alternative roadmap structures to focus on more strategic product planning and managing trade-offs. For each approach, it then discusses how the respective format can help you reframe the question of prioritisation within your team.
Idea #1 See the roadmap as a tree of opportunities
This is a mental model that encourages the team to change the question of prioritisation from when and in what order can we get all of those features done? to what is the most important opportunity we should pursue right now?. It recognises that the exact path is not known as of today, and therefore figuring out the right path is the core task of the product team. It also visualises that tradeoffs are required at every step.
Every transition from one item to the next is an opportunity to prioritise the most important item. Pursuing the most valuable opportunity at every intersection essentially comprises your product strategy. In companies with short release cycles, this might happen every week. Other teams might do this work in 2 months cycles.
The opportunity tree expands over time because as you conduct research and learn more about the the customer and problem space, the list of discovered opportunities grows. As more opportunities are discovered, choosing the right opportunity becomes harder over time, and focussing on the right ones becomes essential. This model encourages stacking opportunities and forcing prioritisation at every intersection rather than queueing them to a linear roadmap.
Some guiding questions the team could discuss at every intersection:
- Have we made progress against our strategy and objectives?
- What did we learn about our customers and the problem space?
- How do those learnings influence our strategy?
- Are our objectives still adequate?
- Have we made progress in the solution space?
Advantages of this approach
- Embraces uncertainty, trade-offs and pivots
- Avoids low-integrity commitments
- Focuses the discussion on the short-term priorities, forcing regular prioritisation
- Aligns roadmapping work with your product development cycle
When is such a roadmap adequate?
Such a roadmap is suitable for an early stage when the long-term strategy isnt clearly defined yet and the team is iterating often. This is usually the case in early-stage companies with little product maturity. At that stage, the roadmap of the product is still unclear and the product team is still learning a lot about the problem space. At this point the roadmap should contain a high level of flexibility for the product team to run experiments and chose the right path. The team should avoid cluttering the roadmap with a large number of requests and ideas.
Idea #2 Kanban roadmap
A simple approach is to structure your roadmap like a Kanban board. The most basic version could contain a Now, a Next, and a Later column. This is somewhat an implementation of the tree of opportunities described above. It similarly embraces the concept of buckets, prioritization and consciously pulling items from a future bucket into the current one. The key difference between a Kanban roadmap and a typical Kanban board is that the roadmap only contains major, strategically relevant initiatives.
Additional advantages of a Kanban Roadmap
- They clarify the near-term priorities, while maintaining long-term flexibility
- They require actively pulling items into the Now column rather than already assuming future items like a traditional roadmap
- Pulling an item into the Now and Next columns represent prioritising the items for the next development cycle(s), the main advantage to traditional roadmaps being that this needs to be done actively and the item wasnt a committed feature in the roadmap all along
- Its easy to manage your roadmap in an existing project management tool (such as Asana or Trello)
Avoid putting everything in the Later column instead of effectively prioritising items that stakeholders submit. Even if the Later column technically does not represent a commitment, this bucket should only contain opportunities youre actually planning to tackle some day. Its all about communicating well what the buckets represent. Later means likely in the future, but it also means we wont do it now. It does not mean No.
When is such a roadmap adequate?
Unlike the more loosely defined tree of opportunities, a Kanban roadmap can be suitable for more mature product development teams as it provides more clarity and more foresight. It works very well when the Product Managers are able to work ahead of development (the contrary of being in the reactive mode of having to deliver product specs all the time). It clearly defines the items being developed or shipped in the Now column as well as the upcoming items in the Next column.
When the nature of your business might require you to commit to certain delivery dates (as is sometimes the case in B2B product management), this is however difficult to accommodate in such a roadmap.
Idea #3 Put product discovery on the map
This roadmap idea builds on Marty Cagans dual-track model of continuous discovery and delivery. Traditional roadmaps focus on the delivery of the product. Product managers spent a significant part of their work discovering the right product. So why not emphasise this important strategic work and put it on the roadmap? Running a design sprint? Conducting Jobs-to-be-Done interviews with customers? Conducting prototype tests with users? Put it on the map!
You might raise the objection that discovery activities arent a particularly good proxy or measure for product success. Discovery is difficult to integrate in a roadmap because its hard to quantify, as the main results of discovery are learnings and insights. I agree, but nonetheless believe making discovery work visible is a good way to demonstrate the work of the product team for three reasons: First, it allows stakeholders to contribute to what and how customer research should be done, therefore moving away from an opinionated feature discussion. Second, it encourages the team to base delivery roadmap decisions on the insights generated by the discovery. Finally, it means youre being deliberate about making space for the important work and justify it to other stakeholders. Product Managers not doing this might find themselves being overwhelmed by having to deliver on product specifications.
When presenting your roadmap, make sure you share how the insights and learnings from your discovery efforts contribute to the delivery roadmap. Those insights are the outcome of your discovery, and the more transparent you are about those, the more trust and buy-in you can generate for a discovery-led roadmap and discovery activities overall.
When is such a roadmap adequate?
I would call this a discovery-driven roadmap, meaning the product discovery is the key driver of the roadmap. It can be useful both for teams who are already doing a lot of product discovery and those who believe they should be doing it. In the former case, it might help focus the discussion on the insights gained from product discoveries and away from stakeholder opinions. For the latter, it can be a good way to start making time for discovery work by demonstrating how it contributes to a better strategy and roadmap. Therefore teams who feel disempowered because the roadmap is mostly driven by management or those who do not yet have a deep customer understanding might use this to strengthen their overall focus on discovery as a core practice.
Idea #4 The OKRs-as-a-roadmap
Simple, but effective: Kill the feature roadmap all together and put your objectives and key results on the roadmap. This allows you to keep your roadmap synchronised with the product teams OKRs while also ensuring that your roadmap stays 100% outcome-focused.
The great opportunity of OKR-based roadmaps is that it forces a retrospective reflection on your roadmap. Did we achieve our intended key results? Did they pay into the overarching objectives? Have our delivery items brought the expected or desired outcomes? Any outcome-based roadmap is only as effective as the learning process behind it.
When is such a roadmap adequate?
- When you already have OKRs in place
- To keep OKRs and your product roadmap in synch
- When you want to reframe your roadmap around outcomes
- When you have established trust in the product team by delivering consistent results through your product initiatives
While a 100% key result focused roadmap sounds great in theory, in practice it can be difficult to not put any delivery items on your roadmap because your stakeholders want to understand what features are being developed. A way to solve this is to add features as key results to the roadmap when you have enough confidence in building a certain functionality. This allows other departments to plan with a release, for example in order to coordinate marketing efforts around a feature launch. Therefore a hybrid roadmap might combine the best of both worlds, putting OKRs at the centre while also including delivery items as key results.
Idea #5 (4b) Add overarching objectives to your roadmap
A very common question that Product Managers get asked is. This feature shouldnt take too long right? I cant remember how often Ive had to clarify that its the wrong question to ask.
This is a first step toward OKR-based roadmaps (hence alternatively titled 4b). If youre not ready to move over fully to OKR-based roadmaps, start by putting overarching objectives on your existing roadmap. Its a great way reframe the discussion around roadmaps from when can we do feature X to how does feature X contribute to our objectives. It will become pretty evident if your roadmap is not focussing on your most important strategic goals. Some guiding questions that this format will spark:
- Are your delivery items focused on the most important objectives of your company?
- Are you consistently aiming at these objectives or trying to get everything done at once?
To make a further step towards OKR-based roadmaps, add the target metric to each delivery item or experiment.
This approach provides a simple solution to the problem that a roadmap full of features isnt a great way to communicate to the rest of your organisation. It provides no context as to why an item might be on the roadmap in the first place and therefore misses out on the opportunity to spark a productive discussion or to enable other stakeholders to chime in.
When is such a roadmap adequate?
It is always recommendable to focus the roadmap on desired outcomes. However there are a couple of situations where this can have a particularly striking effect:
- When your roadmapping conversations are currently focused on the when can we get this done rather than what is our strategy/what are our most important product objectives
- When your roadmap lacks consistency and tries to satisfy too many users/stakeholders and once
- When its not clear to everyone in the company how the roadmap items are consistent with your companys strategic goals
When you already have a feature roadmap, avoid trying to find an objective that encompasses all of the existing items. Take a top-down approach and start with the definition of objectives based on your strategy. Your features and experiments should be a function of your strategy and objectives rather than the other way round.
2 small bonus ideas
Phrase roadmap items around user goals
Rather than describing your roadmap through features, consider putting user goals or job stories on the roadmap. Instead of relaunch signup, frame the item as Enable users to sign up in less than 1 minute, or instead of contract generation name it Enable users to generate PDF contracts as quickly as possible. Those user goals might overlap with your business objectives, and sometimes might simply be customer requests or delights. This rephrasing provides necessary context as to why roadmap items are important for your customers in the first place.
Include levels of uncertainty on your roadmap
Add the level of (un)certainty for the short, medium and long-term time frame your roadmap illustrates. When your company is working with quarterly OKRs or milestones, the current quarter likely has a high certainty, the next quarter medium certainty and beyond that low certainty. However keep in mind that just adding a small disclaimer to your roadmap is not enough. You will need to tackle this topic culturally as well.
Summary & closing thoughts
In summary, the following ideas might help you create a better strategic product roadmap:
- Visualise your roadmap as a tree of opportunities
- Structure your roadmap as a Kanban board with a Now, Next, Later column
- Put product discovery initiatives on the roadmap and clarify how they influence the delivery track of your roadmap
- Create a roadmap based on your Objectives and Key Results
- Categorise your roadmap items into overarching business objectives
The benefits and application of each concept depend on several factors, such as the maturity of your company/product, the type of product, your company culture, your planning horizon and your product development process. I believe its good to have these mental models and tools in your repertoire as a Product Manager or Leader so you can apply them as you see fit. Id be excited to see examples of how you structured your roadmap, to hear whether these approaches helped you create a better roadmap and whether this article enabled you to reframe the roadmap conversations with your stakeholders.
For a more high-level guide for creating and leading a strong product organisation, check out my last article How to build a good Product Team.
Subscribe or get in touch
To stay on top of my future articles, subscribe to my publication Product Crunch or follow me on Medium. Comment below to share your thoughts or get in touch via Twitter. Im genuinely interested in learning about your experiences and getting your feedback on my articles.
Some topic ideas for upcoming posts:
- Dealing with customer requests in B2B product management
- Roadmap buckets
- Principles of a good product roadmap
- Discussing strategy – what conversations around product roadmaps should look like
- Product strategy lessons