Secondary components to answer the concerns of certain stakeholders
Features and solutions
Confidence
Stage of development
Target customers
Product areas
Complementary information to provide context for your roadmap
Project information
Platform considerations
Financial context
External drivers
A document that can effectively rally your troops around a plan needs to be more than just a list of features and dates.
It needs to tell the story of what it will be like when you achieve your vision, what it will take to get there, and how you will know if you are making progress.
A lot of product people think of a roadmap as a simple chart with dates and features, but a document that can effectively rally your troops around a plan needs to be more than that. It needs to tell the story of what it will be like when you achieve your vision, what it will take to get there, and how you will know if you are making progress.
Every roadmap is different, and exactly what yours looks like will depend on what you are trying to communicate and to whom. There’s no template or boilerplate you can plug-and-play for roadmap greatness, and a standardized roadmap doesn’t work across all organizations.
In this chapter, we will explain each of these primary roadmap components using a simple (hypothetical) product roadmap for our favorite garden hose.
There are additional, secondary components we will explain and illustrate as well. These are optional, but will deepen your roadmap and help satisfy the specific concerns of some stakeholders such as your development team, sales and marketing teams, executives, etc.
Finally, there are groupings of related information we consider complementary to a roadmap. That is, they are not part of a roadmap formally, but may provide helpful context and help to tie the roadmap to the concerns of those same stakeholders.
We’ll dig into each of these types of components in detail in subsequent chapters, but for now, let’s have an overview and see how all the components come together to build a cohesive roadmap.
Primary Components
These components are necessary for an effective roadmap. Use this section as a checklist to ensure you’ve covered the essentials.
Figure 2-1. Primary components of a roadmap
Product Vision
Product Vision Is Your Guiding Principle
Whether they call it a mission, a vision, or a purpose, organizations usually have guiding principles that offer direction toward the proverbial North Star. We think of a product vision as how a specific sort of customer will benefit from your product when it is fully realized and ubiquitous.
Chapter 4 includes an in-depth explanation and real-world examples of guiding principles such as product vision.
Business Objectives
Business Objectives Help You Measure Progress
What are the goals your product will accomplish? The outcomes? What will be measurably different for your organization? These are powerful questions that will help you explain the why of your roadmap in concrete terms, get stakeholders excited about the future, and make it easier for you to get the resources you need.
As Bryan Dunn, VP Product Management at Localytics, says, it also gives them the freedom to ask, “What kind of product do we need in order to attain those business goals?”
Chapter 4 provides more depth on this topic, including an example of a roadmap driven primarily from business objectives.
Timeframes
Broad Timeframes Avoid Overcommitment
Focusing on dates as the primary measure of success diverts attention from the iterative and uncertain process of innovation so critical in new product development. Broad timeframes like calendar quarters or even Now, Next, and Later provide guidance while preserving some flexibility. In all cases, the sequence communicates what’s important now and what can wait awhile.
Chapter 9 discusses when to include specific dates for external events and commitments, but we discourage you from including specific ship dates for the roadmap themes and solutions.
Themes
Themes Focus on Outcomes Rather Than Output
Answering the question “What would need to be true for our product to realize its vision and attain its business objectives?” is the best way we’ve found to organize the work and deliverables of your team. Expressing themes as customer needs or problems, in particular, is very effective in guiding the development of solutions (i.e., features and functions).
Chapter 5 discusses how to develop themes and subthemes, and provides real-world examples of theme-driven roadmaps.
Disclaimer
The Disclaimer Protects You (and Your Customer)
Most roadmaps contain some sort of caveat just to make it absolutely clear that anything in the roadmap is subject to change without notice. This protects you from accusations of broken promises; it also protects your customer by making it clear that change is possible, even likely.
Disclaimers of large public companies are often more elaborate. Chip-making giant Intel publishes a roadmap that provides surprisingly little detail, but being a public company, they still preface it with a prominent disclaimer. Speak to your finance or legal department about your organization’s policy here.
Meet the Wombat Garden Hose Co.
We’ll use this hypothetical company to explain how components are used to create the simple roadmap shown here.*
* It’s important to repeat that this is a very simple roadmap, used only to illustrate roadmap components. This is not a roadmap template. Roadmaps take many forms and will be highly customized to tell the story of what it will be like when you achieve your vision, what it will take to get there, and how you will know if you are making progress.
As we said at the beginning of this chapter, there is no one roadmap format that will suit every product and every organization at every stage of growth. Still, we thought it would be useful to show you an example of how these elements could come together to tell a story of value for one product. And so the Wombat garden hose was born.
Imagine you work for a garden hose company and you’ve been asked to create a new product for affluent Americans. Where do you start?
Before we walk you through the thinking behind the creation of the Wombat roadmap, take a few minutes to review how the primary components are expressed in it.
Figure 2-2. The Wombat roadmap with primary components
Developing the Wombat Roadmap
We start with the company vision, the reason we are developing products at all. This provides the grounding for everything that comes after (Figure 2-2).
Knowing that the company is focused on Americans and on making landscapes beautiful, you’d be in a good position to research what’s most important to achieving this vision (Figure 2-3).
Armed with this insight (63% of Americans surveyed indicate insufficient irrigation...), your product vision would almost be written for you (Figure 2-4).
Figure 2-3. The garden hose company’s vision
Figure 2-4. What’s most important to achieving the company vision
Figure 2-5. The product vision for the Wombat garden hose
Work with potential customers should reveal the most important problems customers face in achieving their goal of perfectly-watered landscapes (Figure 2-5).
This set of problems could easily form a set of themes to guide your development efforts—and form the backbone of your roadmap (Figure 2-6).
Note how the first problem identified (hoses kink, split, and leak) maps directly to the first theme on the roadmap (indestructibility). Each subsequent theme then reflects the next prioritized problem.
The themes are ordered into broad timeframes, beginning with half-year periods and expanding to a single column for all of 2018. The final timeframe is simply “Future.”
Additional details add color to each theme. Note that only one theme—the first—has any details about the features you’ll actually ship. Carefully chosen diagrams, mockups, demos, or other exhibits of what you are planning to build make your ideas more tangible (Figure 2-8).
Figure 2-6. The most important problems customers face
Figure 2-7. The set of themes guiding the Wombat product roadmap
Figure 2-8. Adding details and mockups to flesh out a theme
Secondary Components
These components are optional but will enhance your roadmap in important ways for certain stakeholders. Every additional bit of information, however, has the potential to backfire.
Figure 2-9. Secondary components are typically related to a specific theme, but can appear anywhere on the roadmap.
Features and Solutions Show How You Intend to Deliver on Your Themes
Features and solutions are the specific deliverables that will fulfill the needs and solve the problems identified in the roadmap themes. These details are the new features, capabilities, quantities, enhancements, updates, or optimizations you will deliver. Depending on the expectations of your stakeholders, details may be very thin or include specifics such as product specs, architecture diagrams, flow diagrams, design sketches, or even prototypes.
See Chapter 6 for guidance on how to incorporate the proper details into your roadmap and tie them to themes effectively.
Stage of Development
Stakeholders seeing labels like “discovery,” “design,” or “prototyping” on a roadmap should understand that the product is in a very early stage of development. They may be able to see and provide input on sketches, layouts, material choices, and other design aspects before they are finalized. A label like “pre-production” or “beta,” conversely, should convey that the product can be touched (or at least seen) and demonstrated, and is likely to be generally available soon.
See Chapter 6 for more examples of stage of development information in real-world roadmaps and for information on deepening your roadmap for an exploration and examples of each of these concepts.
See Chapter 9 on presenting and sharing your roadmap for more guidance on which stakeholders will benefit from which of these components.
Confidence
Indicating the level of confidence you have in your ability to address each item or theme on the roadmap in the next release is a great way to help offset the sentiment that once it’s on paper (er...pixels?), it is a promise.
Target Customers
If your product serves more than one type of customer, it may make sense to call them out specifically on the roadmap.
Product Areas
A large and complex product—or a new product where basic functionality is still being laid down in many areas—may benefit from a roadmap where themes or features are annotated by product area. Individual product areas may also have separate business objectives.
Secondary Components Added to the Roadmap
Here we’ve added some of these secondary components to enrich and provide context for the Wombat roadmap. We haven’t included all of them in this example. We think you will find that in practice, it’s best to be selective, focusing on the key information needed by your stakeholders to provide context and no more. See Chapter 6 for guidance on when to use each of these.
Figure 2-10. The internal Wombat project plan contains far more detail on the precise timing and resources involved with the effort to deliver on the roadmap. Most roadmap stakeholders would find this level of information both overwhelming and distracting.
Features and Solutions
Many product people are rightfully wary about sharing this level of detail with customers. Specific features are listed only for the indestructibility theme in the garden hose roadmap where the product is nearly ready for shipment. Later themes are too early in the development process to be that certain. For those, the problem expressed in the theme is the focus.
Stage of Development
Products in later stages of development are much more “real” to stakeholders like sales, marketing, customer support, and channel partners. The indestructible garden hose is in pre-production according to our fictitious roadmap, so these stakeholders should all be getting ready to market, sell, distribute, and support it.
Confidence
We chose not to place a confidence percentage on the Wombat roadmap. At Wombat HQ, we felt the stage of development information placed at the bottom of each theme through 2018 (and the lack of any such information in 2019), combined with the broad timeframes used here effectively communicated the tentative nature of the items further to the right. Percentages would add little more insight here.
Target Customers
It should be clear from the company vision and problem statement in the roadmap slides that the Wombat’s initial offering will be focused on American consumers. However, the Infinite Extensibility and Fertilizer Delivery themes targeted for the future are aimed at the professional landscaper market and so this new target market is indicated.
Product Areas
Each theme for the Wombatter is being developed holistically by one team with no division between product components or areas. The roadmap therefore does not call out product areas, making for an uncluttered communication to stakeholders.
Figure 2-11. The Wombat Roadmap with some secondary components added
Complementary Information
These additional categories of information are not really part of a product roadmap; however, your stakeholders will expect you to be familiar with them and ready to discuss how things like hard external dates affect the roadmap. We include this list here so you can consider whether in some circumstances it may make sense to collaborate with your key stakeholders in a joint presentation that provides some of this information for context.
We’ll discuss this concept in more depth in Chapter 9 on sharing and presenting your roadmap.
Table 2-1. Complementary information can add color and context to a product roadmap
Because work on the Indestructible hose is actually in pre-production now, questions at the project execution level are natural.
A full production schedule is not part of the roadmap, but a quick mention of the number one risk can spark the right sort of conversation with internal stakeholders who may be able to help mitigate this risk.
Other complementary information can wait for other, target conversations on those topics with the right stakeholders.
Figure 2-12. The Wombat Roadmap with some complementary information added
Components in Context
Figure 2-13. Gov.uk roadmap
Figure 2-14. Chef Automate roadmap
Components in Context
Figure 2-15. GitHub roadmap
Figure 2-16. GitHub roadmap
Components in Context
Figure 2-17. Bazel roadmap
Figure 2-18. Example roadmap
Components in Context
Figure 2-19. Insurance company roadmap
Figure 2-20. Office 365 roadmap
Summary
Roadmaps come in many forms depending on the size and life cycle of the product. All, however, incorporate core concepts such as what is coming and approximately when (or at least in what order). The most effective ones provide context about why by including an explicit statement of product vision and a set of outcome-oriented themes, together with a disclaimer making it clear all of this is subject to change.
The best roadmaps don’t obscure the core message with a lot of extraneous detail, but home in on the additional context most important to particular stakeholders.
See Chapter 9 on presenting and sharing for tips on choosing just the right details.
Now that you have a picture of what goes into a product roadmap, let’s talk about where you can start.
Product Vision
Business Objectives
Timeframes
Themes
Disclaimer
