Roadmap Framework Albright Strategy Group Home 
Roadmaps and Roadmapping   
Technology Futures   
Strategy   
   
A Common Roadmap Framework

What makes a good roadmap? What questions should it answer? What direction does it set? And how should it be used?

There are many roadmapping applications, from setting scientific research agendas to industry direction to product and technology plans.  Good roadmaps follow a common format, helping guide developers and readers to critical decision points. A common framework also guides the construction of a roadmap, making sure that it sets a clear future objective and answers the critical "why-what-how-when" questions that define and explain a clear action plan for reaching the objective.

The Figure on this page shows the four parts of a common roadmap architecture that answer the "why-what-how" questions and lay out the required actions, the "to-do's."

  • The first part defines the domain of the roadmap, the team's objectives, and their strategy for achieving those objectives - the "why" of a roadmap. The roadmap's definition and strategy often include market and competitive assessments as well as planned applications.
  • The second part defines direction, or the team's plans - the "what" of a roadmap. The direction includes challenges, the architecture and evolution of the team's solution, and measurable performance targets to achieve the objective.
  • The third part describes the evolution of technologies that will be used to achieve the objective - the "how" of a roadmap. The "technology roadmap" defines the technologies that will be used to implement each part of the architecture.
  • The fourth part defines the action plan and risks - the "to-do's" of a roadmap. The action plan identifies key development actions, resources required, risks, and technology investment strategy.
All parts of the roadmap are laid out over time - the "when" of a roadmap. A roadmap may be constructed beginning with the key needs of the marketplace and customers - a market-pull perspective. Conversely, a roadmap may start with a key technology and seek to define the market needs that could be served with the new technology - a technology-push perspective.
A Common Roadmap Framework
4part_framework (16K)

Within the four part architecture, the contents of roadmaps with the most frequently encountered objectives are outlined in the table, listing for several types of roadmaps the topics covered in each of the four parts.

Roadmapping Topics
v3 Roadmap Frameworks (10K)
  • Science and technology roadmaps plot the future development of a scientific or technical field.  The scope of the scientific field and current or potential applications of the technology are linked to key technical challenges of the field.  The structure, or architecture of the field is defined and trends and potential discontinuities are identified.  The challenges are then linked to the evolution of the field in the technology roadmap.  Finally, action plans for resource allocation or investment are defined to achieve the most important technological developments.
  • Industry/government-sponsored roadmaps aim to describe the future of an industry or sector along with actions to move the industry or sector forward.  Industry structure and key directions are linked to technical challenges and those challenges are linked to technology evolution. Corporations and other organizations use roadmapping for a number of purposes such as product planning, platform planning, or organizational capability planning. 
  • Product-technology or platform roadmaps lay out the evolution of a product or platform over time. Capability roadmaps define the capabilities needed for success of a functional organization such as manufacturing or information technology or for services businesses.

Applying the common framework. The roadmapping framework has evolved from our work with clients on a wide range of objectives. We have found that using the framework in facilitated sessions helps focus a team on defining a clear future objective that is tied to customer needs or applications. The team can then define an action oriented plan to reach the objective.

We've also found in our roadmap creation and facilitation practice that the common roadmapping framework serves to pull together the many parts of a plan into an integrated roadmap. There is a normal organizational tendency to parcel out parts of a plan to each respective function with little coordination, resulting in "point" roadmaps for customer needs, products, competitors, and technologies that are barely connected or even at cross-purposes. The common framework counterbalances this functional fragmentation by tying the "points" together into a linked, integrated roadmap with a clear action plan. The framework also opens the opportunity to measure a team's roadmapping progress. See Measuring the Value of Roadmapping.


  2015 The Albright Strategy Group, LLC