What is a product roadmap
A product roadmap is a statement of intent for how you are going to implement your strategy. The product roadmap is a living thing that indicates your best understanding at the point that you last updated it and it also reflects whatever uncertainty you faced when you last put it together.
A product roadmap is primarily used for communicating your product strategy to people in your organization both inside and outside your product team. Some product people may also use a product roadmap to communicate plans to customers.
Important aspects of a product roadmap
The things you should include on the product roadmap are:
Different time horizons that reflect increasing uncertainty. Instead of dates, I use Now, Next, Later, and Never.
- Now are the outcomes you know you’re working to deliver now or will start working on soon.
- Next reflects the outcomes you think you’ll work on in the foreseeable future, with the understanding that things could change.
- Later reflects the outcomes you might tackle some time. Those are the most likely to change as time proceeds.
- Never reflects the outcomes you aren’t going to tackle. Sometimes it’s good to explicitly state what you just aren’t going to do.
Don’t put dates down because when you update the roadmap you don’t know specifically when things are going to get done. If there are specific real time constraints driving the need to work on a specific outcome, you may want to note that.
Outcomes rather than outputs. Describe the needs you want to satisfy rather than the solution you’re going to use to satisfy that need. For the items in Now you probably have a solution in mind, but there’s no guarantee that will be the ultimate solution you use. Using this approach you’re properly setting expectations that you’re going to solve a specific problem – you just don’t know exactly how.
Expressing the items on the roadmap as outcomes rather than features helps to prevent output based thinking and allows you to focus on what problems you want to solve next.
Your stakeholders are going to want to know more specifics, so you can then use different ways to show progress for a given initiative that’s tackling a specific outcome, such as the parking lot diagram.
Ties back to Strategy. Depending on what you’re working on, this could be your organization’s strategy or it could be your product strategy.
An example of a product roadmap
This picture is a representation of a roadmap I pulled together for Agile Alliance to report work on the website for quarterly board meetings.
The roadmap shows specific outcomes we were trying to deliver, often expressed in terms of an outcome based metric such as “increase the number of new membership and membership renewals per month by 10%”.
The color coding identifies which of Agile Alliance’s value dials the outcome aligns with. Agile Alliance expressed it’s strategy in terms of value dials:
- Deliver value to members
- Build an inclusive global community
- Advance the breadth and depth of agile
- Build Agile Alliance brand awareness
These are the key decision filters that Agile Alliance used to decide whether to undertake activities or not. When we considered some action that’s fairly significant we ran it through these decision filters (ie “Will this help us deliver value to members?) if it does not pass through any of the decision filters, we didn’t do it.
Overall, this roadmap provided a good overview of what outcomes your organization is focusing on right now, and gives you some insight into what problems you may want to tackle next.
When to use a product roadmap
Use a product roadmap when you need to gain clarity on your product strategy and you want to communicate the problems you intend to tackle in the short and longer terms with others inside your organization.
Why use a product roadmap
Product roadmaps help you create shared understanding around your product strategy. The act of creating and revising the roadmap helps you to reach agreement on the outcome you’re trying to reach and the things you’re going to try now, next, and later to reach that outcome.
Product roadmaps provide visibility into your product strategy and communicates your plans while still allowing for the uncertainty that comes along with product development.
How to use a product roadmap
There are several ways to create and use product roadmaps. Instead of restricting the discussion to just one approach, I thought I’d share a few different approaches.
Creating a Roadmap: A Guide to Get You Started
In this post, Maddy Kirsch takes you through four key things to consider when creating your product roadmap (and will review what oversights to avoid):
- Make sure you’re using the right roadmap tool.
- Make sure your roadmap is visually clear and compelling.
- Make sure every item on the roadmap is accompanied by a strategic justification.
- Make sure you are reviewing and updating your roadmap frequently.
How to Create a Product Roadmap in 2020
In this guide to product roadmapping, Arjen Harris with Slite looks at the difference between feature vs. theme-based roadmaps, how to build your first product roadmap, how to prioritize items, and how to use and update your product roadmap.
How Do You Create a Product Roadmap?
Jens-Fabian Goetzmann describes an archetypical process to create a product roadmap. Of course, when actually creating a roadmap, this process needs to be further detailed in how it interfaces with the planning, goal-setting, and product development processes already in place.
How to Create a Multiple Product Roadmap
When you create a roadmap, you are almost always describing a roadmap representing one product. But there are times when you want a multiple product roadmap, which communicates the plans for several separate products.
In this article, the folks from ProductPlan discuss the circumstances where your team should use a multiple product roadmap. They also offer some tips for developing this type of roadmap effectively.
How to make your roadmap a living thing
You’ll want to revisit your product roadmap on a regular basis and update it to reflect the things you’ve done, the things you’ve learned and the changes in your organization and environment. This helps to keep the roadmap fresh and useful.
I revised the product roadmap for the Agile Alliance website about every 3 months as a means of providing an update to the Board of Directors. I find that’s a good cycle to revisit what we’ve done and adjust our thoughts about what things are coming up next.
My thoughts on product roadmaps are influenced by my experience and what other people have shared. Below are some of the resources I find helpful to get a better understanding of product roadmaps.
Caveats and Considerations
Some product roadmaps aren’t product roadmaps
It’s extremely important to understand what someone means when they say “product roadmap”. Often when people ask for a roadmap, they’re looking for some way to convey the expected timeframe of specific deliveries for projects. In other words, a roadmap as SAFe describes it.
Most product people would say that’s not really a product roadmap, or at least not a very good one. They’d say that primarily because it doesn’t take uncertainty into account. Yes, the SAFe version of a roadmap indicates a “commitment” and a “forecast”. It also shows dates and specific features so it implies more certainty than is probably realistic. That said, stakeholders outside of the team like this type of roadmap because it tells them when things will be delivered… until things aren’t delivered on those dates.
You may not need a Roadmap
Basecamp avoids product roadmaps in favor of organizing work into six-week cycles where they decide what to do in the next six-week cycle at the beginning of the cycle based on what they know at that point, not what they planned six months ago.
Contrast that with large organizations that brag that “they’re agile” yet rely on roadmaps that disconcertingly resemble a Gantt chart and desire healthy backlogs that project things out at least a quarter, if not longer.
Who’s right?
Perhaps there’s value in both approaches in the right context. Basecamp is a relatively small organization led by people with a specific outlook on product development.
Most large organizations have built-in dysfunctional communication channels because they are large organizations and desire the false sense of security that a fleshed-out roadmap and backlog seem to provide. It doesn’t matter if it’s accurate, just that it’s there. Of course, some people unrealistically expect accuracy in these projections as well.
Additional Resources
Outcome Roadmaps
Sean Sullivan put together a series of articles on outcome roadmaps that cover his take on tackling deadlines and commitments.
- Outcome Roadmaps -Focus product initiatives on what really matters
- From Outcomes Roadmaps to User Stories – Tackling the gap between desired outcomes and agile development
- Outcome Roadmaps with Feature Commitments – Features and other commitments are sometimes unavoidable.
Sean agrees with those who suggest that roadmaps should not show dates and deadlines to an extent, but he feels that deadlines can be a fantastic forcing function. Constraints often drive innovation. In the third article, he gets into some specific types of deadline commitments and how to deal with them.
Product Roadmaps tell you why you’re building something
Scott Sehlhorst wrote a couple of posts that explored the dual views of product roadmaps, which view was more important, and why that view means that product roadmaps are not a list of features.
Rethinking the Product Backlog. Twice.
Melissa Perri has done a lot of thinking about product backlogs and has refined her thoughts with things she’s learned by doing them along the way. The crux of her thought is that product roadmaps should focus on problems to be solved and that you can do this for products in both discovery and delivery.
Intercom on Product: One for the roadmap
On this episode of Intercom on Product Des Traynor and Paul Adams take a look at roadmapping. They discuss how they’ve approached it historically at Intercom and how this process has evolved with them to make room for a wider audience.
If you’re setting out on your roadmap journey it’s important that it reflects the point of the journey that you’re on – having everyone in a startup of 5 or 6 sharing daily tasks each morning makes sense as they work together to build a feature but in a larger company it’s a recipe for chaos. Knowing how and when to define a roadmap, whom to include and how long to plan for are key elements to finding the balanced approach that you need.
Roadmaps Are Dead. Long Live Roadmaps!
When you have questions about roadmaps, it pays to talk to someone who has spent way too much of her life thinking about them. Janna Bastow – co-founder of both Mind the Product and ProdPad – has been trying to fix the problems of roadmaps for most of her professional life. She hacked together the first version of ProdPad to solve her own problem, then began selling to other product people to help them do the same. She joined the Product Experience Podcast to give advice for anyone ready to break up with their roadmap.
Roadmap Prioritization – A Case Study
If your roadmap discussions feel like herding cats, Ian Threadgold, Head of Product Management at Kallidus, may have found a way to help your herding.
He established a transparent process to involve all the key stakeholders to arrive at priority decisions that everyone can support. You can read more about the approach on Product Focus.
How To Gain Alignment from Your Team on the Roadmap
In addition to getting agreement on your product roadmap from your key stakeholders, you also need to get your team aligned with delivering the contents of that roadmap. C. Todd Lombardo described in Mind the Product how he went about getting alignment from his team on their roadmap. He started by listening and asking a lot of questions.
Product Roadmap vs Product Backlog
The folks at ProductPlan have a different view on the usefulness of the product roadmap and product backlog. Given that they build a product road mapping tool, this is understandable. Even with that admitted self-interest, their perspective is helpful to see another perspective and for understanding how the two tools can work together.
Their take: the product roadmap and product backlog serve distinct but complementary roles in helping a product manager shepherd a product from early strategic conceptualization all the way through development and market release. The product roadmap communicates high-level strategic objectives and priorities, whereas the product backlog is a list of tasks that will serve the roadmap’s strategic plan.
Why product roadmaps are so important
Thiago Müller suggests that product roadmaps are important because, when used properly, they can help your team build a shared understanding of what you’re trying to accomplish. According to Thiago, product roadmaps help your team collaboratively gather the pieces of work and have a view of long term desired outcomes that afterward are going to be broken down into sprints, not the other way round.
7 Different Product Roadmap Formats
There are many different types of roadmaps and different formats that roadmaps can take. Anthony Murphy explains the different shapes a Product Roadmap can take in the hopes this gives you some inspiration and perhaps even makes you rethink your current roadmap format.
7 Fails of roadmap making
Roadmaps are an essential bridge between the overarching company strategy and the practical realities of your quarterly OKRs. But unfortunately, many product leaders do them wrong to the point where they not only miss their purpose but also frustrate everyone around them.
Although there are plenty of guides for approaching road mapping, sometimes it’s helpful to focus on the warnings.
So Leah Tharin shared seven major issues she sees teams making when it comes to roadmaps:
- Too much detail on effort estimates
- Too much focus on today
- Too much focus on the competition
- Too much focus on outputs
- Too public
- Not actionable enough
- Not properly communicated
7