From Strategy to Product Roadmap

Let’s actually start with a not-so-good definition by one of the product management gurus:

Sorry, Marty, we disagree. Yes, roadmaps, as defined here, might cause more harm — but then the definition is wrong.

Much better, Melissa, even though a bit fuzzy — how would you create an artifact for an explanation? So, let’s review another alternative:

Much better! There are several elements of that definition, so let’s decompose. A roadmap

• is a visual summary — not just plain text but a graphical illustration of the plan;

• maps out vision and direction — so describes how the vision and strategy will be implemented; see below;

• represents items over time — so, yes, a timeline is relevant, whether with explicit dates or some now/next/later representation; see below;

• contains the why and what of what is being worked on — so initiatives and features connected to strategic intents;

• is both a guiding document as well as some plan.

Putting all of that together, we define roadmaps with just slight variations to the ProductPlan version as follows:

Most people would agree that a roadmap should contain all the themes, epics, features, and stories that the team is working on. We believe

• it’s better to keep the roadmap high-level — so ignore stories and maybe even features

• but instead, add experiments or any other relevant product discovery activities (see part 3 of this playbook).

When there are so many misunderstandings and misconceptions, why do we need roadmaps at all?

Secondly, roadmaps ensure internal alignment across all teams. Specifically, when internal stakeholders are involved in creating the roadmap, this process facilitates discussions of all relevant options. It ensures transparency, for example, for the marketing team, which might need to adjust campaigns and prepare impactful launches. Finally, roadmaps help communicate with external stakeholders, be they customers, investors, or others — see our concept of public roadmaps below.

Regardless of the tool, in the following we provide a few tips for building good roadmaps:

#1 Use Strategic Intents to Structure a Roadmap

This has already been discussed: Good roadmaps reflect the strategy, e.g., by explicitly mentioning themes or strategic intents and using these to group related work items together. This offers several benefits:

• It helps to organize the roadmap meaningfully based on higher-level strategic objectives.

• It helps communicate to stakeholders, who are often interested in the strategic level but not how items are broken down.

• It lets teams rally around a strategic objective. When they finish an initiative and start the next one, it still serves the same strategic intent, so much about the problem's nature is already known.

• It ensures that all strategic intents are addressed; otherwise, it will become evident when an element of the strategy is not currently covered.

• It provides long-term transparency into the strategy: if the structure of the roadmap changes every quarter because new strategic intents are defined — then these are probably no strategic intents in the first place.

#2 Define Outcome-Based Roadmaps

Sometimes, these metrics are not as straightforward as in the case of Netflix (and I even wonder whether these were so straightforward back then or are only in hindsight). Sometimes, the data for these metrics is complex to collect. Sometimes, the feedback loop is much slower, making it difficult to act upon that data. However, any such item should start with a hypothesis on its business value.

#3 Keep Roadmaps in Problem Space

A great roadmap does not yet name solutions but still operates in the problem space. We will explore problem vs. solution space in part 3 of this playbook. For now, imagine a hypothetical company that decided to support business growth by addressing enterprise customers, thereby increasing average deal size. Listing relevant product initiatives that could yield initiatives to tackle the following problems:

All these items are still problems and challenges. They are all opportunities for which solutions can be discussed with the entire team, including engineering.

#4 Quarterly Rolling Roadmap vs. Now/Next/Later

There is a hot debate as to whether or not roadmaps should include any timing:

• Some argue that a Now / Next / Later representation is more appropriate because of the uncertainty that is in the very nature of (digital) product development.

• Others use a quarterly rolling roadmap to at least provide a rough outline of what to expect and when.

According to our experience, when we Focus on B2B, an open Now / Next / Later representation will not be sufficient in many industries. Customers will want to know when they can expect the functionality so that they can prepare for and, e.g., organize pieces of training. The Sales team will ask when a certain functionality will be available and can be sold. Even when phrased as Now / Next / Later, most people will implicitly assume a particular timing, for example, based on upcoming release schedules.

