In a previous post, I offered a definition of the term “product roadmap” and discussed its relationship to concepts like strategy. My definition is:
A product roadmap is a compound artifact that indicates what value the product team intends to the deliver to the market market and when. It also describes some of the “why” underlying this value and timing.
Now that I’ve established what a roadmap is, a perfectly reasonable question is “What makes a good roadmap?” In this post, I’ll suggest criteria I think are important in separating common or average product roadmaps from great ones.
Great Roadmaps Are Validated by Stakeholders
A great product roadmap was created in consultation with important stakeholders and has been explicitly validated by them. That means stakeholders like Engineering, Marketing, and Sales were asked for input and provided ongoing feedback as the roadmap was defined and refined. Once the roadmap stabilized, they provided written acknowledgment that they have a high level of confidence that executing the roadmap will lead to product success.
Getting stakeholder validation can be thought of as a three-step process. Stakeholders should contribute to and sign off on
1. a clear definition of success for the product
2. a product strategy to achieve success
3. the product roadmap reflecting the product strategy.
Getting explicit validation is important as it forces people to make a conspicuous gesture. Beyond a binary agree/disagree, it’s interesting to capture a “confidence interval” by asking, “What is your level of confidence (0-100%) that the product will be successful if we follow this roadmap.” Low average confidence means you’ve got work to do (you may have an executable roadmap, but it may not be leading to success).
Great Roadmaps Have the Right Level of Detail
A common roadmap question I get is how much detail a roadmap should contain. My answer is “As vague as you’re stakeholders will allow it to be.” Your roadmap, like your product, needs to meet the needs of its “consumers”. Different stakeholders will almost certainly expect different levels of detail from your roadmap. For example, engineering will require enough information to assess the impact on capacity. Other stakeholders, like leadership, may be happy with a few bullets that describe the direction of the product thematically. The section below on roadmap versions extends this point.
Great Roadmaps are Mapped to Product Strategy
Business Motivation is a term that includes the ends we’d like to achieve expressed as goals and objectives as well as the means, strategy and tactics, we intend to employ to achieve success. A good roadmap is based on an explicit (written) business motivation. The items on the roadmap are then explicitly mapped to corresponding objectives and strategy, e.g., strategic pillars.
You should not leave it to the audience to do this mapping themselves, especially senior leadership. BTW, not everything on the roadmap will be strategic; some items represent tech debt or basic “blocking and tackling”(tactical) activities and that’s OK. However, if a significant number of roadmap items can’t be mapped to strategy, the roadmap is likely too reactive.
Great Product Roadmaps are Balanced
Building a great product roadmap is a balancing act. Unfortunately, simply prioritizing a huge list and creating items on the roadmap based on it will often result in a roadmap that is not balanced along one or more of these dimensions:
existing customers vs. rest of market
tech debt vs. feature work
evolution of new features vs. enhancing existing features
support for short-term vs. long-term goals
Achieving this balance requires some strategic thought and top-down guidance on how much capacity should be invested in each category. Taking the time to assess balance can help avoid shipping a product that addresses top priorities but, a.) doesn't excite anyone
and b.) doesn't really move the bar for any scenario or user type
Great Product Roadmaps Provide Details on Roadmap Items
You shouldn't assume that a simple word or phrase representing a roadmap item is sufficient for your audiences to understand the value you plan to deliver. A roadmap artifact should include content that provides more context on each roadmap item. Information, like problem addressed, segment served and likely impact on success, are hugely valuable to stakeholders' understanding.
Great Product Roadmaps Communicate Business Context
Your product roadmap provides you with an excellent opportunity to help your stakeholders understand the rationale behind the value you intend to deliver and the timing. For example, the roadmap should be a clear reflection of your product strategy; sharing at least an overview of your definition of success and the associated strategy demonstrates to the product team that they and you are executing strategically. Other information you should consider sharing:
Market overview including size, growth
Target market segments
Business Model, e.g., canvas
Ecosystem Overview
Timing Drivers & Rationale
A Great Product Roadmap Has Versions
Because roadmaps serve a variety of disparate stakeholders, mature product organizations almost inevitably generate multiple roadmap versions -- it's simply too difficult to meet the needs of all stakeholders with a single representation. In my career, I had a "master" roadmap with all items and then filtered and edited that list depending on the audience. Tons of bug-fixing? That probably wouldn't be highlighted in the version I show my leadership (just being honest!). Talking to market analysts? Create a product roadmap version that highlights innovation.
Conclusion
The roadmapping process sits at the intersection of many other processes, e.g., strategy definition, release planning, prioritization, and requirements gathering. If we're going to take the time to build a roadmap, it's worth making sure it's great by ensuring it:
is mapped to business motivation
is balanced
provides details on roadmap items
communicates business context
has versions as necessary
Comments