=Paper=
{{Paper
|id=Vol-2305/paper16
|storemode=property
|title=Why feature-based roadmaps fail in rapidly changing markets: A qualitative survey
|pdfUrl=https://ceur-ws.org/Vol-2305/paper16.pdf
|volume=Vol-2305
|authors=Jürgen Münch,Stefan Trieflinger,Dominic Lang,Rafael Chanin,Dron Khanna,Kai-Kristian Kemell,Wang Xiaofeng,Afonso Sales,Rafael Prikladnicki,Pekka Abrahamsson,Katariina Yrjönkoski,Anu Suominen,Matthias Gutbrod,Jürgen Münch
|dblpUrl=https://dblp.org/rec/conf/sibw/Munch18
}}
==Why feature-based roadmaps fail in rapidly changing markets: A qualitative survey==
https://ceur-ws.org/Vol-2305/paper16.pdf
SiBW 2018 202
Why Feature-Based Roadmaps Fail in Rapidly
Changing Markets: A Qualitative Survey
Jürgen Münch1, Stefan Trieflinger1 and Dominic Lang2
1 Reutlingen University, Alteburgstraße 150, 72762 Reutlingen, Germany
2 Robert Bosch Smart Home GmbH, Schockenriedstraße 17, 70565 Stuttgart, Germany
Abstract.
Context: Companies in highly dynamic markets struggle increasingly with
their ability to plan their future product portfolios and to create reliable feature-
driven roadmaps. It seems that the traditional process of product roadmap crea-
tion that aims at providing a stable plan for all involved stakeholders does not
fulfill its purpose anymore. However, the underlying reasons as well as necessary
changes to the roadmap process are not widely analyzed and understood.
Objective: This paper aims at getting an understanding of current problems
and challenges with roadmapping processes in companies that are facing volatile
markets with innovative products. It also aims at gathering ideas and attempts on
how to react to those challenges.
Method: As an initial step towards the objectice a semi-structured expert in-
terview study with a case company in the Smart Home domain was conducted.
Four employees from the case company with different roles around product
roadmaps have been interviewed and a content analysis of the data has been per-
formed.
Results: The study shows a significant consensus among the interviewees
about several major challenges and the necessity to change the traditional
roadmapping process and format. The interviewees stated that based on their ex-
perience traditional feature-based product roadmaps are increasingly losing their
benefits (such as good planning certainty) in volatile environments. Furthermore,
the ability to understand customer needs and behaviors has become highly im-
portant for creating and adjusting product roadmaps. The interviewees see the
need for both, sufficiently stable goals on the roadmap and flexibility with respect
to products or features to be developed. To reach this target the interviewees pro-
posed to create roadmaps based on outcome goals instead of product features. In
addition, it was proposed to decrease the level of detail of the roadmaps and to
emphasize the long-term view. Decisions about which feature to develop should
be open as long as possible. Expected benefits of such a new way of product
roadmapping are higher user-centricity, a stable overall direction, more flexibil-
ity with respect to development decisions, and less breaking of commitments.
Keywords: product management, product roadmap, agile requirements man-
agement, requirements engineering, agile development, innovation manage-
ment, customer development, UX, lean UX, lean development, portfolio
roadmap, portfolio management.
SiBW 2018 203
1 Introduction
Nowadays the environments for creating new products, services and business models
are getting increasingly complex and changing rapidly. Some of the reasons are the
emergence of new technologies, high connectivity through the Internet, high availabil-
ity of knowledge and ressources due to globalization, rapidly changing customer be-
havior and less predictability of markets and demands. From the point of view of prod-
uct and service development new development approaches are emerging that are highly
customer-centric and data-based with an emphasis on rapid learning. New products and
services capture new markets in ever shorter time intervals. New competitors are revo-
lutionizing traditional market structures and require considerable changes from estab-
lished incubents. This situation has impact on the development and review of product
roadmaps. Established enterprises are struggling more and more with their ability to
plan their future product portfolios and to create reliable feature-driven roadmaps for
the products. Startups also have significant problems with traditional product roadmap-
ping. It seems that the traditional process of product roadmap creation that aims at
providing a stable plan for all involved stakeholders does not fulfill its purpose any-
more. However, the underlying reasons as well as necessary changes to the roadmap
process are not widely analyzed and understood.
This paper aims at understanding current problems and challenges with product
roadmapping. It also aims at gathering ideas and attempts on how to react on those
challenges. The paper is organized as follows: Section 2 provides an overview of related
work. Section 3 presents the research questions and the research study. The results of
the study are discussed in Section 4. Finally, an outlook on the future of product
roadmaps and further research is sketched.
2 Related Work
A comprehensive overview on the topic of product roadmapping in volatile business
environments has been described by Suomalainen et al. [1]. Here, we focus on the core
terminology of traditional product roadmapping, describe key problems with traditional
roadmaps, and sketch some approaches that go beyond this traditional approach.
Kostoff and Schaller generically define a “road map” as a “layout of paths or routes
that exists (or could exist) in some particular geographical space. In everyday life, road
maps are used by travelers to decide among alternative routes toward a physical desti-
nation. Thus, a road map serves as a traveler’s tool that provides essential understand-
ing, proximity, direction, and some degree of certainty in travel planning” [2]. Phaal
and Muller consider a roadmap as an aggregation of relevant information to an inte-
grated view on the evolution of a complex system [3]. According to Kappel [4]
roadmaps are forecasts of what is possible or likely to happen in order to make better
decisions. DeGregorio points out that roadmaps are visualizations of a forecast, which
can be applied in a number of key areas such as technology, capability, parameter, fea-
ture, product, platform, system, environment or threat and business opportunity [5].
Albright defines roadmaps as living documents that describe a future environment and
SiBW 2018 204
objectives to be achieved within that environment. In addition, he mentions that
roadmaps are plans for how those objects will be accomplished over time. Furthermore,
the author suggests that it is advisable to review and update a roadmap over time, oth-
erwise it is not useful [6].
The process to create a roadmap is called roadmapping [2]. Nearly every company
applies its own roadmapping process [7]. A main reasons for this is that enterprises
have different markets as well as different cultures [8]. An appropriate roadmapping
process for a company depends on many factors such as the level of available resources
(people, time, budget), the kind of issues being addressed (purpose and scope), or the
available information (market and technology). Roadmapping provides a platform for
sharing different perspectives and information. Furthermore, the stakeholders of a
roadmap can develop a common vision of where the company is going in the future [9].
Roadmapping can be done on different levels. Kappel categorizes roadmaps in four
categories based on their purpose and emphasis. These four categories are “Science /
Technology Roadmaps”, “Industry Roadmaps”, “Product-Technology Roadmaps” and
“Product Roadmaps” [4]. Phaal et al. identify the following eight types based on their
intended purpose: product planning, capability planning, strategic planning, long range
planning, knowledge planning, program planning, process planning, and integration
planning. In spite of different taxonomies every type of roadmap seek to answer the
following questions: 1) Where are we going? 2) Where are we now? 3) How can we
get there? [7].
The purpose of a product roadmap is to predict the development of products, features
or services over a long period [10]. Typically, product roadmaps are created, reviewed
and improved iteratively. For this purpose, human interactions such as face-to-face
meetings or workshops play an important role [7].
From the perspective of software product management, the product roadmap pro-
vides an overview about the direction of a product, feature or service develoment. Of-
ten, a product roadmap provides information about new releases or versions, their
schedules and the major topics [11]. Sometimes, a roadmap describes also dependen-
cies between product and platform technology. In some cases, the roadmap contains
financial information. For example, estimated revenue and costs are included. In prac-
tice, usually the business owner of a product is responsible for the product roadmap.
This can include the collaboration and agreement with stakeholders or constant updat-
ing of the product roadmap. Usually, a product roadmap has a time horizon of three to
five years. [12] In this time frame the roadmap should be undergoing a regular updating
process to ensure that the roadmap is developing in the right strategic direction and
contains the current state of technical development [1].
Regarding the roadmapping process various approaches have been developed.
Lethola et al. [12] suggest that the roadmapping process should consist of the phases
“preparation”, “approval” and “communication”. The phases “theme identification”,
“core assets” and “roadmap construction” are part of the approach developed by van de
Weerd [13]. Vähäniitty [14] considers the process in four steps, which should be per-
formed periodically in order to adjust the roadmap to the changing market situations
including new information. The steps are defined as “define strategic mission and vi-
sion”, “scan the environment”, “revise and distill the product vision as product
SiBW 2018 205
roadmaps” and “estimate product life cycle and evaluate the mix of development efforts
planned”. Each step has defined objectives. The process is especially developed for
creating and updating product roadmaps.
Komssi et al. [15] suggest a six-step roadmapping process based of the analysis of
the customer value and customer´s processes. The approach includes the building of a
cross-functional team (first phase), the examination of the business strategy (second
phase), the selection of a customer segment (third phase), the identification (fourth
phase) and analysis (fifth phase) of customer activities and linking the business poten-
tial of customer activities into the roadmap (sixth phase).
According to the study “Roadmapping” [16], roadmaps are widely developed, dis-
tributed and used in a feature-driven mode. This means that the roadmap contains prod-
ucts or features for a defined time horizon.
In the following, several reasons for using traditional roadmaps and problems with
traditional roadmaps are summarized (based on Cagan [17]). Important reasons for us-
ing traditional feature-based roadmaps are that the management of a company wants to
make sure that the teams are working on the highest-business-value items first. On the
other hand, the management wants to be able to predict, when the products or features
are ready for market launch. In order to do this, the management usually arranges a
quarterly or annual planning session, where the leaders consider the ideas and negotiate
a product roadmap. This procedure implies multiple challenges which will be discussed
in the following.
First of all, a feature-driven roadmap is only a scheduled list of product or features.
In rapidly changing environments such a roadmap includes many uncertainties and is
typically undergoing many changes over time. Consequently, a company might lose
reliability to external partners and the management might lose an essential controlling
tool.
Another issue due to Cagan is that anytime you put a lot of ideas on a document
entitled roadmap, no matter how many disclaimers you put on it, people across the
company will interpret this item as a commitment to develop it. This leads to a change
of focus from the actual needs of the customer to the functionality of the product or the
system with its features. The criteria for success is no longer customer satisfaction, but
to deliver them “on time”. This procedure leads to the risk that the enterprise moves in
the wrong direction and in some cases might run out of business.
Furthermore, Cagan mentions that at least half of the ideas on a product roadmap are
just not going to work. The most frequent reasons are that the customers are not excited
about an idea. This circumstance can be attributed to the underlying assumptions about
the user or the feature itself. Here is an example: an assumption could be that the user
would like to have an intelligent roller shutter control for the summer. However, the
real customer might only need a cool room. Therefore, the assumption that the intelli-
gent roller shutter control is the right solution for this customer is not necessarily cor-
rect. If there is a better solution available for the customer, the product “intelligent roller
shutter” might not be able to survive in the market.
Several approaches on how to evolve traditional roadmapping have been proposed.
Pichler [18] distinguishes between a so-called feature-based roadmap and a so-called
goal-oriented product roadmap. The feature-based roadmap can be seen as the format
SiBW 2018 206
that is traditionally used for product roadmaps. It defines the dates for upcoming re-
leases and the features that are included in each release. It does not define correspond-
ing goals that are expected to be fulfilled with each release. In contrast the goal-oriented
roadmap includes the following information: the release dates, a goal associated with
reach release, and the features associated with a release. Figure 1 shows the difference
between these two types of product roadmaps. The goal-oriented product roadmap
shifts the conversation from discussing features to agreeing on strategic objectives,
making smart investment decisions, and aligning stakeholders [19]. Goal-oriented
roadmaps do not consider explicitly if certain features on the roadmap are suitable
means for reaching the respective goals.
Fig 1. Feature-based Roadmap vs. Goal-oriented Roadmap [18]
Jeff Patton has created an approach called User Story Mapping. It starts with the
identification of the customer journey along the horizontal axis. In the case of a web
shop, the customer journey could be “search for a product”, “view product details”,
“add a product to shopping card”, and “buy the product”. In a second phase the core
user stories are determined, prioritized, and mapped to the customer journey. Examples
for user stories are “enter credit card info”, “enter delivery address”, and “confirm or-
der”. In the further phases the definition of the releases take place [20]. An interesting
aspect of User Story Mapping is that releases can be planned by walking down the
vertical axis and defining goals. Appropriate functionalities can be considered and
tested before implementation with respect to reaching the release goal. This way, User
Story Mapping can be seen as a new way of product roadmapping that goes beyond
traditional formats and approaches.
3 Study Approach
This section gives an overview of the study approach. It starts with presenting the re-
search question and continues with a description of the study context, i.e., the case
company. Afterwards, the study design including the data collection and analysis, the
study execution, and the discussion of validity are sketched.
SiBW 2018 207
For the study the following research questions are defined:
RQ1: Which approaches and methods for creating and updating a product roadmap
are currently applied by the case company?
RQ2: What challenges and success factors are associated with product roadmap-
ping in the case company?
3.1 The Case Company
The study has been conducted at the Robert Bosch Smart Home GmbH (HOME), re-
ferred to as case company in the following. The case company is a business unit of the
BOSCH Group. It was founded in 2016 as an independent subsidiary. It is engaged in
smart home activities and offers a wide range of products, features and services in the
business field of smart home. Products developed by HOME are, for instance, intelli-
gent heating control and automated house surveillance. The actual number of employ-
ees is about 150. For this study interviews with four employees from the case company
were conducted who were involved in the roadmapping process [21].
3.2 Study Design
The study was conducted by using a qualitative survey method. The qualitative survey
method was chosen because the study has the objective to obtain new insights with
respect to procedures, challenges and success factors in the area of “product roadmap-
ping” in the context of a case company. To achieve this objective, the experience, opin-
ions and views of the experts needed to be obtained. Therefore, the qualitative survey
method (including semi-structured interview, observation, and content analysis) was
preferred over the quantitative survey method [22].
Moreover, Fink identifies several opportunities, in which a qualitative survey
method is appropriate. The following four aspects are relevant regarding this study: 1)
The study is focused on investigating the knowledge and opinions of experts in a par-
ticular field. 2) The study intends to collect information in the interviews with own
words rather than with using predefined choices. 3) There is not enough prior infor-
mation of the study subject to enable either the use of standardized measures of the
construction or a formal questionnaire. 4) The sample size is limited due to access or
resource constraints [23].
3.3 Data Collection and Analysis
Semi-structured expert interviews with participants of the case company were used to
collect data. The expert interview is a method of qualitative social research. [24] In an
expert interview the participants can answer the questions by using free speech and a
self-chosen terminology. In the following, typical characteristics of an expert interview
are listed.
SiBW 2018 208
Table 1. Characteristics of an expert interview [25]
Motivation Professional interest
Process: Constructive
Motivation of the interviewee: Presentation/Transfer of knowledge
Criteria of exclusion (interviewee): Interviewee is not an expert
Criteria for exclusion (interviewer): Unfamiliarity with the topic
An interview guide was developed to structure and focus the interview with the pre-
defined topics and to ensure the thematic comparability of the various interviews (the
complete interview guide is available in Appendix 1). In addition, the interview guide
was created in order to avoid that important aspects are ignored [26].
The developed interview guide consists of three parts. It begins with an opening part
including the background of the interviewed person. The main part contains questions
with respect to the predefined topics. Finally, the closing part considers topics which
were not considered up-front in the interview guide [27].
For a detailed data analysis, all interviews were audio recorded and transcribed. The
most important findings were identified and examined through a analytic content anal-
ysis.
3.4 Study Execution
The study participants were selected experts from the case company. According to
Mieg [25] the experts can be characterized as persons who have authorisation to a cer-
tain field and are involved in decision making processes based on their position. In this
research the authors refer to those experts, who have specified knowledge and skills
about product roadmapping and are involved in roadmapping activities.
The case company was represented by four interviewees. All interviewees held po-
sitions in the middle management. The participants represented the departments sales
business operations, IT coordination, product management and brand and marketing
communications. The purpose and the procedure of the study were shared with the in-
terviewees via an up-front email.
The individual expert interviews were conducted in the office at the case company
on September 21, 2018. The average length of the interviews was 47 minutes, with the
range spanning between 33 and 52 minutes. One researcher conducted all interviews in
face-to-face conversations. An overview of the background of the interviewees is
shown in Table 2. The experience refers to the amount of years in which the person was
involved in roadmapping activities.
SiBW 2018 209
Table 2. Overview of the interviewees
Interviewee Role Experience
Interviewee 1 Head of Sales Business Operations Department 20 years
Interviewee 2 IT Coordinator 1 year
Interviewee 3 Head of Product Management Department 12 years
Interviewee 4 Marketing and Brand Manager 20 years
3.5 Validity
Yin [28] proposes to consider the construct validity, the internal validity, the external
validity, and the reliability for assessing the validity and trustworthiness. We use this
framework as the basis for the discussion of validity of our study. Other frameorks exist
such as the framework from Campell and Stanley [29] that are also applicaple for this
kind of studies.
Construct validity refers to the correct operational measures for the concepts being
studied [28]. As a means for establishing construct validity the goal and the purpose of
the interviews were explained to the interviewees before the interviews. In addition, the
way of data collection through semi-structured interviews allowed for asking clarifying
questions and avoiding misunderstandings.
Internal validity refers specifically to whether an experimental treatment/condition
makes a difference or not, and whether there is sufficient evidence to support the claim
[29]. This criterion can be tested with respect to the validity claims for communicative
actions, according to Habermas [30]. These criteria are defined as follows: 1) Clarity
describes to which extent the interviewees understand the questions or whether there
occur any linguistic discrepancies; 2) Legitimacy refers to the cooperativeness of the
interviewees; 3) Trueness refers to find no contradictions in the statements, 4) Sincerity
consider the completeness of the statements. The following discusses the internal va-
lidity according to Habermas:
Clarity: The interviewees were experts with many years of experience in the field of
roadmapping. Each participant was a native speaker in the interview language Ger-
man. In cases where the questions were unclear to the participants, they asked further
questions.
Legitimacy: Each interviewees were interested in the research and answered the
questions in a detail manner. So, in summary there was a very cooperative atmos-
phere.
Trueness: The experts came from different disciplines, so they asked the questions
from various perspectives. The analysis showed that there were no major contradic-
tions between the perspectives.
Sincerity: Each interviewee answers the question extensively and there was no indi-
cation of missing parts of the topic.
SiBW 2018 210
The external validity is defining the domain to which the studies can be generalized
[28]. Regarding this study the external validity is restricted, because the results are only
valid in the context of the case company. Thus, the results are not transferable to other
fields of investigation. Anyhow, the company might be similar to other German com-
panies in the IoT or Smart Home domain. Therefore, an analytic generalization might
be possible to such similar companies.
The reliability describes whether a study produces stable and consistent results. For
example, the data collection procedures can be repeated with the same results [28]. The
reliability was supported by providing an interview guide that is publicly available.
Although the study was just an initial effort to answer the research questions, the anal-
ysis has been conducted in a systematic and repeatable way. Therefore, a replication of
the study and a reduction of researcher bias is supported.
4 Results
This section sketches the product roadmapping practices of the case company (answer-
ing research question RQ1). Afterwards the challenges and the success factors that were
seen in the case company are outlined in two different sections (answering research
question RQ2).
4.1 Product Roadmapping Practice
The current product roadmap format of the case company resembles a coordinate sys-
tem. On the y-axis you find domains like security, climate or lighting. The x-axis rep-
resents the time dimension (see Figure 2). Usually a time horizon of 12 months is used.
The products and features are put on the roadmap according to their associated domain
and their planned development time (i.e., start and end date). Moreover, each feature
contains the information when the rollout (i.e., the software deployment to the cus-
tomer) is ready or in the case of hardware when the market launch is to be expected.
This procedure provides a clear overview of the planned market launches to external
and internal partners.
SiBW 2018 211
Fig. 1. Product roadmap format at the case company
Currently the management board is responsible for the product roadmap. However,
the management is delegating the product roadmap creation into the hands of the prod-
uct management. In practice, the head of the product management department is re-
sponsible for the product roadmap. This responsibility includes creating and updating
the product roadmap as well as the coordination of other stakeholders with respect to
the roadmap. These stakeholders are the departments “Portfolio Management”, “Engi-
neering”, and “Marketing and Sales”.
For creating the product roadmap and for adding new products, features or services
the following approach is applied: “Currenty we have the procedure that the manage-
ment and I, the head of the product management department define criteria to asses a
product, service, or feature proposal. Typical examples for such criteria are 'Does the
product have a unique selling proposition?', 'Is there a demand from the perspective of
the customer?', and 'How much revenue is estimated?'. Each of these criteria is given
a specific weight. This could be, for example, a factor 4 for the estimated revenue while
the customer demand might be calculated with a factor 3. Every product, feature or
service is then evaluated and receives a score based on the mentioned criteria. This
score reflects a priority, i.e., the higher the score the higher is the priority and the
product, feature or service is more likely to be put onto the roadmap at an earlier time.”
(Head of Product Management Department). Furthermore, an analysis of the social me-
dia channels and service-tickets is conducted. The results of these analyses are also
included in the decision process and can lead to minor adjustments.
New ideas for products, services or features can stem from many different sources,
especially customers. In case of an update for an existing product, surveys with users
will be conducted.
Every month, the product management has a meeting with the other stakeholders in
order to make a concrete decision about which products, services, and features should
SiBW 2018 212
be put on the roadmap. At this meeting, the product managers are presenting their find-
ings of their market research and discuss them with the other stakeholders. The market
research is conducted by the department “Product Management” and includes which
products or features are expected from customers and what products are developed by
the competitors. Another input to the meeting is so-called GfK data. This GfK data
describes consumer behavior and can be used to identify potential delivery areas.
In the next step the development department estimates the development time. The
estimation takes the budget and the available resource into account. The estimation also
aims at answering the question whether a completion of the planned feature is possible
in the scope of the target release. If it is not possible to deliver on time, the product,
feature or service might be moved to a later release.
The prioritization of the previously selected products, features or services is mainly
based on financial aspects. “A financial forecast is conducted with the goal to find the
products, features or services that have the highest impact on achieving the revenue
targets of the company. This financial forecast has the highest impact on the prioriti-
zation.” (Head of Product Management Department) Other criteria that are used in the
prioritization are the strategic alignment, the customer demand as well as the contribu-
tion to the development of a competitive advantage.
Another topic of the monthly meeting is the revisiting of the current roadmap. The
participants analyze the impacts of the last four weeks and try to identify deviations
from the roadmap or needs for changing the roadmap. A typical situation is a change
of capacity or budget. Such a situation might be that the company cannot develop a
planned hardware because of a lack of budget. Another example is that the engineering
has to fix a lot of bugs the next two sprints. This might lead to a delay in the completion
of the planned features and to a deferral of the products on the product roadmap. Con-
sequences could be that features with a low prioritization are removed from the product
roadmap or a market launch gets delayed. Also market-driven events (e.g., from DIY
stores and electronic stores) or technological innovations might lead to a change of the
product roadmap. “The rise of conversational interfaces such as Amazon’s Alexa is an
example for a technological innovation that has a significant impact on many product
roadmaps in the smart home domain. Without the integration of such devices or eco-
systems, the competitiveness of many smart home products would be threatened.”
(Head of Sales Business Operation Department). The revisiting of the product roadmap
includes a review with respect to delays of prioritized products.
4.2 Challenges of the Product Roadmapping Process
The case company operates in an innovative and highly dynamic market environment
with rapid changes and disruptive participants entering the market. This imposes sev-
eral challenges to the roadmapping process. Table 3 gives an overview of the challenges
that were mentioned in this study.
The product roadmap developed by the case company covers a 12 months period.
Thus, […] concrete products or features are defined over an incalculable long time
horizon with many uncertainties […] Nowadays, a long-term-planning with reliable
and stable information (i.e., with features, products and services) is no longer possible
SiBW 2018 213
due to rapidly changing markets.” (IT Coordinator) The volatile market environment
and difficulties with predicting development activities require frequent updates of the
product roadmap. Reasons for these changes are, for instance, a decline in demand for
certain products, development delays due to unforseen events or other important things.
Frequent changes to the roadmap currently lead to high additional cost and sometimes
delayed marked launches of new products.
Furthermore, a constantly changing roadmap is likely to decrease the employee´s
awareness for the overall strategy and company vision. Moreover, the new planning
consumes a lot of capacity of the participating employees which could be used more
efficiently.
“One factor for creating a roadmap is that marketing needs to plan campaigns long-
term ahead and sales requires an reliable outlook of the product portfolio including the
future products and features to present it to potential customers.” (IT Coordinator) In
both cases the mentioned departments require a certain reliability to which point in time
a product, feature or service will be available.
Finally,“in some cases ideas for new products, services or features come from man-
agement or investors with the expectation that these ideas will be implemented without
any delay and independently from the current planning. Often, the implementation of
these ideas leads to an unforeseen change of the product roadmap.” (Head of Product
Management Department) The result is a shift of some features to a later point in time
and hence often means a delayed product launch.
Table 3. Challenges with current product roadmapping
Product Roadmapping – Current Challenges
Many uncertainties exist due to rapid changes of markets, technologies, and
customer behaviors.
Time horizon of a roadmap is too long.
Frequent changes of the current roadmap are necessary.
Frequent changes of the roadmap impose severe consequences (high cost, de-
lays, and planning overhead).
Difficult alignment of the roadmap with product vision and long-term com-
pany strategy.
Marketing and sales require long-term predictions for features, products and
services in order to plan their activities (such as campaigns).
Management or investors sometimes overrule product roadmaps.
4.3 Success Factors of Product Roadmapping
Another objective of this study was to gain insights into the success factors of product
roadmapping. Table 4 gives an overview of the expected success factors for future
roadmapping activities that were mentioned in this study.
The experts from the case company mentioned that a good understanding regarding
the market as well as the ability to live with uncertainties are important success factors.
“A good understanding of the market is necessary for creating a good roadmap. Maybe
SiBW 2018 214
also the abibility to deal with uncertainties is necessary. This means accepting that
nobody exactly knows which product we will launch in a year […] and also accepting
that the roadmap will become fuzzy looking in the long term horizon.” (IT Coordinator)
This means that each employee must accept that a roadmap provides detailed infor-
mation only over a short period of time (e.g., product planning for the next 3 months).
In the case of a volatile environment with rapid changes it is impossible to plan in detail
for a long-time-period. The planning should be conducted continuously to ensure that
the roadmap is always up to date and that the company can always rely on a detailed
plan for a short-term period.
The experts also mentioned that a roadmap should help to give all stakeholders an
idea of the product vision and the direction the company will go in the future.
Another central theme that was mentioned as success factor in the interviews is that
the needs of the customers should be included in the roadmapping process, […] “the
fulfilment of customer needs is the prerequisite for creating successful products that
generate revenue.” (Head of the Product Management Department) A central question
has to be: “In which way do the contents of the roadmap contribute to solving a current
problem of the customer?”(IT Coordinator) The financial review was also mentioned
as a success factor.
Table 4. Success factors for product roadmapping
Product Roadmapping – Success Factors
Ability to live with uncertainty.
Good understanding of markets and customer behaviors.
Detailed planning only for a short period of time.
Continuous planning.
Connecting the roadmap to the fulfillment of customer needs and business
goals.
Alignment of the roadmap with product vision and company strategy.
5 Outlook and Further Research
As part of the study we also asked the participants about their proposals for improving
product roadmaps and related process in the future. We also aim at building a substan-
tive theory of goal-driven or outcome-driven roadmaps that can be applicable in a wider
context. We expect that we will also narrow down research questions when gaining a
better understanding of the research area.
The interviewees mentions that future roadmaps should be structured in a problem-
or outcome driven form. This means that the roadmap should not contain products,
features or services, but instead current needs and problems from the perspective of the
customers (i.e., customer outcomes) and the related business goals (i.e., business out-
comes). Thus the roadmaps are widely outcome-oriented and the way to reach this out-
come (e.g., which features are built to solve the customer problem and/or reach the
business outcome) is left open. This procedure allows that all aspects such as future
SiBW 2018 215
technologies and trends can be taken into consideration. It also allows to conduct ex-
periments in order to determine if certain features are suitable to reach the outcomes
(ideally before implementing them).
Therefore, future product roadmap should be designed in an outcome-oriented way.
This means that the information contained in a long-term roadmap should only reflect
the current needs or problems of the customers as well as the business goals and not the
possible solutions. This allows the company to stay flexible in deciding which solution
fits best and therefore leads to a better fulfillment of the customer demands. Moreover,
it is assumed that an outcome-driven and user-centric approach for the roadmapping
process offers an effective planning of the operative measures and more space for cre-
ativity.
In summary, the traditional procedure for the roadmapping process is not suitable
anymore for an agile and innovative environment. Hence a new approach is required.
This new approach has to provide a flexible customizability to adapt to rapid market
changes as well as provide sufficient planning security with respect to outcomes. Other
disciplines such as marketing and sales will also need to change their way of working.
It might be that they need to plan long-term marketing campaigns based on outcomes
instead of available features.
The challenge for many companies will be to adjust and replace their traditional
product roadmaping and introduce a new modern roadmapping process that makes
them ready for a volatile highly dynamic environment. Further investigations regarding
the abilities of an outcome-driven and user centric roadmapping process (including the
roadmap format and organizational and cultural aspects) are necessary in order to find
a new approach that fits today’s dynamic and complex environments.
References
1. Suomalainen, T: Changing the planning for agile and lean software development – From
roadmapping to continuous planning. Juvenes Print, Tampere (2016).
2. Kostoff, R., Schaller R.: Science and Technology Roadmaps. IEEE Transactions on Engi-
neering Management 48(2), 132 – 143 (2001).
3. Phaal, R., Muller, G.: An architectural framework for roadmapping: towards visual strategy.
Technological Forecasting and social change – An international journal 76(1), 39 – 49
(2009).
4. Kappel, T.: Perspectives on roadmaps: how organizations talk about the future. The Journal
of Product Innovation Management 18(1), 39 – 50 (2001).
5. DeGregorio G.: Technology Management via a set of dynamically linked roadmaps. In: Pro-
ceedings of the 2000 IEEE Engineering Management Society. EMS-2000 (Cat.
No.00CH37139)”, pp.184 – 190. IEEE, Albuquerque, NM, USA (2002).
6. Albright, E.: A Unifying Architecture for Roadmaps Frames a value scorecard. In: IEMC
'03 Proceedings. Managing Technologically Driven Organizations: The Human Side of In-
novation and Change, pp. 383 – 386. IEEE, Albany, NY, USA (2004).
7. Phaal, R., Farrukh, C.J.P., Probert D. R.: Developing a technology roadmapping system. In:
A Unifying Discipline for Melting the Boundaries Technology Management. pp. 99 – 11.
IEEE, Portland, OR, USA, (2005).
SiBW 2018 216
8. Groenveld, P.: Roadmapping Integrates Business and Technology. Research Technology
Management 50(6), 49 – 58 (2007).
9. Phaal, R., Farrukh, C.J.P., Probert D. R.: Technology roadmapping - A planning framework
for evolution and revolution. Technological Forecasting and Social Change 71(1-2), 5 – 26
(2004).
10. Albright, R. E., Kappel T. A.: Roadmapping In the Corporation. IEEE Engineering Man-
agement Review 31(3), 31 – 40 (2016).
11. Kittlaus, H.B, Clough, P.N: Software Product Management and Pricing: Key Success Fac-
tors for Software Organizations. Springer-Verlag, Berlin Heidelberg (2009).
12. Lehtola, L., Kauppinen, M. and Kujala. Linking the Business View to Requirements Engi-
neering: Long-Term Product Planning by Roadmapping. In:
Proceedings of the 13th IEEE International Conference on Requirements Engineering (RE),
pp. 439 – 446. IEEE, Paris (2005).
13. Van de Weerd, I., Bekkers, W., Brinkkemper Developing a Maturity Matrix for Software
Product Management. In: Tyrväinen, P., Jansen, S., Cusumano M. A. (eds.) Software Busi-
ness – First International Conference, ICSOB, pp. 76-89. Springer Heidelberg (2010).
14. Vähäniitty, J., Lassenius, C., Rautiainen, K.: An Approach to Product Roadmapping in
Small Software Product Businesses. In: Kontio J., Conradi R. (eds.) Proceedings of the 7 th
European Conference on Software Quality (ESCQ) - Quality Connection, pp. 12-13.
Springer, Heidelberg (2002).
15. Kommsi M., Kauppinen, M., Tohonen, H., Lethola, L., Davis, A.M.: Integrating Analysis
of Customer´s Process into Roadmapping - The Value-Creation Perspective. In:19th Inter-
national Requirements Engineering Conference (RE), pp. 57 - 66. IEEE, Trento, Italy
(2011).
16. Schimpf, S., Abele, T.: Praxisstudie Roadmapping, Frauenhofer IAO und Tim Consulting
(2016).
17. Cagan, M.: Inspired: How To Create Products Customer Love. 2 nd edn. SVPG Press, Cal-
ifornia (2018).
18. Pichler R.: “Strategize: Product Strategy and Product Roadmap Practices for the Digital Age.
Pichler Consulting (2016).
19. Pichler R.: Agile Product Management with Scrum: Creating Products that Customer Love.
Upper Saddle River, New Jersey (2010).
20. Patton, J.: User Story Mapping: Discover the Whole Story, Build the Right Product. O'Reilly
Media, Sebastopol (2014).
21. Bosch Smart Home GmbH, internal source (2018).
22. Thomas, T. R.: Blending Qualitative & Quantitative Research Methods in Theses and Dis-
sertations, Corwin Press, Thousand Oaks, California (2003).
23. Fink, A. Analysis on Qualitative Surveys. In: Fink A. (eds.) The Survey Handbook, pp. 61
– 78. SAGE Publications, Thousand Oaks, California (2003).
24. Ullrich, P.: Das explorative ExpertInneninterview: Modifikationen und konkrete Umsetzung
der Auswertung von ExpertInneninterviews nach Meuser / Nagel. In: Engartner, T., Kuring
D., Teubl T. (eds.) Die Transformation des Politischen. Analysen, Deutungen, Perspektiven,
pp. 100 – 109, Karl Dietz Verlag, Berlin (2007).
25. Mieg, H. A., Näf M.: Experteninterviews in den Umwelt und Planungswissenschaften – Eine
Einführung und Anleitung, 2nd edn. Institut für Mensch-Umwelt-Systeme (HES), ETH Zü-
rich (2005).
26. Meuser, M., Nagel, U.: Experteninterviews – vielfach erprobt, wenig bedacht: ein Beitrag
zur qualitativen Methodendiskussion. In: Garz, D., Kraimer, K. (eds.) Qualitativ-empirische
Sozialforschung: Konzepte, Methoden, Analysen, Westdt. Verl., Opladen (1991).
SiBW 2018 217
27. Mayer, H.O.: Interview und schriftliche Befragung. Entwicklung, Durchführung und Aus-
wertung, 4nd edn. Wissenschaftsverlag GmbH, München (2009).
28. Yin, R. K.: Case study research: Design and methods, 5. edn. SAGE Publications Inc., Lon-
don (2014).
29. Campbell, D., Stanley J.: Experimental and quasi-experimental designs for research, Hough-
ton Mifflin Company, Chicago (1963).
30. Habermas, Jürgen: The Theory of Communication Action – Reason and the Rationalization
of Society, edn. 1 Beacon Press, Boston (1984).
SiBW 2018 218
Appendix 1. Interview Guide
Background of interviewee:
1. What is your current position in your company?
2. How many years have you been working in the company?
3. How long are you involved in the topic product roadmapping?
Company Information:
4. Can you briefly describe the business sector your company operates in and the
products it develops?
5. What kind of development process do you use?
6. How often do you deploy new versions to customers?
Current roadmapping practices:
7. Who is responsible for the development of the product roadmap in your com-
pany?
8. Which information does the product roadmap contain?
9. What is the procedure of product roadmap creation?
10. Who is involved in the product roadmapping process?
11. Which information is used for creating the product roadmap? Where does this
information come from?
12. How do you prioritize the product roadmap?
13. How do you make decisions which contents are included or removed from the
product roadmap?
14. How do you review the product roadmap?
15. What are criteria for a good product roadmap?
16. In which way do you integrate other stakeholders such as other departments,
customers, or suppliers in the product roadmapping process?
17. In which situations are you changing the product roadmap and how do you
change it?
18. What is the process for changing the product roadmap?
Challenges, success factors and improvement proposals:
19. Are there any challenges or obstacles regarding the product roadmap process?
20. In your opinion, which factors are supporting the product roadmapping pro-
cess?
21. Do you think your current practices of product roadmapping are ideal? If not:
How should they ideally be performed in the future?
Final questions:
22. Do you have any further comments about product roadmapping issues in the
context of your company?
23. Do you have any further questions related to this interview or the study in
general?