Roadmapping
Customer objectives
Marketing
Application
Market
supports, enables
drives, requires
Functional Products
Architect
Conceptual
Technology
technology, process
people manager
Realization
People
Process
time, ca 5 years
Gerrit Muller
USN-SE
Hasbergsvei 36 P.O. Box 235, NO-3603 Kongsberg Norway
[email protected]
This paper has been integrated in the book “Systems Architecting: A Business
Perspective", http://www.gaudisite.nl/SABP.html, published by
CRC Press in 2011.
Abstract
This article describes what a roadmap is, how to create and maintain a roadmap,
the involvement of the stakeholders, and criteria for the structure of a roadmap.
Distribution
This article or presentation is written as part of the Gaudí project. The Gaudí project philosophy is to improve
by obtaining frequent feedback. Frequent feedback is pursued by an open creation process. This document is
published as intermediate or nearly mature version to get feedback. Further distribution is allowed as long as the
document remains complete and unchanged.
All Gaudí documents are available at:
http://www.gaudisite.nl/
version: 2.0 status: concept April 6, 2021
1 Introduction
The definition of new products is a difficult activity, which frequently ends in a
stalemate: “It must be don” versus “It is impossible to realize in such a short time
frame”. The root cause of this frustrating stalemate is most often the fact that we
try to solve a problem in a much too limited scope. Roadmapping is a method to
prevent these discussions by lifting the discussion to a wider scope: from single
product to product portfolio and from a single generation of products to several
generations in many years.
The roadmap is the integrating vision shared by the main stakeholders. A
shared vision generates focus for the entire organization and enables a higher
degree of cooperating concurrent activities.
We discuss what a roadmap is, how to create and maintain a roadmap, the
involvement of the stakeholders and gives criteria for the structure of a roadmap.
2 What is in a roadmap?
A roadmap is a visualization of the future (for example 5 years) integrating all
relevant business aspects. Figure 1 shows the typical contents of a roadmap. At
the right hand side the owner of the view is shown, while the left hand side shows
the asymmetry of the views: the market is driving, while technology people and
process are enabling.
Customer objectives
Marketing
Application
Market
supports, enables
drives, requires
Functional Products
Architect
Conceptual
Technology
technology, process
people manager
Realization
People
Process
time, ca 5 years
Figure 1: The contents of a typical roadmaps
Key to a good roadmap is the skill of showing the important, relevant issues.
The roadmap should provide an immediate insight in the most relevant develop-
ments from the 5 mentioned points of view. These issues are primarily related by
the time dimension.
The convention used in this article is to show products, technologies, people or
process when they are or should be available. In other words the convention is to
Gerrit Muller USN-SE
Roadmapping
April 6, 2021 version: 2.0
page: 1
be extrovert, be oriented to the outside world. The introvert aspect, when and how
to achieve these items, are not directly shown. This information is often implicitly
present, since people and process often have to be available before the availability
of the technology, and technology often precedes the product.
Single page Poster
Top-level
roadmap part of many presentations
Single page Poster
Supporting per view
roadmaps or per driver part of many presentations
Document
Supporting per relevant
reports subject
Figure 2: The roadmap is documented at several levels of detail
A good roadmap is documented and presented at top level and at a secondary
level with more details. Figure 2 shows the desired granularity of the roadmap
documentation, the secondary level is called supporting roadmaps. The top level
is important to create and maintain the overview, while the more detailed levels
explain the supporting data. The choice of the decomposition into supporting
roadmaps depends on the domain. Typically, the supporting roadmaps should
maintain an integrated view. Examples of decomposition are:
• One supporting roadmap per key driver.
• One supporting roadmap per application area.
3 Why Roadmapping?
The Policy and Planning process as discussed in Chapter ?? relies heavily on
roadmapping as tool. The main function of roadmapping is to provide a shared
insight and overview of the business in time. This insight and overview enables the
management of the 3 other processes:
• the Customer Oriented Process
• the Product Creation Process
• the People, Process, and Technology management Process
Gerrit Muller USN-SE
Roadmapping
April 6, 2021 version: 2.0
page: 2
Where managing these processes means defining the charter and the constraints for
these processes in terms of budgets and results: Where do we spend our money and
what do we get back for it?
When no roadmapping is applied then the following problems can occur:
Frequent changes in product policy due to lack of anticipation.
Late start up of long lead activities , such as people recruitment and process change.
Diverging activities of teams due to a lack of shared vision.
Missed market opportunities , due to a too late start.
2012 2013 2014
horizon Feature still
now feature unknown
horizon Do!
now feature
horizon
Stop
now feature
horizon Do!
now feature
Figure 3: Management based on a limited horizon can result in a binary control of
product policy decisions
The frequent changes in the product policy are caused by the lack of time
perspective. In extreme cases the planning is done with a limited time horizon
of, for instance, 1 year. External events which are uncertain in time can shift into
view within the limited horizon when popular and disappear again when some other
hype is passing by. This effect is shown in Figure 3
2012 2013 2104
Preparation by
0.5 person
now feature
Work with
1.5 persons
now feature
legend Continue with
0.5 person
number of people now feature
allocated
Work with
1.5 persons
now feature
time
Figure 4: Management with a broader time and business perspective results in more
moderate control: work with some more or some less people on the feature
Gerrit Muller USN-SE
Roadmapping
April 6, 2021 version: 2.0
page: 3
The availability of a roadmap will help the operational management to apply
a low pass filter on their decisions. The control becomes more analog rather than
discrete, where the amount of people can be increased or decreased dependent on
the expected delivery date, as shown in figure 4.
An inherent benefit of roadmapping is the anticipation, which is especially
important for all long lead time aspects. Examples are technology, people and
process. This is not limited to development activities only; market preparation,
manufacturing and customer support also require anticipation. For example, reliable
mass production has a significant lead time.
4 How to create and update a roadmap
A roadmap is a joint effort of all relevant stakeholders. Typical stakeholders for
roadmapping at a typical high-tech company are
business manager , overall responsible for the enterprise
marketing manager(s)
people, process, and technology manager(s) , often called line or discipline managers
operational manager(s) , e.g. program managers or project leaders
architect(s)
Market Market Market
Products Products Products
Collective Collective Collective
meeting meeting meeting
Techno- ca 2 days Techno- ca 2 days Techno- ca 2 days Shared
logy logy logy Roadmap
People People People
Process Process Process
preparation
2 weeks to digest 2 weeks to digest
by expert
and prepare and prepare
teams
Figure 5: Creation or Update of a roadmap in "Burst-mode"
An efficient way to create or update a roadmap is to work in “burst-mode”:
concentrate for a few days entirely on this subject. To make these days productive
a good preparation is essential. Figure 5 shows the roadmap creation or update as
three successive bursts of 2 days.
Gerrit Muller USN-SE
Roadmapping
April 6, 2021 version: 2.0
page: 4
The input for the first days is prepared by expert teams. The expert teams focus
on the market, the products, and the technology layers of the roadmap. The current
status of people and process should be available in presentable format. The target
of the first burst is:
• to get a shared vision on the market
• to make an inventory of possible products as an answer to the needs and
developments in the market
• to share the technology status, trends and ongoing work, as starting point for
technology roadmap
• to explore the current status of people and process and to identify main issues
Between the first and second burst and between the second and third burst some
time should be available, at the one hand to digest the presented material and the
discussions, at the other hand to prepare the next session. The target of the second
burst is:
• to obtaining a shared vision on the desired technology roadmap
• to sharing the people and process needs for the products and technology
defined in the first iteration
• to analyze a few scenarios for the layers products, technologies, people, and
process
The thickness of the lines in figure 5 indicates the amount of preparation work
for that specific part of the roadmap. It clearly shows the the shift in attention from
the market side in the beginning to the people and process side later. This shift
in attention corresponds with the asymmetry in figure 1: the market is driving the
business, the people and processes are enabling the business.
The function of the collective meetings is to iterate over all these aspects and
to make explicit business decisions. The products layer of the roadmap should be
consistent with the technology, people and process layers of the roadmap. Note that
the marketing roadmap may not be fulfilled by the products roadmap, an explicit
business decision can be made to leave market segments to the competition.
Figure 6 shows the roadmap activities in time. Vertical the same convention
is used as in figure 1: the higher layers drive the lower layers in the roadmap.
This figure immediately shows that although “products” are driving the technology,
the sequence in making and updating the roadmap is different: the technological
opportunities are discussed before detailing the products layer of the roadmap.
Gerrit Muller USN-SE
Roadmapping
April 6, 2021 version: 2.0
page: 5
Market: What is needed by the customers?
Products: How to package technologies
into products to fulfill market needs?
Technology: What technological trends are
relevant? What technologies are needed?
People: What kind of and how many people are
required to realize the products and technologies?
Process: What processes are required to let these
people realize the products and technologies?
time
Figure 6: The roadmap activities visualized in time.
5 Roadmap deployment
The roadmap is a shared vision of the organization. This vision is implemented
in smaller steps, for instance by defining outputs per program and the related
resource allocations per program. In Figure 7 it is shown that roadmap updates
are performed regularly, in this figure every year. After determining the vision a
“budget” is derived that sets the charter for the programs. The budget is revised
with an higher update frequency, typically every 3 months. The budget itself sets
goals and constraints for the operation. The programs and projects in the operation
have to realize the outputs defined in the budget. The operational activity itself
uses detailed schedules as means for control. The schedules are updated more
frequently than the budget update. Within the operational activity the updates are
mostly event driven: changes in the market, technology or resources that render the
existing plan obsolete.
From long term vision to short term realization is a 3-tier approach as shown
in Figure 8. The roadmap provides the context for the budget, the budget defines
the context for the detailed plans. The highest tier, the roadmap, has the longest
horizon, the slowest update rate, and the broadest scope. When going down in tiers,
the horizon tends to decrease, the update rate increases, and the scope decreases.
The roadmap provides a vision, and as such is not committal. A budget is a
commitment to all involved parties. Plans are means to realize the programs and
projects, and tend to adapt frequently to changed circumstances.
6 Roadmap Essentials
We recommend to create a roadmap that fulfills the following requirements:
• Issues are recognizable for all stakeholders.
Gerrit Muller USN-SE
Roadmapping
April 6, 2021 version: 2.0
page: 6
201X 201Y
Q2 Q3 Q4 Q1 Q2 Q3 Q4 Q1
roadmap n roadmap n + 1 Policy
roadmapping and Planning
Process
business plan: Q1 Q2 Q3 Q1
budget budget
budget & allocation delta delta delta delta
detailed market market Product Creation
planning events events Process
tech hurdle tech hurdle
tech hurdle
Figure 7: The roadmap is used to create a budget and resource allocation. The
operational programs and projects use more detailed plans for control.
horizon update scope type
roadmap 5 years 1 year portfolio vision
budget 1 year 3 months program commitment
detailed plan 1 mnth-1yr 1 day-1 mnth program or activity control means
Figure 8: Three planning tiers and their characteristics
• All items are clearly positioned in time; uncertainty can be visualized explicitly.
• The main events (enabling or constraining) must be present.
• The amount of information has to be limited to maintain the overview.
6.1 Selection of most important or relevant issues
The art of making a roadmap is the selection of the most relevant issues. It is quite
easy to generate an extensive roadmap, visualizing all marketing and technological
information. However, such superset roadmap is only the first step in making the
roadmap. The superset of information will create an overload of information that
inhibits the overview we strive for.
Gerrit Muller USN-SE
Roadmapping
April 6, 2021 version: 2.0
page: 7
6.2 Key drivers as a means to structure the roadmap
In [1] key drivers are explained as an effective method to elicit and understand
requirements. Key drivers can also be very helpful in the creation and update of
the roadmap. At the marketing side the trend in these key drivers must be visible
in the roadmap. Showing key driver trends also helps to structure the roadmap.
The supporting roadmaps can clarify how the key driver trends will be supported
For instance, a technology roadmap per key driver is a very explicit way to visualize
the relationship between the market in terms of key drivers, the products with the
expected performance levels, and enabling technologies.
6.3 Nothing is certain, ambiguity is normal
A roadmap is a means to share insight and understanding in a broader time and
business perspective. Both dimensions are full of uncertainties and mostly outside
the control of the stakeholders. It can not be repeated often enough that a roadmap
is only a vision (or dream?).
The only certainty about a roadmap is that reality will differ from the vision
presented in the roadmap.
As a consequence the investment in making the roadmap more accurate and
more complete should be limited. Nobody can predict the future, we will have to
live with rather ambiguous visions and expectations of the future.
6.4 Use facts whenever possible
The disclaimer that ambiguity is normal can be used as an excuse to deliver sloppy
work Unfortunately, a sloppy roadmap will backfire to the creators. It is recom-
mended to base a roadmap on facts whenever possible Examples of sources of
facts are:
• Market analysis reports (number of customers, market size, competition,
trends)
• Installed base (change requests, problem reports, historical data)
• Manufacturing (statistical process control)
• Suppliers (roadmaps, historical data)
• Internal reports (technology studies, simulations)
Use of multiple data sources enable cross-verification of the sanity of assump-
tions For instance, predictions of the market size in units or in money should fit
with the amount of potential customers and the amount of money these customers
are capable (and willing) to spend.
Gerrit Muller USN-SE
Roadmapping
April 6, 2021 version: 2.0
page: 8
6.5 Do not panic in case of impossibilities
It is quite normal that the roadmap layers appear to be totally inconsistent For
instance, a frequent occurring effect is that the budget estimate in response to the
market requirements is 3 times the available budget1 . Retrospective analysis of
past roadmaps shows that the realized amount of work for the given budget is often
twice the estimate made for the roadmap. In other words, due to a number of effects
the roadmap estimates tend to have a pessimistic bias. The overestimation can be
caused by:
• Quantization effects of small activities (the amount of time is rounded to
person weeks/months/years).
• Uncertainty is translated into margins at every level (module, subsystem,
system).
• Counting activities twice (e.g., in technology development and in product
development).
• Quantization effects of persons/roles (full time project leader, architect, product
manager, et cetera per product).
• Lack of pragmatism, a more extensive technical realization than required for
the market needs.
• Too many bells and whistles without business or customer value.
Initial technical proposals might be more extensive than required for market
needs, as mentioned in the lack of pragmatism. Technical ambition is good during
the roadmap process, as long as it does not pre-empt a healthy decisions. The
roadmapping discussions should help to balance the amount of technology antici-
pation with needs and practical constraints.
7 Acknowledgements
The insight that a roadmap should cover all 5 views form market to process came
to me via Hans Brouwhuis. Roadmapping as a business tool gained momentum
within Philips during the quality actions inspired by Jan Timmer.
The critical and constructive remarks by Jürgen Müller helped to shape this
article.
1
This factor 3 is an empirical number which of course depends on the company and its culture
Gerrit Muller USN-SE
Roadmapping
April 6, 2021 version: 2.0
page: 9
References
[1] Gerrit Muller. Requirements capturing by the system architect. http://
www.gaudisite.nl/RequirementsPaper.pdf, 1999.
[2] Gerrit Muller. The system architecture homepage. http://www.
gaudisite.nl/index.html, 1999.
History
Version: 2.0, date: July 27, 2010 changed by: Gerrit Muller
• refactored the original roadmapping paper, split of Chnage Management
• removed the theoretical roadmap
Version: 1.2, date: July 14, 2010 changed by: Gerrit Muller
• textual changes
• figure improvements
Version: 1.1, date: June 8, 2010 changed by: Gerrit Muller
• replaced lists and tables by figures
Version: 1.0, date: May 31, 2002 changed by: Gerrit Muller
• abstract added
• readability of some figures improved
Version: 0.1, date: March 16, 2001 changed by: Gerrit Muller
• new layout propagated
Version: 0, date: December 3 1999 changed by: Gerrit Muller
• Created, no changelog yet
Gerrit Muller USN-SE
Roadmapping
April 6, 2021 version: 2.0
page: 10