But regardless of whether an approximate timing is explicitly mentioned in the roadmap or not, it is critical to state that there are other aspects more relevant:

• Roadmaps are subject to change: Unless there is a legally binding commitment (which should be the absolute exception), then roadmaps may change without notice and solely based on the decision of the company, as represented by the product leader.

• Roadmaps need frequent updates: Even when not changed explicitly, delays in specific work packages, dependencies to other teams, and similar aspects might impact the planning. Consequently, roadmap documents, no matter the tool, are living documents and require frequent updates. Probably not every hour — but depending on the delivery process, an update after every agile sprint might be a good idea.

To illustrate the need and also find a way to deal with engineering, who frequently hesitate to give estimates, we sometimes compare these estimations with route planning as delivered by a GPS:

To emphasize the analogy: based on well-defined destination, you always know where you are, you adjust based on circumstances, and you have clear data when you have achieved your goal.

#5 Share Roadmaps Internally, Again and Again

As mentioned above, the act of creating and updating the roadmap jointly in a team to achieve alignment might even be more valuable than the actual roadmap artifact itself. Likewise, roadmaps are a highly efficient tool to communicate the status quo and progress of the product inside the organization:

• Senior executives are involved in shaping the roadmap at a very early stage when business outcomes are defined and prioritized. Also, later on, they want to be updated about the progress — which can effectively be done by showing them an up-to-date version of the roadmap. Remember the GPS analogy above: executives want to know (a) where you are and (b) your expected time of arrival.

• The Sales team has to, well, sell. So they need something to sell. Even more so in enterprise B2B environments with long sales cycles. Not only will a roadmap show them the current priorities, but it will also help explain why certain extra topics cannot be addressed right now, even though one of their prospects might ask for it.

• The Marketing team has to prepare for product launches and potentially even plan campaigns for specific target audiences, verticals, or regions. They don’t sit around idle waiting for a release date, only to jump on creating tons of marketing material. Instead, discussing the roadmap as early as possible with them will allow them to plan and prepare so that all the effort put into the product also pays off.

• And, of course, the Engineering team also needs to know what’s coming now / next / later. Also, what other teams are doing and how that creates a bigger picture. The product backlog that will be worked on, day over day, sprint over sprint, will be derived from the product roadmap.

To cope with all these different needs, it’s good practice that the roadmap isn’t actually a document (as in Microsoft PowerPoint or Apple Keynote) but a living document in some kind of collaboration tool. This is where products like Aha!, Confluence, ProductPlan, or airfocus shine because:

1. The roadmap gets updated as a byproduct of daily work: any change in priority, delay along the product backlog etc. is reflected automatically.

2. There is a single, unified, and consistent view on the roadmap accessible to the entire company.

3. This view can easily be shared with anybody in the company, in any product communication, internal newsletters, and emails.

The latter is an aspect that can hardly be overestimated. While the Product Management team works with product roadmap elements daily, others do not. So, it’s important to remind them of the underlying strategy and how we want to bring it to life. As far as telling anybody in the company about the product roadmap, it’s even more true than anywhere else:

#6 Share Roadmaps Externally

In a slightly revised version, roadmaps are also a great tool to communicate with customers and prospects as explained in more detail by way of Public Roadmaps.

#7 Don't be dogmatic but rather handle with care

Of course, Product Managers shouldn’t be dogmatic about the guidelines sketched above:

• When there is a legal requirement for specific functionality that can be achieved through an easy feature, don’t invent a strategic intent; instead, just add the feature to the backlog.

• When the solution to such a requirement is evident, skip the problem space and go to solution mode immediately.

• When there is a strict deadline for that requirement, for example, for legal reasons, then add a delivery date so everyone is aware.

We would argue that once the Product Manager is aware of the above guidelines and when exceptions are consciously decided, she is already on the safe side.