Product roadmapping has been an important topic in product management circles for decades. Despite significant backlash against them that has arisen in the last few years, they remain one of the most important artifacts a product manager can create. As a matter of fact, I would say that if you can only do one thing as a PM, create a great roadmap. I’ll elaborate on this later in the post.
So what is a product roadmap?
A product roadmap is a compound artifact that indicates what value the product team intends to deliver to the market and when. It also describes some of the “why” underlying this value and timing.
Ideally, product roadmaps are an expression of product strategy (the value to be delivered and the timing reflect strategic thought). This definition is fairly simple but conceptually dense! Let’s unpack it.
What is a product strategy?
A product strategy is a course of action that leads to success. This term implies that a clear definition of success exists. For example, success can be defined by means of goals, which are general, and objectives, which support goals and are time-bound and measurable. Strategy is about doing! The product roadmap documents the timing of delivery of value based on a product strategy, making roadmaps an expression of strategy (not a strategy in and of themselves).
A clear definition of success is critical as product managers must continuously balance the needs of the market with the needs of the organization they work for. Often, the market’s goals are contrary to our own. For example, most companies want to be as profitable as possible; prospects, on the other hand, want to pay as little as possible for the value a product delivers. Clarity on both your ambitions and the market’s needs is critical for negotiating this balance.
A product strategy describes the means the team plans to employ to bring about success. It also implies what the team does NOT plan to do. For example, a goal to increase profit margin might be accomplished by reducing expenses, increasing prices, or a combination of both approaches. A detailed strategy helps the team set clear priorities and make better (more strategic) decisions. It can sometimes be beneficial to explicitly call out things the team doesn’t plan to do to achieve success.
Product strategies can be complex and detailed but should be distilled into a “strategy elevator pitch” that calls out key “strategic pillars”. In my experience, capturing product strategy in a concise, compelling way is a massive challenge the first time a product manager tries it. It is a competency, however, that separates good product managers from the great.
Unfortunately, very few organizations have an explicit (written down) strategy. In my experience, the term “strategy” is used imprecisely, with most of us having a similar intuition as to its meaning but no shared definition.
Creating a product strategy is the accountability of product management. You should consider creating a precise definition of success and getting buy-in from key stakeholders. You can then describe a course of action for achieving that success and make sure your important stakeholders agree with it and are willing to help execute it. I’ll write more about product strategy in a separate series of posts.
Anatomy of a Roadmap
Roadmaps are compound artifacts comprising two distinct but related types of information.
The roadmap “representation” is often communicated using a list, Gantt chart, or series of milestones.
Stakeholder benefit from the “business context” related to the roadmap which provides insight into “the why” underlying the value that the team intends to deliver and the delivery timing. information like goals, target market segments, and details regarding the intended value help stakeholders understand the roadmap’s strategic relevance.
It is often valuable to combine the representation and business context in a single artifact as they support each other.
Roadmap Items
The intended value expressed in roadmaps can be described in many ways: features, feature “areas”, broad capabilities, problems, requirements, goals, and more. We generically refer to these elements as “roadmap items”. Often, roadmap items on a product roadmap aren’t parallel (some are specific features, some represent general themes like “version 1 SDK”). The critical point is that roadmap stakeholders understand the intent of roadmap items.
Your roadmap has stakeholders so should reflect the value you'll deliver according to their needs.
What a Roadmap is Not
A product roadmap is NOT a simple picture
A roadmap should provide a representation of value being delivered to the market but should also provide important business context explaining why that value and timing were chosen. Without this rationale, roadmaps are of only superficial value and represent a missed opportunity to inform stakeholders of valuable, supporting information.
A product roadmap is NOT a strategy
Product roadmaps should express strategic intent but the strategy itself is an independent artifact! Define your strategy and then create a roadmap showing the value you’ll deliver and when based on the strategy.
A product roadmap is NOT a plan
A roadmap expresses the intent to deliver value. A plan articulate specifically who will perform tasks and when. A plan must still be created to support the intent of the roadmap! I see some people talking about a “product plan” as if it’s a well-established artifact in product management circles. I’ve never seen one. Most planning happens in the context of releases and a functional release plan which includes the goals, scope, and relevant drivers of a release is a great idea (but is rarely created as a coherent artifact!).
A Contract
It is critical that the messaging around a product roadmap communicates that it is a statement of intent. Under special circumstances, some stakeholders may view elements of the roadmap as a commitment. In the B2B domain, for example, roadmaps are often used to demonstrate commitment to customers, prospects, or other stakeholders. These commitments should probably be expressed elsewhere and used sparingly.
Moving Toward Strategic Execution
I’ve been involved in product management for over 20 years. The most common failure I see on product teams is becoming overwhelmed with operational issues at the expense of thinking and acting strategically. Lack of strategic direction often leads to what Melissa Perry refers to as “the build trap”. The diagram below describes the key steps in moving beyond a reactive stance and adopting one that reflects a carefully considered strategy.
As the diagram indicates, product managers must define success, a strategy for achieving success, and finally, a roadmap clearly articulating the intent to deliver strategic value to the market. Failure to follow these steps results in thrashing between operational distractions, a massive waste of resources, and, ultimately, competitive disadvantage.
Are product roadmaps dead?
In the introduction, I said that if you can only do one thing as a PM, you should create a good roadmap. Regardless of (what I consider) reckless attestations to the contrary, roadmaps are critical for aligning internal stakeholders like leadership, engineering, and go-to-market functions. Particularly in the world of B2B, product roadmaps demonstrate commitment to the product and allow external stakeholders like customers, prospects, and partners to plan related activities.
Product roadmaps are NOT dead!
I emphasize creating a roadmap because they lie on the intersection of many other artifacts and activities. A good roadmap can at least imply a strategy. Roadmap items also give engineering and others some idea of what should be delivered. Although roadmaps are incomplete without this business context, they represent the most important contribution a product manager can make to the team.