Product roadmaps come in many sizes and flavors and depending on size and flavor answer a myriad of questions.  There are several common threads through all product roadmaps.  The common threads are:

  1.      Roadmaps are tied to the business strategy.
  2.      Roadmaps answer where are we going.
  3.      Roadmaps answer why we are making the choices we are making.
  4.      Roadmaps are tied to objectives and key results (business outcomes).

Building a Product Roadmap starts with the business strategy for the organization the map will represent.  Organizations that have not defined a business strategy will need to start by doing so.  While a small organization or department might have a single strategy, larger organizations have a number of interrelated strategies that need to be part of the roadmap and help to propel a toward an ultimate goal or key results.  For example, an article on the Harvard Business Review blog states that Google (a very large company) couldn’t survive with just one strategy, the multitude of strategies need to guide organization increase the need to communicate strategy and direction. 

The second step for a product owner is to gather information about where their product is heading.  There are many sources of facts (and alternative facts) that are used as data sources, including industry knowledge, business knowledge, meeting with customers, or interviewing subject matter experts.  The goal is to generate a big picture of the trajectory of the product rather than to dive into detail.  The trajectory of the project roadmap isn’t typically a recitation of research, but rather an interpretation and synthesis based on the business strategy.  As the synthesis occurs the product manager/owner should continually ask whether roadmap can answer the questions implied in the common threads.

On a side note: product roadmaps can devolve into information noise if the level of granularity goes too deep.  Noise will make it impossible to satisfy the common threads. One mechanism used to reduce the signal-to-noise ratio is to map themes rather than features, epics or user stories.  Jared Spool describes themes as “a promise to solve business problems.”  A theme is a higher-level concept than a feature; therefore, it is easier to link to business’ goals and strategy.  Features are more of reflection of how the business problem will be solved than a theme.  Planning in themes over a longer time horizon does not lock an organization into a specific approach to solving any specific problem in the future until absolutely necessary.

A theme-based product roadmap is often supported with IT related architectural and application roadmaps. Generating these IT roadmaps requires having access to both the business strategy and the roadmap of themes.  The business needs drive system and application architecture while at the same time are influenced by the same system and application architectures (I agree that this is circular however an organization’s legacy architecture influences where it can go in the future).  Another and perhaps more nuanced approach I have occasionally seen is the insertion of roadmap mapped to business processes.  The business process roadmap is inserted between themes and IT system and application architecture. 

Finally, specific short-term portions of the product map are typically broken down into more granular detail, such a features and epics.  While answering the ‘where are we going and why’ questions, these types of documents are more akin plans or promises to deliver specific functionality.

Product roadmaps are like sparrows.  Rarely is there just one.  Roadmaps are often really a set of maps that follow a hierarchy.  The roadmaps begin with a strategy to link themes (promises to solve a business problem) with business processes,  IT architectures, and applications. The path from strategy to application represents a hierarchy beginning the road mapping in the middle hierarchy puts the cart before the horse.  When the cart is ahead of the horse the roadmap will fail to answer where an organization is going and why the organization is going where it is going!