This document provides an introduction to product roadmapping. It defines a product roadmap as a plan that outlines steps aligned with product strategy to advance a product in a planned direction. A product roadmap captures part of the product strategy related to the product itself. It is created through a collaborative process involving stakeholders and is informed by discovering customer needs. The roadmap helps prioritize requirements and identify features for future releases to progress the product in line with its vision and strategy.

1. Pragmatic Approach for Building
Great PRODUCT ROADMAP
Translating Product Strategy into Product Roadmap
Murali Erraguntala
www.ProductGuy.in
2016
(2nd Edition)

2. Page | 1
www.ProductGuy.in
Pragmatic Guide for Great PRODUCT ROADMAPPING
Table of Contents
TABLE OF CONTENTS...................................................................................................................... 1
TABLE OF FIGURES.......................................................................................................................... 3
INTRODUCTION .............................................................................................................................. 4
WHAT IS PRODUCT ROADMAP?.................................................................................................... 6
NEW PRODUCT ROADMAP.................................................................................................................. 8
FEATURE ROADMAP .......................................................................................................................... 9
WHAT IS NOT A PRODUCT ROADMAP?.................................................................................................. 9
WHY PRODUCT ROADMAP .......................................................................................................... 10
PURPOSE OF PRODUCT ROADMAP ............................................................................................. 11
PRODUCT MANAGER....................................................................................................................... 11
CUSTOMERS.................................................................................................................................. 11
ENGINEERING MANAGER ................................................................................................................. 12
SALES ........................................................................................................................................... 12
BUSINESS DEVELOPMENT MANAGER (BDM)....................................................................................... 12
INTERNAL ROADMAP VS EXTERNAL ROADMAP......................................................................... 13
REQUIREMENT VS NEED............................................................................................................... 16
CONTEXTOF REQUIREMENTS............................................................................................................. 17
FIVE WS ....................................................................................................................................... 18
DISCOVERY OF NEEDS .................................................................................................................. 20
DISCOVERING VS UNDERSTANDING REQUIREMENTS ............................................................................... 20
DISCOVER OF CUSTOMER FOCUSED NEEDS ........................................................................................... 20
DISCOVERY OF MARKET FOCUSED NEEDS.............................................................................................. 22
COLLABORATIVE DISCOVERY OF NEEDS – WHO CAN PARTICIPATE?......................................... 27
NEEDS FROM SUPPORT TEAM............................................................................................................ 28
NEEDS FROM ENGINEERING TEAM...................................................................................................... 30
NEEDS FROM SALES......................................................................................................................... 31
NEEDS FROM BDMS....................................................................................................................... 32
BASIC TENETS OF COLLABORATIVE DISCOVERY....................................................................................... 33
NEEDS FROM CONFLUENCE OF MULTIPLE MINDS ................................................................................... 34
IMPORTANCE OF ‘WHY’.................................................................................................................. 34
ABILITYOF PRODUCT MANAGER TO FACILITATE COLLABORATION............................................................. 35
CATEGORIZATION OF REQUIREMENTS – TACTICAL, STRATEGIC AND DISRUPTORS................. 37
TACTICAL...................................................................................................................................... 37
STRATEGIC .................................................................................................................................... 37

3. Page | 2
www.ProductGuy.in
Pragmatic Guide for Great PRODUCT ROADMAPPING
DISRUPTOR ................................................................................................................................... 39
PRODUCT OFFERING VS MARKET MATRIX ............................................................................................. 39
RATIO OF TACTICAL/ STRATEGIC / DISRUPTOR REQUIREMENTS IN ROADMAP....................... 41
INFLECTION POINT – SEIZING THE OPPORTUNITY...................................................................... 49
PERILS OF INFLECTIONPOINT............................................................................................................. 49
OPPORTUNITY –TO DISPLACE INCUMBENTS......................................................................................... 50
RISK – TO AVOID BEING DISPLACED .................................................................................................... 51
PRIORITIZATION OF PRODUCT REQUIREMENTS......................................................................... 58
IDENTIFICATION OF PRODUCTOBJECTIVES (AKA GOALS).......................................................................... 58
IDENTIFICATION OF PRODUCT ATTRIBUTES............................................................................................ 60
PRODUCT ATTRIBUTES VS PRODUCT LIFECYCLE..................................................................................... 63
SCORECARD TECHNIQUE - GUIDELINES................................................................................................ 64
BRAINSTORMING............................................................................................................................ 67
PM-ENGINEERING JOINT OPERATION................................................................................................. 68
COST VS VALUE .............................................................................................................................. 69
TECHNICAL DEBT............................................................................................................................ 74
WHY I DON’T ENTIRELY RELY ON SCORECARD METHODOLOGY?................................................................ 74
ACTIVITY VS TASKS.......................................................................................................................... 76
HOW TO PRIORITIZE SMALLER FEATURES.............................................................................................. 77
PRIORITIZATION OF DEFECTS VS REQUIREMENTS.................................................................................... 79
IDENTIFICATION OF FEATURES FOR FUTURE RELEASES ............................................................................. 80
LONG TERM PRODUCT ROADMAP –IS IT MANDATORY?.......................................................................... 81
DEADLY MISTAKES TO AVOID DURING PRIORITIZATION OF REQUIREMENTS.......................... 82
PRODUCT REQUIREMENT BACKLOG – HOW TO MANAGE......................................................... 87
RECORD NEEDS .............................................................................................................................. 87
NEEDS TRIAGE................................................................................................................................ 88
CATEGORIZE NEEDS......................................................................................................................... 89
REFINE NEEDS................................................................................................................................ 90
DRAFT THE PRD............................................................................................................................. 90
PRIORITIZE THE REQUIREMENTS......................................................................................................... 90
ORGANIZE BACKLOG........................................................................................................................ 90
MEASURE THE EFFICACY OF PRODUCT ROADMAP..................................................................... 92
PRODUCT OBJECTIVES (AKA GOAL) METRICS......................................................................................... 93
FEATURE USAGE METRICS................................................................................................................. 95
GAUGE THE MOOD – MEASURE THE PERCEPTION.................................................................................. 96
CUSTOMER HIJACKING THE PRODUCT ROADMAP – HOW TO AVOID....................................... 98
CONCLUDING THOUGHTS .......................................................................................................... 101
ANNEXURE A............................................................................................................................... 102

4. Page | 3
www.ProductGuy.in
Pragmatic Guide for Great PRODUCT ROADMAPPING
Table of figures
FIGURE 1: WHY? WHAT? AND HOW? OF PRODUCT VISION, STRATEGY AND ROADMAP.......................7
FIGURE 2 - TIME TO ANNOUNCE ROADMAP......................................................................................14
FIGURE 3 - SHOPPING CART..............................................................................................................18
FIGURE 4 - CATEGORIZING REQUIREMENTS ......................................................................................38
FIGURE 5 - PRODUCT OFFERING VS MARKET.....................................................................................40
FIGURE 6: MCKINSEY 3 HORIZON FRAMEWORK................................................................................41
FIGURE 7: TECHNOLOGY HYPE CYCLE (SOURCE:GARTNER)................................................................46
FIGURE 8: ADOPTION CURVE AND MATURITY CURVE (SOURCE: GARTNER)........................................48
FIGURE 9: INFLECTION POINT...........................................................................................................49
FIGURE 10: ADOPTION RATE OF DEVICES IN US HOUSEHOLD.............................................................52
FIGURE 11: ADOPTION RATE OF PERSONAL COMMUNICATION DEVICE .............................................53
FIGURE 15 – PRODUCT PRIORITIZATION CYCLE..................................................................................60
FIGURE 12 - FEATURE VALUE VS EFFORT ...........................................................................................72
FIGURE 13: ORGANIZING PRODUCT REQUIREMENT BACKLOG ...........................................................88
FIGURE 14: CATEGORIZING REQUIREMENTS BACKLOG......................................................................91
FIGURE 15 – PRODUCT PRIORITIZATION CYCLE..................................................................................93
FIGURE 15 - PRODUCT ATTRIBUTES FEEDBACK LOOP.........................................................................94

5. Page | 4
www.ProductGuy.in
Pragmatic Guide for Great PRODUCT ROADMAPPING
Introduction
GREAT product roadmap evolves from product vision and product strategy. Further, it
acts as a single most important document that provides a unified and consistent view of
where the product is heading to all the concerned stakeholders (Engineering Team,
Sales Team, Account Team, Business Development Team, Sr. Management, Customers,
and Partners).
Product vision and strategy should provide a framework and guidance for the
preparation of GREAT product roadmap, and it should be the overarching principle that
governs the process of preparing product roadmaps. The process for the preparation of
GREAT product roadmap involves a series of linear and nonlinear activities planned and
executed meticulously by Product Manager. The process is also collaborative comprising
of all the stakeholders either directly or indirectly involved with the product. The
process triggers with the discovery of needs through broader understanding and
anticipation of customer business challenges, pain points, and desired business
outcomes. Discovery of needs is a never-ending activity and Product Manager
periodically branches out a linear set of activities from discovery of needs to perform
the following
 Convert needs into requirements
 Draft requirements into PRD (Product Requirements Document)
 Categorize requirements into tactical, strategic, and disruptor categories
 Identify percentage split for each of those categories
 Socialize requirements with engineering team,
 Derive metrics for prioritization of requirements using scorecard methodology
and
 Ruthlessly prioritize requirements balancing both short-term and long-term
objectives in alignment with the product strategy.
In addition, Product Manager should evaluate the efficacy of product roadmap and
should provide a mechanism to reinforce the feedback back into prioritization process
for effective and efficient prioritization of product requirements.
When the industry is going through the cusp of enormous technological changes related
to IoT (Internet of Things), Big Data, Mobility, Cloud, Virtualization etc., the role of
GREAT product roadmap is indispensable for a successful technology transition. The

6. Page | 5
www.ProductGuy.in
Pragmatic Guide for Great PRODUCT ROADMAPPING
GREAT product roadmap plays a dominant role in forking out resources from the current
product (aka Cash Cow) for validating the new technology. It does through applying lean
techniques to eliminate uncertainties surrounding the application of new technology
towards creating a better value for customers. GREAT product roadmap does it without
affecting the revenues of existing products. Roadmap further plays a critical role during
the technology shift from older product to newer prototype as new technology matures
and old technology marches into sunset mode. When the older product is inching closer
to the inflection point, the roadmap should systematically shift the revenues and
resources from the older product to newer prototype while possibly accelerating the
technology shift to reduce transition time.
Rest of the eBook elaborates on aspects outlined above. Contents of this eBook were
available as a series of blog posts on my blog (www.ProductGuy.in). I deeply appreciate
your efforts to drop thoughts or comments on my blog or through email. The entire
content is born out of my experiences of being a B2B (Business-to-Business) Product
Manager for the hardware product, so there is a possibility of certain bias in the
methodologies outlined in this eBook towards B2B products.
A copy of the eBook is downloadable from www.ProductGuy.in/eBooks
Happy Translating Product Strategy into GREAT Product Roadmap!!!
Murali Erraguntala
Blog| Email

7. Page | 6
www.ProductGuy.in
Pragmatic Guide for Great PRODUCT ROADMAPPING
What is product roadmap?
The product roadmap is a plan that outlines a series of tactical steps in alignment with
product strategy to push the product ahead in the trajectory of planned direction. Every
product should have a vision that defines the purpose and reason for the existence of
the product and where the product should be heading. The strategy would then define a
path to get there by drafting a plan of action detailing how to get there. The strategy
involves aspects related to both product and non-product (e.g. marketing campaigns,
support, pricing etc.). Product roadmap captures part of the strategy related to the
product. The product roadmap is a plan of action that reflects product strategy.
Let me take a step back for further pondering upon what is product vision, product
strategy, and product roadmap. How does each of them are interrelated? Product vision
defines why the product exists - what is the single most important purpose both from
the perspective of customers and organization that the product is intending to fulfill.
Product Manager is often busy conceiving features that should be added to the product,
but (s)he loses sight of the fundamental foundation upon which the product is built. The
foundation that defines what organization believes in and the belief that dictates what
product should stand for, why does it exists and what it is intended to achieve. Have you
ever wondered what does great companies like Apple, Google, Facebook, Toyota, and
Honda etc. believe in, are n’t their products direct reflection of what they believe.
Therefore, every product should embody the beliefs and product vision should be a
reflection of those beliefs.
What does Apple believe in – Shall I state ‘Innovation, Simplicity and Building Great
Products’.
In the words of Tim Cook1
, following are the values that define Apple.
We believe that we’re on the face of the Earth to make great
products”
We believe in the simple, not the complex”
1 Source: https://hbr.org/2012/04/its-not-what-you-sell-its-what

8. Page | 7
www.ProductGuy.in
Pragmatic Guide for Great PRODUCT ROADMAPPING
“We believe in saying no to thousands of
products, so that we can really focus on the
few that are truly important and meaningful to us”
Are n’t all the products that Apple build and evolve revolve around the above stated
beliefs?
Often over time, what the product does, who are its target customers, what it intends to
achieve for an organization (in terms of revenue, growth, market expansion etc.) can
change. However, there will not be a change in what the organization believes in and
how the belief dictates the way Organization build, evolve and design products, unless
there is a change in the overall direction of the organization. What products does an
Organization build and how does an Organization build those products are centered on
the belief that defines the purpose behind its existence.
Product strategy outlines the path to evolve the product during the course of its life
cycle guided by the product vision. While the vision sets the overarching goal of where
the product should head in accordance with the product purpose and product
objectives (WHY?), strategy defines the patch to accomplish the product vision (WHAT?)
and product roadmap defines the exact steps or procedures executed along the path to
realize product vision (HOW?)
Figure 1: Why? What? and How? Of Product Vision, Strategy, and Roadmap
Product Vision
Product Strategy
Product Roadmap

9. Page | 8
www.ProductGuy.in
Pragmatic Guide for Great PRODUCT ROADMAPPING
“Product roadmap is a plan of execution that reflects
how the product will be evolved both in short-term
and in long-term in accordance with the product
strategy. Product roadmap outlines the list of product
requirements, solutions or new products planned to be
released over a period of time that would precisely
reflect the direction in which the product is heading”
At the outset, product roadmap is definitely not a discreet list of features. It has a theme
or purpose attached to it and delivery of items outlined in the product roadmap will
contribute either directly or indirectly to the realization of product objectives and
product purpose.
New product roadmap
As the name suggests, this roadmap will outline new products or platforms planned for
launch in future. Duration of new product roadmap is long term (around 2 years,
assuming new product introduction takes 12-18 months). If there is a plan to roll out
successive products in the product line, then new product roadmap will generally span
for 2-3 years. The actual duration of new product roadmap will primarily depend on the
nature of the product (hardware or software), complexity of the product and duration
to develop new products. The roadmap actually captures the timeline to build and roll
out a full-fledged product for general availability and not just the beta version. Product
roadmap for new product definitely goes beyond the MVP (Minimum Valuable Product).
Product roadmap is definitely not a discreet list
of features; it has a theme or purpose attached
to it and delivery of items outlined in the
product roadmap will contribute either directly
or indirectly to the realization of product
objectives

10. Page | 9
www.ProductGuy.in
Pragmatic Guide for Great PRODUCT ROADMAPPING
Feature roadmap
Feature roadmap would contain product requirements addition to an existing product
line. The product requirements could be segregated based on themes (usability,
performance, technology, new solutions, etc.) or market segments. The duration of
feature roadmap will be utmost 12-18 months in general. The duration essentially
depends on the timeline of each release. I generally suggest capturing utmost 3-4
releases in the roadmap. If it is agile development methodology with a quarterly release
window, then feature roadmap could span for a year. In the case of new product just
launched into the market, it might be tough to prepare a long-term roadmap especially
if the product is addressing a new or emerging market and the customer needs are not
lucid. The duration of the feature roadmap is therefore dependent on the volatility of
the market in addition to several other factors.
What is not a product roadmap?
The product roadmap is definitely not a committed plan. It evolves with changes in
business, customer needs, and other related factors. It is not prepared in haste and
definitely not in a reactive mode, product roadmaps are prepared pro-actively to set the
direction for the product. The addition of features to the product roadmap does not
happen randomly to fill the roadmap. Instead, Product Manager adds features to the
product roadmap after careful evaluation of roadmap under the below mentioned
parameters and prioritized accordingly:
1. How it helps customers’ business
2. How it helps in achieving product objectives
3. How it helps in realizing product purpose
4. How it is aligned with product strategy
‘The purpose of roadmap’ and ‘why roadmap is required’ might throw lot better
perspective of what constitutes a product roadmap and what does not constitute a
product roadmap.

11. Page | 10
www.ProductGuy.in
Pragmatic Guide for Great PRODUCT ROADMAPPING
Why product roadmap
Lack of product roadmap is akin to the famous quote of Benjamin Franklin
If you fail to plan, you are planning to fail”
Lack of product roadmap would render product directionless and Product Manager is
possibly providing an opportunity to all the stakeholders to steer the product in
different conflicting directions without any purpose or objective. Without any
appropriate approach to building product roadmaps, every product release will contain
bug fixes and a small set of insignificant features or features that require less effort.
There is no immediate impact, but slowly and steadily the sales would decline, the rate
of new customer acquisition dwindles, the gap widens with competitor products,
customers whine about the lack of features that really excite them and they lose
confidence in further investing in the product.
It is highly crucial that product roadmap has to be driven and prepared meticulously by
Product Manager in consultation with all the relevant stakeholders (Customers,
Engineering Team, Sales, BDM etc.) in a compelling manner such that the product
roadmap reflects product growth strategy. Please be aware that product roadmap is just
a plan and not a commitment, so Product Manager should add necessary disclaimers to
product roadmap providing sufficient indications that it is prone to changes.
Lack of product roadmap is akin to the famous
quote of Benjamin Franklin - ‘If you fail to plan,
you are planning to fail’

12. Page | 11
www.ProductGuy.in
Pragmatic Guide for Great PRODUCT ROADMAPPING
Purpose of product roadmap
The product roadmap apart from providing a blueprint of where the product is heading
and how the product will evolve over the next few years, they also serve a specific
purpose to various stakeholders and I have highlighted those purposes explicitly in this
section. Each of those purposes further emphasizes the importance of product roadmap
and why it is essential for Product Manager to have an exclusively focus on preparing
product roadmap.
Product Manager - Product roadmap preparation as a regular activity pushes the
Product Manager to explicitly outline product purpose and consciously rethink about
product objectives. Later outline the product growth strategy to accomplish product
objectives based on the findings from competitive, customer and market analysis.
Preparation of product roadmap as a well-defined process will therefore consciously let
Product Manager ponder upon the product growth strategy to accomplish product
objectives. Typically, the preparation of product roadmap should be a top-down activity
but in the event of no conscious effort by Product Manager to construct product vision
and strategy, the process to the definition of product roadmap as outlined in this eBook
will allow Product Manager to explicitly focus on product vision and strategy. Product
Roadmap is also an important document that can aid Product Manager to reason out or
justify the budget requirements for product development.
Customers – Primarily, product roadmap provides confidence that the product is
evolving. Secondly, it indicates the direction in which the product is heading. The
information is critical for customers to understand whether the evolution of the product
is in alignment with their business objectives. Thirdly, it provides timelines and list of
product requirements available in each product release. Fourthly, customers can plan
their business (expansion, launch of new services etc.) accordingly. Finally, roadmap
when shared with customers regularly eliminates conflicts or ambiguity between
requirements expected by customers and requirements delivered in future releases.
On the 4th
point, many of you might question if product roadmap is just a plan, how
customers could plan their business in accordance with the product roadmap. When I
talk about the roadmap, I am talking about a timeframe of 18-24 months and I generally
split the roadmap into multiples pieces depending on the duration of each release. The
probability that the contents of the product roadmap will change is relatively higher as

13. Page | 12
www.ProductGuy.in
Pragmatic Guide for Great PRODUCT ROADMAPPING
we inch closer to the end of 2nd year. Nevertheless, the initial contents (0-6 months and
6-12 months) do not change much and customers can use that data for half-yearly or
yearly planning.
Under certain exceptional conditions, Product Manager sells the product to customers
promising some set of features. In such scenario, the roadmap will act as a commitment
to deliver the promised features within the committed timeframe. Failing to do so might
attract penalties (depending on the clause signed with a customer).
Engineering Manager – Even though product roadmap would have been derived in
consultation with the engineering team, it provides direction to engineering manager on
how to align his/her resources to deliver requirements added to the product roadmap.
In the case of new technology introduction or new product development, engineering
team can also fathom about the need for new competencies accordingly can plan to
either build or acquire those competencies.
Sales – Sales team can use the roadmap to close deals, to retain existing customers and
to attract prospective customers because roadmap provides the following inherent
advantages:
 Product roadmap, when planned and prepared well, can provide the competitive
advantage.
 Product roadmap can commit product requirements of either current or
prospective customers. The product roadmap is mostly a plan but in certain
cases, few deals beget a need for commitment to deliver new requirements or
new product. In such specific scenarios, product roadmap acts as a commitment
to deliver requested requirements or new product within promised duration.
 The product roadmap is a sign that the product is evolving to meet future
business challenges of both existing and prospective customers.
Business Development Manager (BDM) – BDMs can look forward to expanding the
business into new territories or new market segments if Product Manager prioritizes
product requirements specifically for foraying the product into new geographical
regions or new market segments. Even otherwise, BDMs can estimate the revenue
potential in their territory not only based on the current product capabilities but also
based on the product capabilities available in future.

14. Page | 13
www.ProductGuy.in
Pragmatic Guide for Great PRODUCT ROADMAPPING
Internal roadmap vs External roadmap
In most cases, there would be an internal and external roadmap. Product Manager does
not directly add a requirement to the external roadmap and share it with customers.
Most likely scenario is that after Product Manager discovers a customer need, he will
convert the need into a product requirement and discuss with engineering team to give
a proper shape to the requirement. What I precisely meant by giving proper shape to
the requirement is that while Product Manager will explain ‘What’ and ‘Why’ of the
requirement, engineering team can figure out ‘How’ part of the requirement to conduct
a high-level feasibility analysis and estimate the time frame required to deliver the
requirement. Internal roadmap could be termed as a work-in-progress item trying to
finalize the contents of the roadmap collaborating with internal stakeholders and later
pushing it to the external roadmap after getting a buy-in internally. There are other
notable differences between an internal and external roadmap.
 The engineering team is the audience for internal roadmap while Customers,
Sales Team, Account Managers, and BDMs are the audience for an external
roadmap.
 The internal roadmap is engineering focused and it will be too technical. The
external roadmap is customer focused and therefore the use-cases or solutions
that provide tangible benefits to customers will be part of the external roadmap.
For instance, if there is a feature that changes certain algorithms to improve the
efficiency or make the product scalable, internal roadmap list the exact technical
changes done to the product while external roadmap will abstract customers
from technical nitty-gritty and reveal only the possible benefits. Therefore,
Product Manager while adding the exact technical requirements to the internal
roadmap will add only the tangible benefits to the external roadmap.
 In a case of external product roadmap, Product Manager has to ascertain, (i)
what to share (ii) how much to share and (iii) when to share. In the preceding
section, I have talked about (i) what to share and (ii) how much to share.
Regarding (iii) when to share, there are no hard and fast rules. In a case of new
product arrival, even though the news might excite customers sometimes
Product Manager might decide against sharing the details with customers for the
fear of cannibalizing the sales of existing products. So simple thumb rule that I

15. Page | 14
www.ProductGuy.in
Pragmatic Guide for Great PRODUCT ROADMAPPING
follow is to ascertain the risks vs benefits of sharing the news over a time interval
(probably 4 quarters) and identify at which specific interval does the benefits
exceeds the risks. If Product Manager plots a simple graph of risks vs benefits on
Y-axis and time interval on X-axis, the risks and benefits will be mostly linear with
each of them following an inverse pattern.
Figure 2 - Time to announce roadmap
 An external roadmap is a subset of an internal roadmap with an exclusive focus
on the value rendered to customers. Customers only care about the value
delivered to their business environment. List of features delivered in each release
is of little significance to them. Product requirements, new technology or new
platforms that are under evaluation might not find space in an external roadmap.
An external roadmap is also a selling tool. Any feature or solution that does not
directly contribute to the purpose of selling will not find space in an external
roadmap. For instance, changes to the product to make it more stable or efforts
to reduce the defects found is purely an internal item and therefore external
roadmap will not enlist those items. I attempted to provide an example of
internal vs external roadmap for the connected car. In a case of external
roadmap, I have listed the benefits of advanced diagnostics and indicated about
the feature to allay fears about data security. In an internal roadmap, the focus is
also on features contributing to the reliability of the product. Customers
implicitly expect for the availability of those features and it do not make sense
Q3 Q4Q2Q1
TimeT0
Time to announce roadmap

16. Page | 15
www.ProductGuy.in
Pragmatic Guide for Great PRODUCT ROADMAPPING
explicitly listing them in external roadmap. Nevertheless, an internal roadmap
should explicitly list those features, as nothing is left to the imagination of
engineering team. The engineering team will outline a solution (HOW) to the
requested features in functional specification document.
Connected Car Roadmap
Internal External
On Board Diagnostics
 Identify the list of vital parameters
that can help in early detection of
potential failures
 Communicate vital parameters to the
diagnostic servers for analysis
 Ensure reliability in case of failure of
diagnostic servers
 Diagnostic server to pick relevant data
for offline and online analysis
respectively
 Identify the list of roadside assistance
providers and add them to the
database
 Integration with maps to locate the
nearest roadside assistance provider
 List and identify multiple channels to
communicate with every roadside
assistance provider
On Board Diagnostics
 Pro-active predictive failure
detection and display of relevant
warning messages and possible steps
to overcome them.
 Automatically call the nearest
available roadside assistance
provider for immediate help in case
of no possibility for auto-recovery
Table 1 - Internal vs external roadmap
Customers only care about the value delivered
to their business environment. List of features
delivered in each release is of little significance
to them

17. Page | 16
www.ProductGuy.in
Pragmatic Guide for Great PRODUCT ROADMAPPING
Requirement vs Need
In the entire eBook, I had interchangeably used both the terms ‘requirement’ and
‘need’. It is appropriate to differentiate a need from a requirement, so my readers can
get a better perspective when I refer to either ‘requirement’ or ‘need’.
 Need – A need is any customer business challenge or pain point or desired
business outcome. Need is also referred to as job-to-be-done by customers. The
need could be untold (understood by Product Manager without being explicitly
mentioned by customers) or unmet (no product has addressed it) or underserved
(existing product is only addressing it partially) or overserved (existing product
deliver more than what customers need). A classic example of overserved
product is Microsoft Office – most users do not use 90% of the functionalities of
office. Need is primarily defined from the perspective of a customer. Typically,
MRD captures a need.
The existence of a challenge or a pain point would be single most compelling
reason for customers to buy a product that addresses their pain point in a most
optimal way while delivering the best possible experience. Identifying and
anticipating customer business challenges or pain points is critical for building the
new product. The business outcome can be termed as a solution derived to
address a business challenge or pain point. ISPs (Internet Service Providers) are
grappling with challenges of reduced or flat ARPU (Average Revenue Per User)
resulting in not so significant growth. Therefore, the desired business outcome
for ISPs is an opportunity to monetize their network and ISPs will rightly embrace
any product that can aid in such business outcome.
 Requirement – A requirement is a need when translated into a form
understandable by the engineering team. While need outlines the WHY,
requirement outlines the WHAT and functional spec written by engineering to
implement the need outlines the HOW. The PRD mostly contain requirements,
while it is worthy of mentioning need as a means to outline the purpose behind
the requirement. While need will outline that an ISP customer is looking forward
to an opportunity to monetize their network, the requirement will outline the
exact list of features or solutions when added to the product will facilitate
customers to monetize their network.

18. Page | 17
www.ProductGuy.in
Pragmatic Guide for Great PRODUCT ROADMAPPING
Context of requirements
Every need when translated into a requirement has three facets. Let me illustrate
through an earlier example of how to help ISPs increase revenues.
 What is the requirement? – Focusing on outcome
o Opportunity to monetize the network
 Why is the requirement important to customers? – Focusing on customer pain
points or challenges
o Revenues are flat causing negligible growth
 How to address the requirement? – Focusing on solution
While translating need into requirement and adding it in the PRD, Product Manager has
to focus on the first two aspects leaving the last one to the engineering team. However,
in addition to those three tenets, another additional tenet is relevant today called
context. Context highlights the exact environment in which customers operate.
Accordingly, engineering team can build a solution that exactly fits customers’
environment. Product Manager can also use the context to pro-actively figure out any
constraints. Constraints highlight the limitations thrown by the customers’ environment
that might hamper the solution to work properly.
For sake of illustration, let me take an example of connected car wherein the car
updates the onboard diagnostics such as oil levels, braking, tire pressure, engine
temperature, and system data etc. over the internet (What is the requirement?). The
purpose of advanced diagnostics is to anticipate the failure based on a set of critical
parameters going off the threshold mark and to warn the driver about the imminent
failure. Behind the scenes, the data could be used to possibly auto rectify the failure.
Otherwise, advanced diagnostics will alert support team to address the failure without
any delay providing them with sufficient information to diagnose and fix the failure. The
purpose is to alert the drivers of a rally before any potential life-risking failures and
eventually save their lives (Why is the requirement important to customers?).
I have precisely communicated what is the requirement and why it is required.
Nevertheless, are those details sufficient to fulfill the requirement, but what about
context? Without context, it is tough to understand whether it is possible to fulfill the
requirement in the environment in which it aroused. User personas and user stories are
probably one way of communicating the context but if personas or user stories are
used, they had to be exhaustive to cover all possible scenarios. In our example, the

19. Page | 18
www.ProductGuy.in
Pragmatic Guide for Great PRODUCT ROADMAPPING
context is a car participating in a rally travelling at an average speed of 100 miles per
hour in remote terrain. How does the context help? Context primarily helps in being
aware of the constraints thrown by the environment. The success of the solution hangs
on reliable connectivity continuously connecting the car with the base station while
travelling at an average speed of 100 miles per hour and relaying the diagnostic data in
real time. Product Manager has to anticipate whether there is sufficient infrastructure
to ensure the success of the solution. Otherwise, Product Manager should defer the
solution until the infra is ready or devise alternate measures to reliably transmit
diagnostic data to the base station.
Five Ws
Let me illustrate another example for precisely understanding the context. While the 1st
shopping cart was designed, the designer or the Product Manager would have asked
customers (the customer could be Walmart, Tesco or anyone equivalent) how the
shopping cart should look like. Instead, they should have focused on why the shopping
cart is required. The purpose would have dictated the design and designers would have
designed the shopping cart and there are at least two broader possibilities as shown
below:
Vs
Figure 3 - Shopping cart
How does context make the shopping cart design lot better? As I said context is all
about going beyond ‘WHY’ of the requirements and understanding the environment
that defines how customers will use the product and where they will use it. Product
Manager initially started asking customers what exactly they need and Product Manager
used to be self-contented that they are building products as requested by customers.
For obvious reasons, the conversation changed from ‘WHAT’ to ‘WHY’. ‘WHY’ is crucial,
but once Product Manager gets to know the 1st
level of WHY. Product Manager will start

20. Page | 19
www.ProductGuy.in
Pragmatic Guide for Great PRODUCT ROADMAPPING
making his/her own assumptions to the remaining levels of WHY. I would rather prefer
to understand the requirements as if the mind is a CLEAN SLATE. What happens if the
mind is a CLEAN SLATE coupled with essential nature of Product Manager to be curious?
Product Manager will start asking more questions, more Ws. That is precisely what we
all should do, ask more Ws. When Product Manager asks for more Ws, they get the
entire context. I formulated the essential five Ws that can possibly understand the
context of a requirement.
 WHY – What is the actual purpose behind the requirement? The requirement
could be to provide a tool, a product, or a solution. For sake of discussions, let us
call tool as a subset of the product, solution as hardware or software that
integrates multiples products or tools.
 WHAT – What would customers do with the tool, product or solution?
 WHEN – When would customers use the delivered tool, product or solution?
 WHO – Who will use the delivered tool, product or solution?
 WHERE – Where do customers will use the tool, product or solution?
Requirement: Connected Car – Diagnostics to detect early failures and provide
preventive measures
 WHY – To avoid deaths due to failures in the car
 WHAT – Identify what failures can cause death and when those failures can
occur? Through early detection of those failures, drivers and his/her support
team will be alerted
 WHEN – The proposed solution will be used during car RALLIES.
 WHO – RALLY drivers and a team that inspects those failures to provide pro-
active support to avert failures and saves lives of drivers will use the solution.
 WHERE – Connected car solution is used during RALLY. It can be a rally in any
terrain but preferably in a terrain where the possibilities of deaths due to
negligence is higher

21. Page | 20
www.ProductGuy.in
Pragmatic Guide for Great PRODUCT ROADMAPPING
Discovery of needs
A well-orchestrated discovery of all possible needs through broader understanding and
anticipation of customer business challenges, pain points, and business outcomes, later
converting those needs into product requirements is the ideal starting point for drafting
a GREAT product roadmap. Unless Product Manager discovers and understands the
entire gamut of unmet, untold, latent, overserved and underserved needs, later
translates them into product requirements, the process of prioritizing product
requirements will not be effective. Product Manager can only prioritize what (s)he has
discovered, so it is ideal that Product Manager discovers right set of exhaustive needs.
The foundation for evolving a product readily embraced by target customers and which
does not decline prematurely rests on effectively formulating the product roadmap with
a right set of requirements prioritized at right time intervals.
Discovering vs understanding requirements
Terms ‘discovering requirements’ and ‘understanding requirements’ were
interchangeably used in this entire section. Discovering requirements refers to the
process of identifying needs that customers did not recognize yet. There are always
needs that customer do not recognize but Product Manager has the responsibility to
spot those needs while building and evolving the product by observing customers in
their natural habitat and developing a thorough understanding of customer business
environment. I refer to identification process of those needs and translating those needs
into requirements as discovering requirements. On the other hand, understanding
requirements is the identification of needs recognized by customers. Product Manager
understands those needs by explicitly talking with customers and the thumb rule that I
follow for understanding requirements is ‘Never ask customers what they need, always
always always ask why they need’.
Discover of customer focused needs
Product Manager should be all ears while talking with customers to grasp their business
challenges and pain points. ‘Listen to your customers’ is an age old adage that is
followed by every business and I am not advocating doing anything differently. I am just
Never ask customers what they need, always
always always ask why they need

22. Page | 21
www.ProductGuy.in
Pragmatic Guide for Great PRODUCT ROADMAPPING
trying to emphasize that Product Manager should both listen and understand customer
needs, but (s)he does not let customers decide the contents of the product roadmap.
Product Manager should not let customers dictate what features to develop. Instead,
Product Manager will let customers focus on their business challenges (needs) and the
Product Manager (in collaboration with engineering team) should derive the optimal
solution that would address business challenges of customers. Otherwise, customers do
not think twice to dump the product that contains exactly what they asked for in favor
of the product that optimally addresses their business challenges (needs). Even in the
case of customers outlining the expected business outcome, Product Manager has to
thoroughly analyze the reasons for customer proposing such outcome and suggest other
viable alternatives on a need basis.
On the related context, I want to quote the words of Henry Ford even though it is a
cliché.
If I had asked people what they wanted, they
would have said faster horses.”
Ford while listening to his customers understood their innate needs of travelling quickly
from A  B. So understanding customer untold/unmet needs along with explicit needs
is critical to evolve the product roadmap. Yet does listening and understanding
customer needs alone would suffice? Before I go any further let me clarify my definition
of customer focus, “CUSTOMER FOCUS embodies everything that product attempts to
understand and address unmet/untold/underserved needs of existing customers of the
product”.
In short being customer focus is delivering what customers require instead of delivering
what they asked for. Sometimes an exclusive focus on customers might be a trap, it
leaves Product Manager to be very narrow and short term focused. While it is always
better to focus on exclusive segments to ensure that the product will address their
Customers do not think twice to dump the
product that contains exactly what they asked
for in favor of the product that optimally
addresses their business challenges

23. Page | 22
www.ProductGuy.in
Pragmatic Guide for Great PRODUCT ROADMAPPING
needs, but to attain long-term success Product Manager has to look beyond the needs
of a select group of customers.
Discovery of market focused needs
In several of my blog posts (@ www.ProductGuy.in), I have repeatedly stressed that
most of the customer business challenges are short term. However, both short-term and
long-term business challenges and pain points of customers should be the focal point
for evolving the product. The pitfalls of listening to customers and acting accordingly is
that someone might suddenly pop-up disrupting the entire market with new technology
or new offering and customers might not think twice to switch sides. While it is required
to keep focused on prospective customers of the existing product, it is also essential
listening to market to understand how it might evolve.
The market is no different from customers and indeed market is a generic
representation of a broader segment of customers. When I insist on market focus, I was
looking forward to constructing a generic representation of the entire customer
segment and start assessing how their needs will evolve with changes in dependent
macro factors. More often, there is an inevitable necessity to go beyond the boundaries
of the existing needs and existing customers to identify or grasp what is changing
outside and build a mental map of how those changes might alter the customer
behavior or create new needs.
Customer focus is about delivering what
customers require instead of delivering what
they asked for
The pitfalls of listening and understanding
customers is that someone might suddenly pop-
up disrupting the entire market with new
technology or new offering and customers
might not think twice to switch sides

24. Page | 23
www.ProductGuy.in
Pragmatic Guide for Great PRODUCT ROADMAPPING
At a tactical level, it always augurs well to look at every individual customer needs to
ensure a steady flow of revenue. However, at a strategic level while Product Manager
has to envision how the product should evolve, (s)he has to create a mental map of how
the generic needs of the broader segment of customers evolve and how they will
probably respond to new technology innovations or any products in adjacency space
that can address the needs of customers. To be more precise, in case of market focus, I
was rather thinking strategically to fathom the long-term evolution of the market needs
or long-term relevance of the product due to changes in market/technology or customer
behaviors through explicitly pondering over the following
 Attacking growth – If it is a growing market, there should be conscious effort to
identify who is contributing to the growth and lay plans to capture it?
 Capitalizing white space (aka demand generation) – Probably same product but
new use-case and new target segment, Product Manager have to look out for
such possibility. Otherwise, Product Manager has to spot customers trying to use
the product differently from its intended use and should validate the possibility
of either building a variation of the existing product or enhance the existing
product to generate additional demand for the product.
 Is there any product in the adjoining segment that has the potential to make the
current product irrelevant (what Mobiles did to Pager, what Smartphones did to
Camera and Navigation Devices) in near future? Is the existing product a
disruptor or any other product(s) can potentially disrupt the new product? UBER
leveraged technology to deliver better taxi services in comparison with
traditional players. Identify or anticipate potential disruptors that have potential
to displace the existing product from the market.
 Who are customers of tomorrow – There was a wider perception that Internet
Service Providers (ISPs) were primary target segment of networking devices not
There is inevitable necessity to go beyond the
boundaries of the existing needs and existing
customers to identify or grasp what is changing
outside and build a mental map of how those
changes might alter the customer behavior or
create new needs

25. Page | 24
www.ProductGuy.in
Pragmatic Guide for Great PRODUCT ROADMAPPING
until Amazon, Google, Facebook, and Microsoft started buying more networking
hardware than ISPs. Not many vendors looked at the later as potential
customers. In the case of consumer products, Product Manager can build and
evolve better products by ascertaining the buying patterns or behaviors of
Millennials, who might constitute a significant portion of the target market. Their
choices might not be the same as existing customers. While building and evolving
an existing product, there should be conscious effort to understand who
customers of tomorrow are.
 What are the customer needs of tomorrow – Can Product Manager anticipate
those needs. Plan to evolve the existing product not for customers of today but
for customers of tomorrow.
 Is there any new technology or trends that when not accommodated might cause
the product to be irrelevant? For instance, the effect of virtualization (Network
Functional Virtualization-NFV/Software Defined Networking-SDN) on physical
appliances in networking industry or Impact of IoT on industrial products
 Is there any new technology or trends that when not accommodated might cause
the new product to be irrelevant? For instance, effect of virtualization (Network
Function Virtualization-NFV or Software Defined Networking-SDN) on physical
appliance in networking industry or Impact of IoT on industrial products. Is the
existing product negating all relevant trends? If so, Product Manager is seriously
jeopardizing the longevity of the product.
Product Manager will not be able to consciously ponder over the above items unless
(s)he expands the horizon to go past the existing customers and existing products to
understand the characteristics of the entire segment and comprehend how it will either
react to external changes or impacted by external changes.
Anticipate emerging needs
In the case of market focus, Product Manager does not merely understand customer
needs, (s)he should also anticipate how customer needs will evolve or what new needs
will emerge with possible changes to dependent macro factors. Once Product Managers
understands the dependent macro factors (such as economy, regulation, internet,
technology etc.) that can directly or indirectly influence the products, there are 2 kinds
of possibilities.

26. Page | 25
www.ProductGuy.in
Pragmatic Guide for Great PRODUCT ROADMAPPING
1. Needs of tomorrow
 With increased adoption of multiple devices (smartphones, tablets etc) by
each user or family, will users start demanding new plans from ISPs?
 With increased adoption of mobile devices in rural a segment and with the
possibility of a decrease in internet connectivity costs, could the following
new needs could emerge:
(i) Mobile banking. Similar to the m-pesa model
(ii) Sharing latest farming techniques and knowledge.
(iii) Mobile commerce to sell directly to consumers – eliminate intermediary
agents.
 With the advent of IoT and wide spread adoption of IoT technologies to
create smarter homes, what will be the impact to ISPs that provide pipes to
carry data (specifically Machine-to-Machine - M2M)? How ISPs could
monetize the data?
2. Customers of tomorrow
 With the potential increase in disposable income of millennials, they can be
possible target customers for real estate, luxury cars etc. Product Manager
has to ascertain whether their needs will be the same as existing customers.
What I have stressed so far is that certain needs will emerge and new customers will be
added to the target segment in future with changes in the economy, technology,
regulation etc., and it is the responsibility of Product Manager to anticipate both
emerging needs and emerging customers. Later, track them in PRD.
How far to look into the future
Primarily, why should Product Manager anticipate, why not address the needs or target
new customers after they emerge. Whether to anticipate or just wait until the need
emerges primarily rests upon one factor – How long does it take to address a need? If
the duration is really longer, then Product Manager has the responsibility to anticipate
the needs to get the 1st
mover advantage and to excite the customers before the
competition does. In the case of automobile sector where the development cycles are
BIG, Product Manager cannot wait to understand the needs and aspirations of
millennials until they start buying cars. It would be tough to answer how far should
Product Manager look into the future, I would only insist on a starting point that would

27. Page | 26
www.ProductGuy.in
Pragmatic Guide for Great PRODUCT ROADMAPPING
constitute the sum of the time taken to research, develop and validate the product.
Since it would be tough to predict the future, Product Manager could better anticipate
possible outcomes of the future through scenario analysis and use lean techniques of
product development to build product increments to validate and ascertain which
outcome is most likely to occur.
Final thoughts
Guess I have dropped sufficient hints on what I am trying to conclude, the contents of
Product Roadmap should be a combination of both market and customer focused needs
translated into product requirements. If I had to rephrase my earlier definition of
roadmap –
“Product Roadmap is indeed a collection of customer
and market business challenges, pain points and
business outcomes translated into product
requirements and prioritized in accordance with the
product strategy/product objectives and addressed
through incremental product enhancements, or
incorporating new technology, or building new
platform or new product lines”
Ideally, product roadmap should focus on both short-term and long-term evolution of
the product.

28. Page | 27
www.ProductGuy.in
Pragmatic Guide for Great PRODUCT ROADMAPPING
Collaborative discovery of needs – Who can participate?
One of the constant fears that every Product Manager share is: Competition identifying
a customer need or an opportunity before (s)he or their peers do – Honestly, Product
Manager need not feel bad about it. Such situations do occur and it can only testify that
the discovery process is not rock solid and there are gaps. It gives one more reason for
Product Managers to believe that they should think beyond themselves to expand their
sources that can help them discover needs. Engineering, Sales, Account Managers, and
Business Development Managers etc. always outnumber product Managers in an
organization. One best piece of advice that I had received is that stacking more Product
Managers is not feasible and it is not the right solution too. Instead, Product Manager
has to scale with existing stakeholders to perform his/ her activities.
Impact: Collaborate effectively with all the stakeholders to discover needs
Product Manager is not alone in the process of discovering needs even though (s)he is
exclusively responsible for discovering needs, corroborating needs and sometimes
synthesizing inputs from various disparate sources to formulate a need. It might sound
cliché, the truth is Product Manager does not have an authority to demand that every
stakeholder has to discover needs and Product Manager cannot set goals for the
discovery of needs to each stakeholder. What I had mostly observed is that when
Product Manager walks that extra mile to facilitate Sales Manager close deals, help
Account Manager maintain better relations with their customers, and aid Engineering
Manager and his team accelerate development of better products, entire stakeholder
will also walk that extra mile in assisting Product Manager to build better products.
When ProductManager walksthat extra mile to
facilitate Sales Manager close deals, help
AccountManager maintain better relationswith
their customers, and aid Engineering Manager
and his team build products faster, entire
stakeholders will also walk that extra mile in
assisting Product Manager to build better
products

29. Page | 28
www.ProductGuy.in
Pragmatic Guide for Great PRODUCT ROADMAPPING
For better clarity on how each stakeholder can help Product Manager in the discovery of
needs, I have provided some illustrations to clarify on the kind of needs that each
stakeholder can discover.
Needs from support team
 Product and Non-product enhancements (Usability, Features, Documentation
etc.) -
YouTube changed the VIEWS variable to 64 bit to accommodate more than 2
billion views after Google noticed increasing viewership for ‘Gangnam Style‘
video2
. Product Manager conceptualizes and builds a product with certain scale
parameters assuming it would suffice. However, as time progresses and customer
business grows, product might soon start hitting the limitations on certain critical
scale parameters. Customers would raise a panic button immediately after hitting
the limitation but support team can pro-actively raise an alarm through
monitoring the critical parameters of the product. Support team will use support
cases or other methodologies available to monitor and track the critical
parameters of the product. When the critical scale parameters reach a threshold
level, support team should immediately alert Product Manager to increase the
value of the affected scale parameters.
The support team is also equipped to analyze support cases and understand the
trends to figure out the most common issues faced by customers, such analysis
can help Product Manager understand the list of needs not optimally addressed
by the product. Any improvements can lead to better customer experience
thereby triggering higher retention rate leading to more up-sell or cross-sell
opportunities. Increasing trend of support cases on a specific feature could also
throw lot more possibilities for Product Manager to ponder upon the following:
 The feature might be buggy – Wakeup call for engineering team to
immediately address those issues, while Product Manager can plan for interim
release to avoid further customer dissatisfaction
 The feature is not intuitive – The feature might be working properly but
customers are increasingly finding it difficult to operate. Either the feature is
2 source:https://plus.google.com/u/0/wm/4/+youtube/posts/BUXfdWqu86Q

30. Page | 29
www.ProductGuy.in
Pragmatic Guide for Great PRODUCT ROADMAPPING
not intuitive (usability constraints) or documentation is not clear. It is widely
accepted principle that product should be intuitive enough for users to
operate the product without the need for a documentation. However, from
the perspective of HW (Hardware) product, documentation often plays a key
role.
 The feature is incomplete – Product feature does not completely address
customer needs. Wake up call for Product Manager because (s)he has not
properly analyzed the customer needs. Product Manager needs to take quick
remedial action to bridge the gap between customer needs and product
capabilities ASAP while performing a candid introspection of why the product
could not address the customer needs properly.
 New use-cases/ solutions
There are classic examples of customers using the product quite distinct from its
intended use. Every product has few innovative customers who are always step
ahead of the product team in implementing new use cases independently
through innovative changes in configuration or building new solutions through
successfully aligning the product with other products. Those innovative
customers whom I would comfortably refer to as Innovators or Visionaries as
explained by Geoffrey Moore in his book “Crossing the Chasm” do dare to exploit
the entire functionalities of the product to address challenges faced by them.
Such customers constantly pose technical challenges and help Product Managers
build better products, which eventually puts the product ahead of the
competition. Personally, it is good to have such customers and they are worth
more than a million-dollar customer.
Support engineers should consciously look out for such unique use-cases or
solutions through the aid of support cases to assist Product Manager to identify
innovative customers and capture their innovations. Product Manager can later
use the data to enhance the product that can supplement those innovations or
draw plans for new product offering or new ways of positioning the product (aka
demand generation).
 New product requirements
Customers ask about non-existing features through support probably because of
lack of understanding of the entire functionality of the product. Product Manager

31. Page | 30
www.ProductGuy.in
Pragmatic Guide for Great PRODUCT ROADMAPPING
could use those inputs to understand new product requirements; this set of
requirements will predominantly be incremental extensions of existing product
capabilities.
Sometimes support system is the single window for customers to vent their ire
on the lack of any features that should have been available in the product by
default. In B2C (Business to Consumer), customers do not think twice to raise
their concerns through social media. The support system should have the facility
to track the digital footprint for such messages.
Needs from engineering team
Engineering teams are masters of technology while product managers are presumably
masters of problem space. Closer ties between the two entities triggering frequent
discussion (not necessarily structured, probably unstructured discussions over coffee,
lunch or in corridors) can create wonders. When Product Manager keeps engineering
teams informed of the problem spaces, they can evaluate how advances in technology
(probably new components in case of HW products, new algorithms) can address
customer pain points in a much better way. For instance, in the case of VoIP products,
engineering team can suggest alternate mechanisms that can increase voice and video
quality, reduce latency and BW required etc. For same reasons, it is always better to
provide outside view of the world to the engineering team. The engineering team has to
be equipped with details about competition, customers’ wins & loses, and what
differentiates our product from the rest.
To further illustrate the importance of working with the engineering team, while I was
working on new virtualized product I was interfacing a lot with engineering team to
understand more about virtualization and how the performance could be improved. I
did earlier talk about increasing the adoption rate of new technology. I saw the
performance as one of the primary roadblocks for customers from adopting virtualized
product. Engineering team did throw many ideas on how to improve performance and
in fact, they did introduce me to Docker technology. Docker technology was gaining
ground and engineering team educated me on how it works and potential advantages
offered by Docker over hypervisor. I could leverage the technical details provided by the
engineering team to understand how Docker can help provide better value to customers
over hypervisor. End of the day, underlying technology does not make much difference

32. Page | 31
www.ProductGuy.in
Pragmatic Guide for Great PRODUCT ROADMAPPING
to customers as much as the value rendered by each of those technologies does.
Nevertheless, technology awareness is critical for Product Manager to make informed
decisions. Tagging with engineering team can help Product Manager to stay abreast of
the latest technology and further understand the impact it could have on product
evolution.
Many would advise Product Manager to hang out with customers, sales team, and
account managers. I would rather insist on hanging out with engineering team at an
equal proportion to build better products. When Product Manager is close to the
engineering team, it is better to leverage the opportunity facilitating the frequent
exchange of thoughts, ideas, problems etc. I could only say that MAGIC would be
created out of such interactions and if there is a distributed Product Management team,
I would prefer to hand over the responsibility of building and evolving the product to
the Product Manager closer to the engineering team. Closer interaction might often
enable engineering team to understand the needs precisely, so they can deliver
solutions that can amaze customers and create a WOW feeling.
Needs from sales team
No one interfaces closely with customers as much as Sales Manager does. Sales
Manager can provide specific details on how each customer is using the product and
they can help discover needs of an individual customer. Sometimes Sales Manager can
also help understand the gaps with competitors that is haunting the product in closing
deals. In addition, Product Manager can also seek Sales Manager input on the below
items to get better knowledge about the product
 Why is customer happy with our product? Seriously helps to know why we are
winning.
 Why is customer whining? With what aspects of the product (support, usability,
reliability or lack of features) is the customer not happy about?

Many would advise Product Manager to hang
out with customers, sales team, and account
managers. I would rather insist to hang out with
engineering team at equal proportion to build
better products

33. Page | 32
www.ProductGuy.in
Pragmatic Guide for Great PRODUCT ROADMAPPING
 What deals did the product lose? Is the product losing because of lack of any
capabilities? Is there any trend?
 Is the product losing to any other product in the adjacency space?
Another big source to discover needs is RFP, which Product Manager neglects often. In
the case of a B2B segment, RFPs mostly precede sales and the RFP would contain more
details about customer needs. RFP would also validate the ability of the product to
handle future needs of customers. Analyzing multiple RFPs provides the direction in
which customer businesses are evolving, look out for patterns of new needs and record
them.
Another possibility to identify customer needs is to spot star Sales Managers. Star Sales
Managers sell more not because the product is in demand or the product is great or that
(s)he is lucky. They sell more because of their deeper understanding of both the
customer and the product combined with the ability to position the product effectively
at the crossroads of problem and solution space. Working with such Sales Managers is
extremely beneficial for gaining more insights into customer needs. Further, such Sales
Managers are always on lookout for opportunities to generate the demand for the
product. They equally look up to the Product Manager to share or contemplate new
use-cases providing additional compelling reasons for customers to invest in the
product.
Needs from BDMs
BDMs can mostly help discover strategic needs that can push the growth of the product.
While talking about discovering needs, I stressed the importance of pondering on the
following topics:
Star Sales Managers sell more not because the
product is in demand or the product is great or
that (s)he is lucky. They sell more because of
their deeper understanding of both the
customer and the product combined with ability
to position the product effectively at the cross
roads of problem and solution space

34. Page | 33
www.ProductGuy.in
Pragmatic Guide for Great PRODUCT ROADMAPPING
 Attacking growth – If it is a growing market, there should be conscious effort to
identify who is contributing to the growth and lay plans to capture it?
 Capitalizing white space (aka demand generation) – Probably same product but
new use-case and new target segment, Product Manager have to look out for
such possibility. Otherwise, Product Manager has to spot customers trying to use
the product differently from its intended use and check if there is an opportunity
to build a variation of the existing product or extend the existing product to meet
additional demand for new use-cases.
 Is there any product in the adjoining segment that has the potential to make the
current product irrelevant (what Mobiles did to Pager, what Smartphones did to
Camera and Navigation Devices)
BDMs do definitely play a greater role in helping Product Manager ponder over the
above topics. BDMs by the virtue of their responsibility to identify new markets for the
product and to put the product on growth trajectory should gain better knowledge
about the market, trends etc. While interactions with Sales Manager(s) boil down to
specific customer needs, interactions with BDMs revolve around discovering market
needs.
Role of BDMs do not just restrict them to help discover strategic needs, they can also
play a greater role while the market is on the cusp of technology change. During
discussions around inflection point, I did mention that Product Manager should also
focus on accelerating the technology shift triggering the migration of customers from
old to new technology. BDMs can help identify factors which when accomplished can
trigger the acceleration of technology shift. The factors could be an improvement in
performance of new technology or identification of widespread applications of new
technology.
Basic tenets of collaborative discovery
In all the above cases, Product Manager do not blindly accept the needs and record
them rather he opens a dialogue with the respective stakeholders to understand more
about the need (WHAT part of the need) and develop a complete awareness of how
unmet, underserved or latent need is impacting customers (WHY part of the need).
Without the complete grasp of what and why of the need, it might be extremely difficult
for Product Manager to convert the need into requirements and appropriately prioritize

35. Page | 34
www.ProductGuy.in
Pragmatic Guide for Great PRODUCT ROADMAPPING
it. In certain cases, stakeholders can merely provide some hints on customer needs and
they might not be equipped to provide complete details. Incomplete information is still
fine and Product Manager might have to build upon those hints. Product Manager
should encourage stakeholders from sharing any kind of information about customer
needs, pain points etc. and not penalize or reprimand them for sharing incomplete
needs. The basic premise is that any information on customer need is worthy unless
thoroughly corroborated. Product Manager should also follow inclusive approach while
prioritizing requirements by thoroughly communicating the yardsticks used for
prioritization of requirements to the entire team of need discoverers for allaying any
fears of bias in the process of prioritizing requirements.
Needs from confluence of multiple minds
Needs are not always discovered by a single entity. Certain needs emerge at the
confluence of multiple minds. Especially in the case of emerging technologies such as
IoT, Virtualization, Big Data etc. where there is no clear definition of problem space
because technology is evolving and the applications of the technology are evolving, the
culmination of engineering, domain experts, Product Managers is essential to synthesize
divergent thoughts into a concrete need. Unlike in earlier scenarios, I am focusing on
structured methodology (like brainstorming) because each entity has many thoughts
and they are worthless individually. The focus of brainstorming session is not to pick the
best idea. Instead, Product Manager has to effectively moderate to facilitate a
freewheeling conversation among all the participants to put on the table all the
divergent thoughts including their assumptions, later participants would have built upon
other thoughts to provide a shape to a new product need. The scenario is akin to each
participant holding a partial solution to a riddle. Product Manager has to identify and
bring together all the entities holding the partial solution to solve the riddle. To ensure
success of this entire exercise, Product Manager has two challenges
1) Identifying right set of participants
2) Facilitating effective participation from all participants
Importance of ‘WHY’
‘WHY’ does not essentially mean that Product Manager fires a barge of questions either
during brainstorming or while collating needs from various stakeholders, ‘WHY’ should
not sound like an interrogation. The power of ‘WHY’ lay in enabling others to ponder, to

36. Page | 35
www.ProductGuy.in
Pragmatic Guide for Great PRODUCT ROADMAPPING
reason out their findings. Primarily ‘WHY’ should also let the other person break their
assumptions. Every person has a certain set of assumptions and it guides their thinking
process. Higher the assumption, more the limitations exists in expanding the thought
process of an individual. Because of the limitation or inability to question the status quo,
retailers thought people would never buy clothes online without touching. Executives at
Nokia and BlackBerry thought mobile users would always be comfortable with QWERTY
keypad. ‘WHY’ is critical when Product Manager has to think beyond the existing needs
of customers and anticipate how new technology could influence them. ‘WHY’ would
dig out all the assumptions related to customer behavior and ‘WHAT IF’ hypothetical
analysis could be used to understand what changes in technology or product would
trigger the change in customer behavior. The examples that I had highlighted is related
to disruptor technology as asking ‘WHY’ creates much larger impact. Nevertheless,
asking ‘WHY’ is essential for the critical understanding of tactical and strategic
requirements as well. The exact definition of tactical, strategic and disruptor
requirements is outlined in the following section.
Ability of Product Manager to facilitate collaboration
Honestly, there will never be a dearth of stakeholders discovering or contemplating
needs based on their role and experience. Product Manager has to create an
environment for facilitating the free flow of needs and information related to the
product (drawbacks, needs, limitations etc.) from every stakeholder to Product
Manager. Even if any of the needs sounds dumb, Product Manager should not dismiss it
away, (s)he should explain the reasons for discarding and elaborate the yardsticks used
to measure the value of a need.
To check whether Product Manager could create a collaborative atmosphere, Product
Manager(s) should try answering the following questions with YES/NO
1) Are you approachable?
2) Are you enthusiastic about listening to ideas that resolve customer problems?
3) Are you eager to know about the new business challenges of customers?
4) Are you interested in keeping yourself abreast with latest technology
advancement surrounding your product?
5) Are you eager to know about the kind of implications that new technology can
have on the product?

37. Page | 36
www.ProductGuy.in
Pragmatic Guide for Great PRODUCT ROADMAPPING
6) Do you have the list of blogs or analyst data on your reading list as an everyday
task?
7) Do you feel spending time with engineering is your primary responsibility?
8) Do you feel bad about dragging engineering team into all your calls with
customers?
If the answer to all the above questions is emphatic YES, then Product Manager is
desperate to fill his/her head with information. Such Product Manager would never
forego any opportunity to learn and (s)he would naturally facilitate an atmosphere to
collaborate.

38. Page | 37
www.ProductGuy.in
Pragmatic Guide for Great PRODUCT ROADMAPPING
Categorization of requirements – Tactical, strategic and disruptors
Explicit focus on customer and market is to discover all possible needs without leaving
any needs behind. Unless Product Manager discovers all needs, (s)he will not be able to
make right prioritization decisions and it will hamper the evolution of the product. After
the discovery of all needs, trying to categorize and prioritize them based on market or
customer hardly makes any sense. Discovery of customer-focused needs provides a
foundation to build a generic representation of the broader segment of customers and
to embark on the journey of discovering market focus needs. Therefore, somewhere
deep down needs that are discovered through customer focus will ultimately overlap
with the needs that are discovered through market focus unless the business models
rest on customization. Therefore, categorizing requirements into customer focus and
market focus could hardly be effective. Then, what would be the right set of parameters
to categorize requirements?
I have already provided hints of possible categories while talking about ‘Discovering of
market focused needs’. Yes, you guessed it right. I am trying to categorize requirements
into tactical and strategic. In addition, I have added a new category called disruptor.
Tactical
Tactical requirements are short term (mostly 1 year). Requirements listed under this
category do not face any uncertainty. Tactical requirements are lucid and therefore
there is hardly any risk in implementing them. Further, customers will readily embrace
the requirements when incorporated into the product ensuring a steady flow of
revenues. The requirements under this category address short-term business challenges
of customers providing an attractive proposition for customers to invest in the product.
The requirements under this category are mostly evolutionary in nature. Tactical
requirements are essential to ensure a steady flow of revenues to meet revenue targets
of the product.
Strategic
Strategic requirements are the near long-term (typically around 2-3 years). There is
some amount of uncertainty on how customers would react to the proposed changes to
the product and therefore the risk of implementing them is moderately higher.
Therefore, the priority is to eliminate uncertainty through building a minimalistic

39. Page | 38
www.ProductGuy.in
Pragmatic Guide for Great PRODUCT ROADMAPPING
prototype, validating it, and soliciting feedback in an iterative manner until complete
elimination of any uncertainty associated with the strategic requirement. The
requirements under this category bring in entirely new value to customers but more
often customers do not explicitly request them and customers can still live without
them unless the requirement becomes parity. Online fashion store adding the capability
of augmented reality to facilitate virtual dressing room is a fine example of strategic
requirement.
Figure 4 - Categorizing requirements
Tactical
What are the customer
businesschallengesor
paintpoints?Whatare
the desiredbusiness
outcomesandwhy?
Is ita growingmarket?
Who iscontributingto
the growth?Which geo
or whichsegmentof
customers
How to generate
demand?How to add
more customersto the
targetsegment?
Strategic
Can the productbe
usedforany alternate
purpose?Canthe
productbe tweakedto
addressthe needsof
new targetsegment?
Who are the customers
of tomorrow?
What are the needsof
tomorrow?
Disruptor
Is there anyproductin
the adjoiningspace
whichwhenimproved
furthercouldbe a
potential threat?Are
youlosingcustomersto
any productinthe
adjoiningspace?
Is there anynew
technologyortrends
that whennot
accommodatedmight
cause the productto be
irrelevant.
Customer Focus
Market Focus

40. Page | 39
www.ProductGuy.in
Pragmatic Guide for Great PRODUCT ROADMAPPING
Disruptor
Disruptor is a game changer. They uproot the entire market, create a new market and
install new normal. Disruptors make old way of doing things irrelevant through creating
a new product line, new consumption models, and new ecosystem that did not exist
before. Disruptors do not evolve the product but they will extend the product line
introducing new products embracing disruptive technology or innovations. Strategic
requirements when chosen properly can extend the product life cycle without
prematurely declining the product. However, they could not stop the product declining
from disruptive innovations or technology. Focus on disruption is to embark on the
journey of finding new technologies that have the potential to disrupt the entire market
and create a new normal. Disruptors create viable options and alternatives for growth in
long term. In the case of strategic requirements as well, we focus on imbibing
innovation and new technology into the product to create a better value but those
innovations or new technology are sustaining in nature and does not create new
markets. While disruptor technology or innovation creates new market uprooting the
older ones, an ideal way to tackle the disruptor technology is to embrace it and not to
fight it. Organizations therefore have to start investing in new technologies that have
the potential to disrupt the market and introduce new normal.
Product offering vs market matrix
In order to better explain tactical, strategic and disruptor, I derived product offering vs
market matrix. I believe the diagram below is self-explanatory.
 Incremental enhancements to existing product to better position the product in
existing market belongs to tactical category.
 Evolutionary changes to existing product offering to position in new market or
creating new product offering for positioning in existing market belong to
strategic category.
 Revolutionary changes to create new markets through new product offerings
belong to disruptor category.
While I have exclusively talked about what is tactical, strategic and disruptor
requirements. In the following chapter, the focus is on why it is essential to split the
requirements into three categories and how to obtain such a split in alignment with
overall product vision and strategy.

41. Page | 40
www.ProductGuy.in
Pragmatic Guide for Great PRODUCT ROADMAPPING
Strategic Disruptor
Tactical Strategic
Figure 5 - Product offering vs Market
ExistingProduct
Offering
Existing
Market
New Market
NewProduct
Offering

42. Page | 41
www.ProductGuy.in
Pragmatic Guide for Great PRODUCT ROADMAPPING
Ratio of tactical/ strategic / disruptor requirements in roadmap
The motivation to categorize the roadmap into (i) tactical, (ii) strategic and (iii) disruptor
is derived from the 3-horizon framework described by McKinsey for products.
Figure 6: McKinsey 3 Horizon Framework
Source: http://www.mckinsey.com/insights/strategy/enduring_ideas_the_three_horizons_of_growth
Horizon 1 - Tactical
Focus on addressing existing business challenges to
ensure flow steady of revenues in short term.

43. Page | 42
www.ProductGuy.in
Pragmatic Guide for Great PRODUCT ROADMAPPING
Horizon 2 - Strategic
Focus on expanding the product through innovative
solutions or addition of new technology for targeting
additional growth or revenue in near long term.
Innovative solutions or new technology delivering
potential value to customers would act as key
differentiators to retain customers and to facilitate
revenues in near long term
Horizon 3 – Disruptor
Focus on creating viable options for future growth in
long term through appropriately investing on
technologies that have the potential to disrupt the
market
There will always be clamor to introduce tactical requirements that fetch product
revenues in shorter run. Unless Product Manager determines the split and allocates
some portion of roadmap for non-tactical requirements, strategic requirements will
never surface when confronted with tactical requirements owing to their inability to
bring immediate revenues. The bitter truth that most Product Managers often miss is
that exclusive focus on tactical requirements will shrink the lifetime of the product,
thereby causing the product to decline prematurely. Investment on strategic
requirements is imperative to secure near future revenues and growth. By explicitly
defining a ratio, I am only trying to strike the balance between tactical and strategic
avoiding potential conflicts while prioritizing requirements.
In order to figure out the ratio, Product Manager needs to understand what the product
growth strategy is. Undeniably, the primary purpose of every product is to increase the
bottom line and product growth strategy would exactly let everyone know what
contributes (prospective customers, new market segment, new geo territories, new
technology, or new solution?) to additional growth. Please refer to the related blog post
Exclusive focus on tactical requirements will
shrink the lifetime of the product, thereby
causing the product to decline prematurely

44. Page | 43
www.ProductGuy.in
Pragmatic Guide for Great PRODUCT ROADMAPPING
on ‘Attacking White Space – Identifying Growth Opportunities’ @ ProductGuy.in.
Accordingly, Product Manager could figure out that ratio. For instance, if existing
customers contribute to more revenues in a saturated market than product
requirements of existing customers should occupy higher ratio. In case of targeting new
market segments, product requirements specific to those segments would occupy
higher ratio. If anyone is hoping that I would suggest some scientific methodology to
determine the ratio between each of the categories (tactical, strategic, disruptor), I hate
to disappoint but to be honest there is no scientific way to derive the ratio. Drafting a
scientific methodology is not ideal because road mapping is a combination of art and
science. Instead, I will provide some guidelines that should equally translate into
actionable items while determining the split. The success in determining the split clearly
lay in formulating the product growth strategy. I have provided illustrations of most
familiar product growth strategies as a reference for facilitating discussions on more
such product growth strategies.
 Leapfrog strategy – If the product is not a market leader and the intention is to
leap frog the competition, do not act as fast follower and never attempt to
accomplish everything that market leader has done. If the gap between your
product and the incumbent product is too wide, trying to ape incumbent and
following them will never let the product surge ahead. Instead, listen to the
market, think ahead of time and try to imbibe new technology or new offerings
to jump ahead of the market leader. Nintendo WII is a classic example of leapfrog
strategy. While Nintendo’s competitors were busy driving the market towards
expensive consoles and sophisticated graphics successfully, Nintendo did not
follow them instead build WII leveraging new technology of gesture control and
targeted a new segment of casual gamers with less expensive consoles driving
huge margins.
 Fast follower strategy – Companies adapt fast follower strategy when they are
averse to spending money on R&D and experimental products to validate the
market for uncertainty. The fast follower should be nimbler to quickly jump into
the fray after the 1st
mover has cleared the air on the uncertainty about new
technology or innovation.

45. Page | 44
www.ProductGuy.in
Pragmatic Guide for Great PRODUCT ROADMAPPING
In either case, there is a precedent of what works and
what do not work. Therefore, Product Manager while
focusing on closing the parity has to leverage the
experiences of incumbent to focus on requirements
valued most by customers
 Market leader strategy - If the product is a market leader, then it has to be at the
forefront of innovation disrupting the market continuously. Something similar to
what Microsoft and Intel did for Desktop. While Microsoft evolved Windows OS,
Intel evolved the processors to meet the higher processing requirements of
Windows OS. I do not think any customer have directed both Microsoft and Intel
to evolve their products. What Intel and Windows did was to create a demand. I
do not think they ever targeted to satisfy a demand.
 Customer focus strategy - In case of mature or saturated market, existing
customers constitute a majority contributor to revenues. In such scenario
deriving a product roadmap constituting predominantly customer-focused
features will yield better results however with some room for market features.
Otherwise, there is always a possibility for someone to disrupt the saturated
market and grab your customers. For instance, what OLA, UBER did for traditional
taxi business.
As long as there is steady flow of revenues, Product Manager will have a free hand in
implementing his plans of incorporating strategic requirements into the product.
However, decline in revenues of subsequent quarters will hit the overall resource
allocation to the product eventually scuttling the plans of Product Manager to introduce
any strategic requirements. Hardly Product Manager will have a free run, so it is vital to
show gains in short run while simultaneously planning for long-term gains. De-facto, I
generally adapt 80:20 rule to derive the split between tactical and strategic. Depending
on the strategy, I utmost take +/-10 from strategic. In both leapfrog and market leader
scenario, the emphasis will be on strategic requirements but definitely not on par with
tactical requirements. I generally prefer allocating 30% of the overall roadmap for
strategic requirements. The value 30% is just a hunch, the ultimate objective of the split
is to retain inflow of revenues while focusing on strategic requirement. As long as

46. Page | 45
www.ProductGuy.in
Pragmatic Guide for Great PRODUCT ROADMAPPING
Product Manager follows rigid prioritization process, creating space for strategic
requirements in the roadmap will never be an ordeal.
Depending on the overall strategy of the organization, Product Manager has to
determine % split for each of the 3 horizons in product roadmap. Wait! Why did not I
talk about disruptor? Organizations has to focus on both strategic and tactical
requirements, there is hardly no choice. Nevertheless, explicit focus to identify potential
disruptors is purely by choice even though all the firms have to innovate continuously to
stay afloat in the market. The reasons I said choice is that there is lots of uncertainty in
disruptor technology even after they hit the market and until they mature.
Organizations should cautiously validate disruptor technology. Further any new
technology with exception of some take longer time to mature. Therefore, it is the
prerogative of the organization depending on their overall strategy whether to
exclusively invest or not invest their resources to anticipate or create new normal
through identifying or creating disruptor innovations or technologies. Some
organizations might not take the tedious journey of unraveling the mystery around new
technology by resolving the uncertainty and identifying the potential market for those
technologies, instead they chose to wait for someone to clear all uncertainties
surrounding new technology and later start investing on them (fast follower) or acquire
companies with the expertise on the new technology.

47. Page | 46
www.ProductGuy.in
Pragmatic Guide for Great PRODUCT ROADMAPPING
Figure 7: Technology hype cycle (Source: Gartner)
Investing on disruptive technologies is not a norm as much as there is necessity to focus
on both strategic and tactical. Technology adaption takes time and a quick look at the
hype curve will reveal that most of the technologies take a minimum of 5 years to reach
‘Peak of Inflated Expectations’. At the height of inflated expectations, we could notice
that the early adapters express interest to invest in technology. Yet, the technology is
raw and validation of technology takes place during this period. The technology would
be further refined based on the feedback received during validations by early adapters
to reach mainstream. Obviously organizations do have time to keep a watch and assess
the maturity of the technology (refer Gartner Maturity Curve and Adoption Curve
below). While technology reaches the height of inflated expectations, organizations
either have to be nimbler to enter the fray much faster or start acquiring companies
investing in that technology. Uncertainties surrounding the technology would then be
mostly resolved. The challenge is in the adaption of the technology to address
appropriate business challenges that are critical to customers’ environment. To put in
other words, the focus would be mostly on demand generation.

48. Page | 47
www.ProductGuy.in
Pragmatic Guide for Great PRODUCT ROADMAPPING
When I said investing on disruptor is not a norm does not essentially mean that I am
advocating companies against investing on disruptor technology and such move would
spell doomsday. What I had indicated is that depending on the overall strategy of the
organization, they can adapt wait and watch approach. From the point of innovation
trigger to reaching peak of inflated expectations, there was always sufficient time to
take a note of how technology is evolving and to jump into the bandwagon. If you look
at some of the earlier technologies, how long did it took Bluetooth to enter into the
mainstream? How long did it took Digital Camera to enter mainstream market? While
we are now talking about driverless cars and virtual reality etc., what is the right time to
start investing on driverless cars before it is commercially viable. In fact, I am desperate
to understand or figure out some frameworks or models to understand the right timing
to invest on any technology. Much of the new technology although fascinating and
tough to evade the hype surrounding it, how does one determine the actual potential
and right time to start investing on it. I only have too many questions than answers. The
idea is to enter the market just on time without being too early or too late.
Much of the new technology although
fascinating and tough to evade the hype
surrounding it, how does one determine the
actual potential and right time to start investing
on it?

49. Page | 48
www.ProductGuy.in
Pragmatic Guide for Great PRODUCT ROADMAPPING
Figure 8: Adoption curve and maturity curve (Source: Gartner)
Once the organization decides to make a move and start investing on disruptor
technology, focus of discussion is to figure out the right balance between old and new
technology. Unlike tactical and strategic, we cannot allocate a static % of the roadmap
to disruptor. As the new technology evolves and matures, the old technology eventually
declines. Inflection point is the point at which old technology dissolves and new
technology emerges. Inflection point causes a shift in revenues, technology, customer
preferences etc. Therefore, product roadmap has to be flexible to adapt to the shift in
technology or rather pro-actively accelerate the shift. I will be elaborating on this topic
in the next section.

50. Page | 49
www.ProductGuy.in
Pragmatic Guide for Great PRODUCT ROADMAPPING
Inflection point – Seizing the opportunity
Every product has an Inflection point as defined by Andy Grove in his book “Only
Paranoids Can Survive”. One simple case of the inflection point is technological change.
The inflection point is both an opportunity (to displace incumbents) and a risk (to be
displaced by new entrants or existing competitors), so it is critical to be wary of the
inflection point.
Figure 9: Inflection point
Perils of inflection point
Most of the companies basking in the glory of the success of its existing product(s) miss
the inflection points. Intel was so obsessed with microprocessor business; it missed to
dominate the chipset business in mobile space. Qualcomm and other players dominated
the mobile chipset market3
. Nintendo was the leading game player in 32-bit games
while Sega became the dominant player in 64-bit games and Nintendo lost the battle in
64-bit games. Likewise, Sony dominated 128-bit games and Sega lost the batter in 128-
3 Source: http://www.nasdaq.com/article/qualcomm-leads-mobile-baseband-chipset-market-analyst-blog-
cm367305

51. Page | 50
www.ProductGuy.in
Pragmatic Guide for Great PRODUCT ROADMAPPING
bit games. So clearly each of the aforementioned companies had a tight vigil on the
inflection points and entered the market with a new technology. However, the same set
of companies missed to observe the subsequent inflection points and lost their market
dominance to their competitors when there is a technological change. The only error
committed by those companies is to bask in the glory of existing products success and
focus exclusively on tactical requirements alone. Undeniably, most of the companies
commit such mistakes.
Having talked about inflection point now let me revert to the actual topic of how to
tackle inflection point in the roadmap. Please note that both technological and non-
technological changes can cause inflection points. Since I hail from the high-tech
industry and I am obsessed with technology, let me focus my discussion on inflection
point within the scope of technological change. Accordingly, there are two situations for
tackling inflection point.
1. Opportunity – To displace incumbents
2. Risk – To avoid being displaced by new entrants or existing competitors
In either case, it is critical to identify the new technology that when introduced will
change the dynamics of the market. However, the only difference is that in former
scenario, when there is lots of aggression to displace the incumbent, there would be
conscious effort to identify and validate new technology to understand how new
technology can change the dynamics of the market when embraced into the product
offering. In later scenario, incumbents will be busy serving their customers and they
might possibly discard the new technology trend as a fad. Clayton M. Christensen threw
lot of light on this topic in ‘The Innovator’s Dilemma’.
Assuming both incumbents and non-incumbents spot the new technology and realize
the importance of embracing new technology in product offering, our discussion is
primarily on how the product roadmap will address the introduction of new technology
to face strategic inflection point. Since the focus is on roadmap, I am not trying to sweat
much to provide methodologies to spot new technology that has potential to disrupt.
Opportunity – To displace incumbents
New technological introduction will either help displace incumbents (Sega displaced
Nintendo with 64-bit games) or create a new segment (Nintendo WII target casual

52. Page | 51
www.ProductGuy.in
Pragmatic Guide for Great PRODUCT ROADMAPPING
gamers). Either way, immediately after the identification and validation of new
technology, Product Manager can start prioritizing addition of new technology to the
product offering through adding it explicitly to product roadmap. In this scenario, there
is less of product roadmap dilemma and more of technology dilemma (how customers
would adopt new technology and what would be adoption rate). Startups or non-
incumbents will leverage this opportunity to gain a foothold and for them they have
more to gain than lose in chasing new technology or new market segments. On the
other hand, for incumbents, they have lot to lose if they do not plan the transition
properly. The irony is that for incumbents, not adapting new technology is not a zero
sum game. Incumbents have to time the introduction of new technology.
Risk – To avoid being displaced
In this scenario, there is more of product roadmap dilemma and less of new technology
dilemma. Adoption of any technology takes time and the adoption rate would only
increase gradually. Further investing in new technology would not provide immediate
gains, so trying to prioritize new technology introduction over other product features
that could fetch revenue in the immediate future is a big challenge. For those reasons,
it is fair to treat new technology introduction separately and not allow it to compete
with existing product features. Remember the % split of roadmap across the following
categories – tactical, strategic and disruptor. Even before we talk about technology
adoption, first problem is to eliminate the uncertainties related to new technology and
figure out how the introduction of new technology will deliver significant value to
customers.
Now coming back to the discussion of technology adoption, let us take the example of
IoT. The success of IoT lays in more proliferation of connected and smarter devices, so
manufacturers have to enable the smartness in the devices they manufacture. But do all
customers embrace IoT immediately? Definitely not, the technology adoption cycle
familiarized by Geoffrey A. Moore obviously suggests that customers adopt technology
at varying intervals. So companies should most probably employ a two-legged approach
(investing on both old and new technology at varying degrees) to ensure seamless
transition of their customers from old technology to new technology. There is hardly
any other alternative to two-legged approach in addition to deriving a well-crafted
strategy to increase the adoption rate. After eliminating uncertainties surrounding new
technology and determining the exact use-cases or applications of new technology, the

53. Page | 52
www.ProductGuy.in
Pragmatic Guide for Great PRODUCT ROADMAPPING
technology transition is not a technical problem as much as it is a business problem
(how to increase adoption rate) and roadmap problem (how to balance between old
and new technology). I am not undermining the efforts required to validate the new
technology, what I am stressing is that in the case of embracing new technology to avoid
the risk of being displaced, seamless transitioning from old to new technology and
accelerating the adoption rate are major challenges for a Product Manager.
Figure 10: Adoption rate of devices in US household
Business problem
The good news is that at least in B2C segment the adoption rate of new technology is
relatively quicker. May be, one primary reason for quicker adoption rate is affordability
along with increase in per-capita income of the consumers. In addition, technologies are
maturing more quickly because of the quantum of changes that are happening
simultaneously. While it took almost 80 years for landlines to reach 80% adoption rate
after it was first invented, it only took 30 years for mobiles to reach 80% adoption rate
after Motorola invented 1st
mobile in 1983. Clearly, customers are adopting the recent
innovations more quickly than before. Mobiles clearly defy the 30-year rule
conceptualized by Paul Saffo. Paul Saffo4
has admitted in his article that multiple
4 Source: http://www.saffo.com/wp-content/uploads/2012/01/Pauldesignworld1992.pdf

54. Page | 53
www.ProductGuy.in
Pragmatic Guide for Great PRODUCT ROADMAPPING
technologies are simultaneously accelerating faster and it will get tough to fathom the
impact of amalgamation of multiple technologies unless we start gaining a bigger
perspective of how smaller change can coalesce to form something bigger.
In a B2B segment as well, maturity and affordability of new technology will be one of
the primary drivers to increase the adoption rate of new technology. Identification and
articulation of precise value delivered by new product offering that imbibes new
technology also drives adoption rate.
Figure 11: Adoption rate of personal communication device
Roadmap problem:
[PS: Subsequent sections of this eBook refers the product that incorporates new
technology as new product offering]
Revenue potential of new product offering will always be too little, so allowing the new
product offering to compete with traditional product for resources will spell death knell
for new product offering. The primary focus for Product Manager is to resolve the
resource split between old and new technology through ruthless prioritization of
features of both new product and old product.

55. Page | 54
www.ProductGuy.in
Pragmatic Guide for Great PRODUCT ROADMAPPING
1. Take small and substantial steps – Focus on V in MVP
In the case of new product offering, it is advisable to take baby steps. Start with
building the most essential parts (basic functionality) of new product offering
that would facilitate to enter the market and validate the product. Product
Manager need not strive to build a perfect product instead build a prototype with
sufficient functionality that can render appropriate value to customers. The basic
idea is to validate the prototype, solicit the feedback from a select group of
customers, and iterate the prototype incrementally in a cyclic manner to build a
full-fledged product while successfully convincing those customers to transition
to new product offering.
2. Don’t adopt herd mentality
Everyone is testing waters with new technology and none might be sure about
what market needs, so just don’t blindly follow the competition. Herd mentality
is riskier. Ideal mechanism is to validate the product with selected set of
customers and understanding their needs to aid in further evolution of the
product using the principles: Insight, Observation, and Empathy as outlined by
Tim Brown in his book “Change by Design”. Every technology (for instance IoT,
BigData) is useless, unless Product Manager wove a solution offering surrounding
the technology and successfully build a product that resolves a need. Technology
sans solution is no good for anyone. We are often in awe of new technology and
we are enamored by it that we instantly fell in love with technology. Rather fall in
love with problems addressed by new technology instead of falling in love with
technology.
Everyone is testing waters with new technology
and none might be sure about what market
needs, so just don’t blindly follow the
competition. Herd mentality is riskier
Technology sanssolution is no good for anyone.
Never fall in love with technology, instead fall in
love with problems addressed by new
technology

56. Page | 55
www.ProductGuy.in
Pragmatic Guide for Great PRODUCT ROADMAPPING
3. Pick a customer(s) - THE Lighthouse Customer
The good news is that incumbents have a customer base and they do not have to
hunt for lighthouse customers. It should be possible to pick the early adopters
from the existing customer base for validation of the new product offering.
Leverage lighthouse customers to validate value hypothesis of the new
technology, ‘Value Hypothesis’ is a term coined by Eric Ries in his book ‘Lean
Startup’.
4. Measure the adoption rate
Any further changes to the new product offering will be dependent on the
feedback solicited from lighthouse customers. Meanwhile Product Manager has
to look out for certain signs to measure the adoption rate of the new technology.
Accordingly, Product Manager can plan to increase investment in evolving new
product offering
 Is technology becoming cheaper?
 Is the performance curve of technology increasing?
 Are there any standards evolving for new technology?
 Are more customers interested to trial new technology?
 Are there any viable business models to sell new product offering?
 Has the company started making real money on new product offering? Or is
there a clear potential to make real money?
Response to the above queries can help Product Manager ascertain whether the
new technology will be adopted and at what rate. In case of substantial signs
indicating the increase in adoption of new technology, it implies that early
adopters have gained confidence on the new product offering and it should be
possible to convince them to start investing on new product offering. Product
Manager should now look out for success stories of new product offering, create
press releases and communicate the actual value delivered by new product
offering to early majority and provide them sufficient reasons to trigger the
migration

57. Page | 56
www.ProductGuy.in
Pragmatic Guide for Great PRODUCT ROADMAPPING
5. Trigger transition from old to new technology or product offering
It is during this phase that Product Manager should aggressively evolve both
product offering (in terms of functionality, usability, performance etc.) and non-
product offering (documentation, support, marketing, press release, case studies)
of new technology while cutting down the investment on older product. It might
not be wise to continue investing on both existing products and newer product
while letting customers take their own sweet time to transition. Product Manager
should target to cut down overlap period between older and newer product.
Product Managers should develop a strategy to reduce the transition time by
offering incentives to migrate through trade-ins, migration offers, early discounts
etc. or by offering more value on new product offering in comparison with old
product.
6. Finally, Guidelines for managing product/technology transitions in
roadmap
The entire purpose of this exercise is to ensure preparedness for the future while
not leaving sight of the short-term opportunities and effectively manage the
transition of customers from old product to new product. Please note that the
old product is still the revenue generator (probably old product might be a cash
cow) and we could not risk the revenues of old product at the cost of embracing
new technology. Product Manager has to strike a perfect balance. Since we are
building the new product offering at the cost of existing product, Product
Manager has to follow some ruthless prioritization of features on existing
product as to deliver only the most critical product requirement and allow some
space to introduce new technology.
Prioritization tips for existing product during technology transition:
During early phases of introducing and validating new technology
 Deliver features that are critical and categorized as ‘MUST HAVE’
 Deliver only core features or extensions to core features
o Most product managers are familiar for bundling product with tons of
features. Such strategy is disastrous during technology transition.
Product Manager should prioritize only those features that extend core
functionality of the product.
 Deliver requirements that are applicable to wider range of customers

58. Page | 57
www.ProductGuy.in
Pragmatic Guide for Great PRODUCT ROADMAPPING
 Don’t focus on custom requirements – Even if they are requested by high
revenue generating customers
o Use appropriate negotiation skills to either drop custom requirements
or trade custom requirements for any other generic requirement
During customers’ transition period from old to new technology – As the
technology adoption increase
 This phase indicates sunset mode for the product, so the focus in less on
investment and more on squeezing all possible revenues.
 Even among ‘MUST HAVE’ requirements, focus only on those requirements
that delivers immediate value to customers
o For instance, Product Manager does not prioritize requirements such
as support for 100K simultaneous users where customer anticipates
the increase of simultaneous users to 100K after a year
 Focus on features that can aid in migration
 Focus on stabilizing the product
o Smaller segment of customers might always stick to old product for
little longer duration. So stabilizing the product to help reduce support
cost will be ideal
 There should be reversal trend of prioritizing more requirements related to
new technology and less requirements related to old technology
o Entice customers to migrate by delivering more value on new
technology
Final Thoughts
During the transition phase, Product Manager should not lose sight of the product
revenues. The ultimate goal for the Product Manager during transition phase is to
ensure that the revenues of new product offering will offset the decline in revenues of
older product.

59. Page | 58
www.ProductGuy.in
Pragmatic Guide for Great PRODUCT ROADMAPPING
Prioritization of product requirements
It is the time I start elaborating the critical topic that I intended to address through this
eBook. Until now, the focus was on understanding, discovering and anticipating needs
and who can help Product Manager identify those needs. After Product Manager
collates all possible needs and start drafting requirements, there will not be dearth of
product requirements but the next challenge is prioritizing those requirements. Product
roadmap preparation is a top-down approach and it should evolve from the product
vision. Product vision will define what requirements to prioritize and why to prioritize
those requirements.
Identification of product objectives (aka Goals)
Product vision is the foundation of any product. Product vision will always define the
WHY? It defines true purpose of the product, why it exists and it defines a direction for
the product. The overarching goal of why product exists and what is its purpose will
define who are its target customers, what should the product do, what is the
competitive advantage, and finally what are the product objectives (how does the
product help accomplish organizational goals). Rightly, so, product vision will provide
guidance for every decision making related to the product – How sales should sell the
product, how engineers should build and evolve the product, how marketing should
promote the product and how Product Manager should draft the product strategy.
Product strategy outlines the path to accomplishing product objectives abiding by
guidelines laid by product vision. Product roadmap provides a plan to execute product
strategy. At a high level, product vision embodies the following:
 What does the product stand for? Why it exists?
 What needs to address?
 Which customer segments to target?
 What is the USP (Unique Selling Proposition) of the product? How effectively
does the product will address the needs? How is the product different from
others?
 How does the product capture value?
A little deeper look will reveal that product vision has two broader categories
1. Product purpose
2. Product objectives

60. Page | 59
www.ProductGuy.in
Pragmatic Guide for Great PRODUCT ROADMAPPING
Product Vision
Product Purpose (Customer Centric) Product Objectives (Organization Centric)
 Why product exists?
 What needs to address?
 Which customer segments to
target?
 What is the USP of the product?
 How effectively does the product
will address needs?
 How the product captures value?
- Increase in profits
- Expansion into new markets
- Opportunity to cross sell
other products etc.
- Customer retention,
acquisition etc.
Part of the product purpose that defines ‘Why product exists?’, ‘What does the product
stands for?’ is the product tenet or principle. It is mostly static and it governs how
Organization build and evolve products. Product purpose (not including the product
tenet or principle) and Product objectives do change as the customer needs evolve, as
organization growth objectives change and as product traverses through various stages
of the product adoption life cycle (launch, growth, maturity and decline). Understand
from your CEO or VP Product Management, how the product should contribute to
overall organizational goals, accordingly Product Manager has to formulate product
objectives.
Product Manager would later perform thorough analysis of customer, market,
competition and technology to understand list of augmented needs that customers
value most and how effectively should product address those needs to accomplish
product objectives. In short, prioritization process of product requirements is all about
identifying right set of requirements that fits within the framework of product purpose
and yet has the potential for collectively accomplishing product objectives. Effectively
product roadmap should be a top down approach, product requirements has to be
prioritized in accordance with the goal (i.e. product objectives) while product purpose
acting as a guiding force.
Prioritization process of product requirements is
all about identifying right set of requirements
that fits within the framework of product
purpose and yethas the potentialfor collectively
accomplishing product objectives.

61. Page | 60
www.ProductGuy.in
Pragmatic Guide for Great PRODUCT ROADMAPPING
.
Identification of product attributes
When Product Manager starts prioritizing requirements, there should be an effective
mechanism to understand how each requirement contributes to both product purpose
and objectives. Therefore, we identify attributes (related to both purpose and
objectives) that can help measure how each requirement is contributing to the overall
product vision. Doing so, Product Manager is also prioritizing requirements based on
outcomes, based on how it affects the overall strategy and direction of the product.
Product objective aka goals are the end results of effective prioritization of product
requirements. Attributes of product objectives can also be metrics that can help us
measure the efficacy of product requirements prioritization process. Prioritization of
product requirements is a two-stage process. Requirements when prioritized in
accordance with the product attributes deliver value to customers that indirectly
contribute to accomplishing of product objectives. Ideally, the focus should be on
prioritizing requirements that deliver right value to customers. Accomplishing product
objectives should be a natural result of delivering the right value. In short, Product
Manager has to identify what value when delivered to customers will contribute to
accomplishing product objectives. Later, focus on prioritizing requirements that deliver
the desired value.
Figure 12 – Product prioritization cycle
Effectively product roadmap should be a top
down approach, product requirements has to be
prioritized in accordance with the goal
Product
Objectives
aka Goals
Product
Roadmap
Deliver
Value to
Customers
Prioritize Requirements Accomplish

62. Page | 61
www.ProductGuy.in
Pragmatic Guide for Great PRODUCT ROADMAPPING
Attributes of product objectives
The entire intention of effectively prioritizing product requirements is to deliver right
value to customers that can increase customers’ preference towards the product and
can indirectly contribute to achieving product objectives. So let us start with the end i.e.
product objectives. Product objectives could be one or more of the following:
 Revenue – Focus on growth, increase in profits
 Customer acquisition – Customer acquisition and revenue are not the same,
customer acquisition can happen at the cost of no additional revenue
 Competition – Parity with competitor products
 Cross sell – Opportunity to cross sell other products
 Stickiness – Customer retention and indirectly increase the cost of switchover
I would preferably pick not more than two attributes, as it will badly skew the
prioritization process of product requirements. If there is any conflict, identify which
objectives are more important.
Attributes of product purpose
Product addresses many needs. Nevertheless, there should be subset of needs that
focus on addressing the key pain points of customers. Product Manager has to correlate
between key needs and product objectives, Product Manager has to understand
addressing what needs or delivering what value can help product achieve its objectives.
If the objective is customer acquisition and stickiness, then identify what value when
added to product would drive customer preferences towards the product. Also, identify
delivering what value would increase switchover costs for customers and enhance
customer experiences thereby facilitating customers to stick with the product. Mostly,
enhancing customer experiences and increasing switchover costs can cause product
stickiness.
As stated already, prioritization process of product requirements should always be top-
down – Understand objectives and prioritize requirements that deliver right customer
value, which indirectly contributes to product objectives. However, at times it is better
to follow bottom-up approach to check if there are any potential conflicts between
product objectives and the actual customer preferences. An occasional qualitative
analysis to understand whether customers are buying the product for the same reasons
as Product Manager is thinking will be ideal bottom-up approach to validate whether

63. Page | 62
www.ProductGuy.in
Pragmatic Guide for Great PRODUCT ROADMAPPING
Product Manager has picked right attributes for prioritization process of product
requirements. Let us hold discussion on this topic to a later section. For effective
discussions on how attributes can aid in prioritizing product requirements, let me
assume a fictitious B2B IoT product targeted for retail stores that help in delivering
following value:
 Insight – Provides insights on how customers are accessing the store
 Generate revenue – Notifies customers through smartphone about the
availability of goods that might interest them based on their behavioral pattern
 Cut costs – Eliminates the need for sales person by flashing all information about
goods on his/her smartphone
 Up sell/Cross sell – Assist in picking of goods that go well with good chosen
already (replicate Amazon model). For instance, shirt that you chose goes well
along with a trouser – Help locate the trouser
 USP – Does the requirement contribute to enhancing the USP? In case of the
fictitious product, the USP could be as simple as ‘easy to use’, ‘easy to maintain’,
‘compatible with all mobile devices’, ‘mobile payment to avoid long queues’ etc.
Efficacy of product requirements prioritization process lay in effectively picking the
attributes valued most by target customers. Existences of those attributes should
provide compelling reasons for target customers to buy the product and stick with it for
a longer duration creating a long lasting relationship between the product and
customers. Attributes of product purpose measure the value delivered to customers and
weights assigned to each attribute should relatively highlight how customers value each
attribute.
Drop down all possible attributes that you could imagine. Identify the important
attributes that when delivered will help accomplish product objectives. I suppose it
would be ideal to stick with utmost three attributes in purpose and utmost two
attributes in objectives Otherwise, the weights are thinly scattered making it difficult for
Product Manager to prioritize product requirements effectively. More attributes not
only add difficulty but also dilute the efficiency of prioritization process of product
requirements. For sake of further illustration, let me use the attributes mentioned
below. Please note that the weights should be in percentages.

64. Page | 63
www.ProductGuy.in
Pragmatic Guide for Great PRODUCT ROADMAPPING
Attributes Weights
Purpose
1. Insight
2. Cost reduction
3. Ease of use
10
35
15
Objective
4. Customer acquisition
5. Stickiness (customer retention)
25
15
Table 2 - Product attributes and weights
While attributes of product purpose measure the value delivered to customers,
attributes of product objectives measure the value captured by organization. As I had
indicated earlier, customer acquisition and stickiness should be result of prioritizing
right set of requirements that deliver right value to customers. So prioritizing
requirements based on attributes of product purpose should be sufficient and adding
attributes of product objectives to the mix for product requirements prioritization
process is not required.
I would prefer to add attributes of product objective to the mix if prioritizing
requirements purely based on product purpose does not explicitly contribute to product
objective. i.e., when there is no direction correlation between delivering right value to
customers and accomplishing of product objectives. For instance – cloud model for IoT
product instead of on premise. Cloud model will deliver value to customers, it can help
in subscription pricing, acquiring new customers on trial basis, reduce CAPEX etc.
However, If the value delivered is scattered or if customers do not value it yet as cloud
model is little forward looking and we should move towards such model in adherence
with technology trends then prioritization based on customer value will not be effective.
In such scenarios, using attributes of product objectives will be ideal. Essentially, it is a
choice and product prioritization process is strictly not a science, it is an art with ample
scope for subjectivity.
Product attributes vs Product life cycle
Selection of product attributes do change for simple reason that product purpose and
product objectives do not remain static as product traverse through its adoption life

65. Page | 64
www.ProductGuy.in
Pragmatic Guide for Great PRODUCT ROADMAPPING
cycle. However, what I wanted to emphasize in this section is that the process of
prioritizing requirements across two consecutive releases is mutually dependent even
though we might use distinct product attributes for prioritization of product
requirements. Suppose if Product Manager decides a theme based release exclusively
focusing on (i) usability (ii) reliability in each release then Product Manager should at
least ensure completion of work holistically on the respective themes in each release.
There is no point in focusing on usability in a release and heading to reliability in next
release without completing entire planned stuff on usability. In some cases, Product
Manager will introduce certain requirement in a minimalistic way to evaluate customer
reaction and evolve it later. However, if the feedback from customer is good then
Product Manager should attempt to enhance the requirement in the subsequent
releases at the earliest. The value delivered to customers or product requirements
prioritized in each release should have cascading impact on requirements prioritized in
the subsequent release. Requirements prioritized in reach release should not look like
silos. In fact, each release should be a stepping-stone to achieve a bigger objective. If
Product Manager candidly introspects last few releases, the entire value derived from
those release should be greater than the sum of their individual parts.
Scorecard technique - Guidelines
Every product might have a distributed team of Product Managers, each managing
different components of a product or separate target markets or combination of both.
As part of completing the scorecard, every Product Manager should rate each
requirement in a scale of 0-10 against each of the chosen attributes. The scale of 10
indicates that the requirement is contributing immensely and scale of 0 indicates that
the requirement has no impact on the corresponding product attribute. Rating of each
product requirement against chosen attributes is purely subjective. However,
brainstorming exercise mentioned later in this eBook would ensure that the respective
Product Managers have done due diligence in evaluating each of their requirements
against product attributes. Thereby reducing the possibility for errors and eventually
ensuring efficiency and impeccability in relative prioritization of product requirements.
Requirementsprioritized in reach release should
not look like silos. In fact, each release should be
a stepping-stone to achieve a bigger objective

66. Page | 65
www.ProductGuy.in
Pragmatic Guide for Great PRODUCT ROADMAPPING
Going forward, I should shift the conversation from requirements to features.
Requirements outline what are the customer needs that the product should address.
Requirements will allow engineers to define how to address those needs, through
conceptualizing features. Requirement to feature mapping can be either one to many or
many to one. Nevertheless, for effective prioritization of product requirements, we
need to shift our conversation to features. It is essential to have conversations using
features as engineers understand features better and focusing on features is critical to
determining the cost of each feature. Determining cost is a topic that is crucial to
understand cost vs benefit analysis.
While trying to rate each feature against set of pre-defined attributes (both purpose and
objectives), identify how they are contributing relatively to any existing feature that
might probably be doing something similar. Product Manager can add a new feature
either to replace an existing feature or to expand an existing feature to enhance existing
functionality. In such cases, Product Manager should identify how much value does the
new feature delivers in relation to the existing functionality. If the existing functionality
is rated against ‘Ease of Use’ at 5 and the new feature that is either replacing or
enhancing the existing functionality is rated against its potentiality to deliver ‘Ease of
Use’ at 8, then we need to consider the relative difference while determining the actual
value that the new feature delivers to customers.
Attributes Insight Cost
Reduction
Ease of
Use
Customer
Acquisition
Stickiness Total
Value
Feature 1 7 0 3 9 7 44.5
Feature 2
Feature 3
…
…
…
…
Feature N
Table 3 - Product attribute value in a scale of 1 to 10
The value of 44.5 is a weighted value derived by mapping score of each product
attribute against its weight for each features as show in the table below.

67. Page | 66
www.ProductGuy.in
Pragmatic Guide for Great PRODUCT ROADMAPPING
Attributes Insight Cost
Reduction
Ease of Use Customer
Acquisition
Stickiness
Feature 1 (S1y) 7 0 3 9 7
Feature 1 (Wy) 10 35 15 25 15
Table 4 - Value and weights of feature 1
To derive the weighted value, I did use the following formula
𝑊𝑆𝑉𝑥̇ 𝑦 =
𝑆 𝑥𝑦 ∗ 𝑊𝑦
10
Equation 1 - Weighted value of feature x and attribute y
Attributes Insight Cost
Reduction
Ease of
Use
Customer
Acquisition
Stickiness Total
WSV1y 7 0 4.5 22.5 10.5 44.5
Table 5 - Weighted scale value of feature 1
( 𝑇𝑜𝑡𝑎𝑙 𝑉𝑎𝑙𝑢𝑒) 𝑇𝑥 = ∑ 𝑊𝑆𝑉𝑥𝑦
𝑛
𝑦=1
Equation 2 - Total value of feature x
Total value of each feature is sum of weighted value of all the attributes corresponding
to each feature.
 x is the index value of each feature and y is in the index value of each attribute.
 WSVxy is the weighted scale value for attribute y of feature x.
 Sxy is the scale value in the range of 0-10 for attribute y of feature x.
 Wy is weight associated with attribute y.
 Tx is the total value delivered by feature x in accordance with chosen product
attributes and
 n is the number of attributes

68. Page | 67
www.ProductGuy.in
Pragmatic Guide for Great PRODUCT ROADMAPPING
Brainstorming
There is no better option than brainstorming to discuss, debate, and argue on the ability
of each requirement to contribute to product purpose and product objectives.
Brainstorming session when done effectively provide revelations that was not
comprehended before by Product Manager or rather by any other participant. How
many times have we felt ‘Oh GOD, I never thought about it’! Brainstorming would help
to identify such facets never thought earlier when done effectively. Efficacy of
brainstorming sessions lays in adhering to following guidelines:
 Each participant should challenge and should have willingness to be challenged
by others.
 Each participant should build upon the thoughts of other participants to add
better clarity to ‘WHAT’ and ‘WHY’ of each requirement.
 Product Manager should ensure that there is a commonality of purpose, vision
and direction among all the participants.
 Each participant should engage in dialogue. In dialogue, participants aim for
collective good and not for win of any specific participant
 The session should be skillfully facilitated and moderated by Product Manager
Much of what I had described above was inspired from a book called ‘The Fifth
Discipline’ by Peter M Senge, the book offers lots of tips for effective and efficient
brainstorming session. The above stated pre-conditions are pre-requisites for success of
brainstorming session. Every participant should strictly adhere to those guidelines.
Product Manager should determine invitees for the brainstorming process. The invitees
should both contribute and benefit from the process. Engineers are supposed to benefit
as they now get clear directions on what features to add and why to add. Sales and
other equivalent members can contribute more as they represent customers, so they
can be voice of customers while Product Manager can moderate the entire discussions.
The brainstorming process will be chaotic, exhausting and mostly Product Manager will
feel tired about justifying each need. Yet such process adds pluralism ensuring healthy
discussions and debates among divergent minds leaving no room for human errors in
prioritizing requirements. The exercise is also an attempt to prove everyone that
prioritization process of product requirements is process driven backed with data and
does not happen in accordance with whims and fancies of a Product Manager.

69. Page | 68
www.ProductGuy.in
Pragmatic Guide for Great PRODUCT ROADMAPPING
It is also on opportunity to introduce BIG PICTURE to engineering team:
 What are the list of product requirements?
 Which segment of customers need those product requirements?
 Why do customers need each of those product requirements? What specific
business challenges or pain points does each product requirement address?
 What value does each product requirement deliver? How do they indirectly
contribute to achieving product objectives?
PM-Engineering joint operation
I often insist that engineering team should inculcate system thinking to have a holistic
view of how each component in the product inter-operate to deliver value to customers.
Engineering team should be aware of customer segments using the product and the
purpose for which the product is used by those customer segments. In addition,
engineering team should have a precise understanding of what and why behind each
requirement. Unless engineering imbibes those details, I could only foresee lots of
friction between what they should develop and what they actually develop. Including
them early in the prioritization process is one way to reduce the friction. However, I also
insist that during on boarding process of every engineer into the product team, (s)he has
to undergo detailed training on (i) what is the product, (ii) who uses the product, (iii)
why customers are using the product, in addition to the regular agenda of (iv) how the
product is built.
If engineering team is not involved in the
feature prioritization process, I could only
foresee lots of friction between what
engineering team should develop and what they
actually develop
The brainstorming process might be chaotic,
exhausting and mostly Product Manager might
feel tired about justifying each need. Yet such
process adds pluralism ensuring healthy
discussions and debatesamong divergent minds
leaving no room for human errors in prioritizing
requirements.

70. Page | 69
www.ProductGuy.in
Pragmatic Guide for Great PRODUCT ROADMAPPING
Involving engineering team early in the process helps them obtain the bigger picture to
avoid any ambiguity during development and to estimate efforts required to address
each requirement. Most importantly, Product Manager tries to instill a sense ownership
highlighting that their comments are valuable to evolve the product. Thereby making
engineering team realize that their priority is not just delivering the product right but
also delivering the right product. Constantly attribute success of the product to their
efforts and make them realize that they are entitled to demand more details from
Product Manager on why (s)he prioritizes certain features and for whom as much as
Product Manager has every right to ruthlessly demand more features from engineering
team.
End of the brainstorming session, scorecard is completed with assigning appropriate
weights for every requirement for all possible attributes. Further, every stakeholder will
be on same page with regard to prioritization process. Remember, I was talking about
inclusive approach to prioritization process of product requirements under discovering
needs section. Brainstorming process exemplifies inclusive approach and every
stakeholder would feel that their feedback is valued and they have better clarity on
prioritization process of product requirements. Guess there is no better technique than
brainstorming to achieve an inclusive approach.
Cost vs value
The purpose of attributes is to evaluate how each feature will contribute to the product
purpose and objectives i.e. Product Manager evaluates each feature based on benefits
accrued to customers. However, it is extremely unfair to evaluate features purely based
on impact that those features can have on customers’ business without evaluating the
cost associated with each feature. Every feature has a cost associated with it, cost to
develop, evolve and support. The product cost is independent of product attributes and
Engineering team should realize that they are
entitled to demand more details from Product
Manager on why (s)he prioritizes certain
features and for whom as much as Product
Manager has every right to ruthlessly demand
more features from engineering team

71. Page | 70
www.ProductGuy.in
Pragmatic Guide for Great PRODUCT ROADMAPPING
it is used to a do a comparison of cost vs benefits. The benefits delivered by a feature
might be high but at a high cost whereas another feature can deliver relatively lesser
benefits but with absolutely lower cost. Therefore, it is crucial to understand the
benefits in relation to cost.
Feature cost is estimated on a scale of 1-100. Firstly, development team should identify
person-weeks or person-months to develop each feature. The purpose of cost
estimation is to identify relative cost and not the absolute cost, so let us pick a feature
that consumes more man-weeks than any other feature. Let us assign a scale of 100 as
feature cost to that feature. Assuming that the feature consumes 15 man-weeks, let us
determine the relative cost of remaining features using a ratio of 15:100. Now suppose,
one of the remaining feature consumes 12 man-weeks, using the ratio of 15:100, the
feature cost would be 80 (12 * 100/15).
( 𝐹𝑒𝑎𝑡𝑢𝑟𝑒 𝐶𝑜𝑠𝑡) 𝐹𝐶𝑥 = 𝑀𝑊𝑥 ∗
100
𝑀𝑎𝑥 ( 𝑀𝑊𝑥)
Equation 3 - Feature cost of feature x
 FCx is the feature cost associated with feature x
 MWx – Man weeks to develop and support feature x
Fill the below table using the above formula.
Attributes Insight Cost
Reduction
Ease of
Use
Customer
Acquisition
Stickiness Total
Value
Feature
Cost
Feature 1 7 0 3 9 7 44.5
Feature 2
Feature 3
…
…
…
…
Feature N
Table 6 - Feature cost

72. Page | 71
www.ProductGuy.in
Pragmatic Guide for Great PRODUCT ROADMAPPING
I took a fictitious example of eight features with fictitious values for total value and total
cost.
Feature Total Value Feature Cost
Feature 1 90 70
Feature 2 70 40
Feature 3 40 90
Feature 4 35 25
Feature 5 90 15
Feature 6 60 80
Feature 7 60 25
Feature 8 20 40
Table 7 - Total value and feature cost
However, while doing actual prioritization, I would suggest using the formula that I had
earlier provided to derive the total value and feature cost for each feature.
Plot a graph as shown below with feature cost on X-axis and total value on Y-axis to
determine the stack order of features. The entire graph is divided into four quadrants
and they are categorized as:
1. More likely,
2. Less likely and
3. No.
Top left corner is categorized as more likely, features in that category deliver higher
value at less cost. Bottom left corner and top right corner is categorized as less likely,
features in that category deliver value in proposition to cost. Bottom right corner is
categorized as no and features under this categorized will never be prioritized as they
deliver less value at a higher cost. After plotting the graph, it is evident that features in
‘Most Likely’ quadrant will derive more value for each unit of feature cost and therefore
Product Manager should prioritize those features. However, from the graph it is not
evident which among those three features in ‘Most Likely’ quadrant will deliver more
value. Likewise, there are two quadrants for ‘Less Likely’ and the graph does not provide
the absolute value of feature to understand the relative ranking of features. Absolute

73. Page | 72
www.ProductGuy.in
Pragmatic Guide for Great PRODUCT ROADMAPPING
value of each feature can help us stack rank features and list them in the ascending
order of
Figure 13 - Feature value vs effort
Absolute value for each feature is derived using a ratio of total value vs feature cost i.e.
what is the absolute value delivered by each feature for each unit of feature cost. After
calculating the absolute cost, arrange the features in the descending order of absolute
value to get a stack rank of features.
𝐴𝑉𝑥 =
𝑇𝑥
𝐹𝐶𝑥
Equation 4 - Absolute value of feature x

74. Page | 73
www.ProductGuy.in
Pragmatic Guide for Great PRODUCT ROADMAPPING
AVx is the absolute value delivered by feature x
Tx is the total value delivered by feature x
FCx is the feature cost associated with feature x
Feature Total Value Feature Cost Absolute Value
Feature 1 90 70 1.30
Feature 2 70 40 1.75
Feature 3 40 90 0.44
Feature 4 35 25 1.40
Feature 5 90 15 6.00
Feature 6 60 80 0.75
Feature 7 60 25 2.40
Feature 8 20 40 0.50
Table 8 - Absolute value
Arrange the features in the descending order of absolute value to get stack ranking of
features.
Feature Stack Rank
Feature 5 1
Feature 7 2
Feature 2 3
Feature 4 4
Feature 1 5
Feature 6 6
Feature 8 7
Feature 3 8
Table 9 - Stack rank
Feature3 is a ‘STRICT NO’ as it is HIGH EFFORT and LOW CUSTOMER value.
If there is a window to deliver top four features, picking the top 4 might not always
work. Some customer might push for feature 1 and there will be a multi-million dollar
clinging on the deliver on feature 1. Therefore, there will be lots of pressure on Product

75. Page | 74
www.ProductGuy.in
Pragmatic Guide for Great PRODUCT ROADMAPPING
Manager to deliver it unless Product Manager is proficient to trade the feature with
other important features. I did briefly discuss about this topic in later sections of the
eBook. The other aspect is regarding the structure of engineering team. If the product
has multiple components and assume separate engineering team exists for each
component. So what-if all the top four features belong to a specific component and the
strength of the engineering team cannot handle more than two. While the features
belonging to other components deliver relatively less value. If such scenario repeats
than it is ideal to change the structure of engineering team to add more engineers to
the team that works on component delivering more value. For those reasons and for
lots of other good reasons, Product Manager should have a say and be pro-active in
structuring the engineering teams.
At the outset, it might not always be ideal to look at features objectively using scorecard
methodology and we should allow some room for subjectivity. May be for reasons
started earlier and for lots of other good reasons elaborated later, I do not entirely rely
on scorecard methodology.
Technical Debt
Any discussions on Product Roadmap would not be complete without mention of
‘Technical Debt’. Product accrues technical debt through implementing any functionality
in a quick and dirty way to get some quick results. At times, it might not be possible to
entirely get rid of technical debt owing to delivery pressures etc. but it has to be
minimized to an extent possible. Meanwhile Product Manager should consciously
analyze the implications of accruing technical debut. Accruing technical debt has serious
consequence and it has a cost associated with it. While determining the cost of
developing a feature, Product Manager has to include cost of technical debt if any to
perform cost vs benefits analysis to ensure whether it is worth accumulating technical
debt.
Why I do not entirely rely on scorecard methodology?
We got a scorecard and stack ranking through plotting of a graph estimating cost as well
(including cost of technical debt). The stack ranking can let Product Manager pick the
‘top X’ requirements. Wait, did I ever say I use scorecard methodology to prioritize
features. With all due respect, scorecard is an excellent methodology that helps Product

76. Page | 75
www.ProductGuy.in
Pragmatic Guide for Great PRODUCT ROADMAPPING
Manager to ponder and diligently assess how each product requirement can help
achieve product objectives. Yet, I do not blindly rely on scorecard or any equivalent
methodology. I merely use them as a reference to understand the relative importance
of each requirement under a specific category to make effective prioritization decisions.
Let me assume for a moment that the primary product objective is to generate more
revenues, so obviously revenue attribute would carry relatively higher weights along
with other attributes corresponding to product purpose that are valued most by
customers and can either directly or indirectly contribute to increase in revenues. If we
apply scorecard, undeniably, Product Manager prioritizes all features contributing to
increase in revenue and (s)he would have done a fabulous job.
Nevertheless, did I not discuss in length about being market focus – delivering
requirements that might excite customers, generating demand, attacking growth in long
term etc. I also discussed about imbibing new technology to stay ahead of the curve and
ensure competitiveness of the product. Focusing on them (WoW requirements, new
technology) will fetch revenue in long run in addition to allowing the product evade
strategic inflection point. Customers will be glad to have those value adders but they
would never ask for them explicitly. Scorecard methodology will not be able to strike a
balance between short-term and long-term requirements.
For those exact reasons, I have earlier attempted to categorize the requirements as i)
tactical, ii) strategic and iii) disruptor. In addition to avoid prioritization conflicts
between requirements in each of those categories, I strongly advocated the need to
allocate a portion of product roadmap for strategic and disruptor. Yet, I am still not
convinced with using scorecard technique for prioritization of requirements within each
category. Prioritization is more of an art than science, so employing pure scientific
methodology might be disastrous. Even though I use scorecard techniques to ensure
that I have done my due diligence in understanding how each requirement contributes
to both product purpose and objectives, I firmly believe that common sense prevails
over scorecard methodology.
I firmly believe that common sense prevails over
scorecard methodology

77. Page | 76
www.ProductGuy.in
Pragmatic Guide for Great PRODUCT ROADMAPPING
In addition, prioritization of strategic and disruptor features is done after evaluating the
degree of uncertainty and amount of efforts required to build minimalistic version of
those features for validating and eliminating uncertainty. Attributes and weights do not
work in this situation. Little gut feeling and thorough analysis of the amount of efforts
required to eliminate uncertainty through applying lean techniques plays a vital role in
selecting requirements under strategic and disruptor category.
Another factor that does not work in favor of scorecard methodology is product
prioritization decisions based on political reasons or undue pressure from customers or
integration with non-performing products to push their sales. We all agree that we do
not leave in a fair world, so prioritizations decisions purely based on scientific
methodology such as scorecard is not ideal. It works for a utopian society. I am not
suggesting against the use of scorecard. I am only suggesting using it until certain level
to determine how each product requirement is poised to contribute to both product
purpose and product objectives. Later use the data as a reference to understand the
relative value and cost of each product requirement. Product Manager can use those as
a reference to understand whether right product requirements are prioritized even
though (s)he might make exceptions to the rule.
Activity vs tasks
Activity could be termed as a sequence or series of steps that coalesce together to
complete an entire event or a job. Those specific sequences or individual steps of an
activity could be termed as a task. Activity encompass everything from start to finish of
a specific job. Naturally, activity comprises of various tasks. Activity could be organizing
a webinar. While tasks could be following sequence of series of steps of organizing a
webinar. Scheduling a webinar, inviting prospective attendees to register for a webinar,
sending invites to all registered attendees, presenter(s) and panelist(s), allowing them to
add the invite to calendar, sending remainders, providing a window to allow attendees
to post questions and panelists to respond during webinar, optional form post the
webinar for seeking feedback etc. Tasks are analogous to features, while activities are
more related to outcomes or jobs-to-be-done. While prioritizing features we have to
ensure whether subset of prioritized features coalesce to complete a new activity that
could not be performed by the product until now or enhance an existing activity that
could be performed by the product. Our choice of attributes indirectly focuses on
activities, however because of human nature to commit flaws either in selection of

78. Page | 77
www.ProductGuy.in
Pragmatic Guide for Great PRODUCT ROADMAPPING
attributes or in selection of weights, I normally chose to identify activities performed or
enhanced by prioritized features and how those activities are in alignment with overall
direction of the product.
When consciously focusing on activities, Product Manager could understand the list of
activities performed most by customers. Product Manager could eventually try to
prioritize features that could potentially enhance those activities that drive customers to
come for more. Unfortunately, product prioritization process through scorecard
methodology does not consider activities. Adding activities to the scorecard might add
3rd
dimension making it complex for human mind. However, explicit focus on activities
might be relevant even when product prioritization process is based on non-functional
product attributes. When the focus is on non-functional attributes such as usability,
reliability, performance etc. Do Product Manager really need to focus on enhancing the
usability across the entire product? Definitely no. Product Manager can focus on
enhancing usability, reliability and performance of only those activities performed most
used by customers. Product Manager should always focus on enhancing only those
aspects of the product that influence customers to come for more.
Focusing on activities brings-in completeness to the product and probably, another
viable alternative to strengthen product prioritization process as well. Another
advantage is that it helps in marketing the outcome of group of features prioritized in
each release.
How to prioritize smaller features
I call them as low hanging requirements that will deliver reasonable value to customers
and does not take too much effort to deliver them. Those requirements are not deal
breakers but definitely good to have. When small features compete against bigger ones,
they would never find space in the product roadmap. In operating systems, I could
recollect the concept of starvation wherein operating system would employ aging
technique to avoid any low priority process from resource starvation. I would be glad to
Product Manager should always focus on
enhancing only those aspects of the product
that influence customers to come for more

79. Page | 78
www.ProductGuy.in
Pragmatic Guide for Great PRODUCT ROADMAPPING
employ such aging techniques; nevertheless, I am not heading in that direction. Product
Manager has to negotiate with engineering team to prioritize such features without
affecting the original set. The efforts are little less in delivering those features and the
risk to overall development should be minimal, engineering team can deliver those
features by optimizing their development and test cycles.
Roles, responsibilities, authority, hierarchy etc. nothing would help Product Manager to
have his way as much as personal relationship does. The relationship between
engineering team and Product Manager should be symbiotic in nature. Both the entities
should add lots of value to each other roles. Product Manager has to offer something
before asking for favors. Among many other things that Product Manager can do to let
engineering team focus on what they do best in most optimal way is to
 Add lot more clarity to product requirements (ensure it is actionable)
 Freeze product requirements and provide clarity on all the open items before
start of the development for each release
 Do not let engineering team wait on Product Manager for prioritization decisions.
 Remove any obstacles or deviations that is clogging the development or test
activities
I always believe in the principle ‘Do it right the 1st
time’. The above activities of Product
Manager would definitely aid engineering team to head in that direction and facilitate
them to do ‘Deliver more (features) with less (resources)’.

Common principles that any engineering team
should imbibe
 Do it right the 1st time
 Deliver more with less
The relationship between engineering team and
Product Manager should be symbiotic in nature.
Both the entities should add lots of value to
each other roles

80. Page | 79
www.ProductGuy.in
Pragmatic Guide for Great PRODUCT ROADMAPPING
Prioritization of defects vs requirements
I have seen many debates on Quora and other related forums regarding prioritization of
defects against product requirements. Now my belief is that both are different and I am
firm believer in ‘Engineering owns quality’. Even though quality precedes everything,
Product Manager does not pitch defects against product requirements. No product is
defect free and every requirement added to the product begets more defects. Product
Manager would collaborate with engineering team to determine the tolerance level for
the overall open defects or defects open rate. Accordingly allocate a window in each
release for resolving defects avoiding any conflict with product requirements.
Ultimately, it is the responsibility of engineering team to prioritize and resolve defects
within that window. As I had stated earlier, I am firm believer in ‘Engineering owns
Quality’. Engineering team should have complete authority over prioritization of defects
and resolve them within the guidelines of quality SLAs (Service Level Agreements).
Product manager will be encroaching into their space, if (s)he starts prioritizing defects.
I would definitely loathe if my engineering team is busy fixing defects at the cost of
evolving the product. As I had said earlier, both engineering team and Product Manager
should agree on the tolerance level for defects, if occasionally the defect rate goes
higher because of certain unforeseen reasons, I would urge Product Manager to make
more room for resolving defects probably at the expense of not addressing few
requirements. However, if it happens too often, then the defect rate should be
contained by identifying the actual root cause. Engineering team should ascertain what
is causing more defects and what is causing decline in quality to improve quality in a
longer run instead of continuing fixing defects at the expense of evolving the product. It
is as important to evolve the product continuously, as it is to maintain the quality of the
product. There cannot be any trade-off between them.
I am firm believer in ‘Engineering owns Quality’.
Engineering team should have complete
authority over prioritization of defects and
resolve them within the guidelines of quality
SLAs

81. Page | 80
www.ProductGuy.in
Pragmatic Guide for Great PRODUCT ROADMAPPING
Identification of features for future releases
Product Manager will prioritize features of upcoming release with utmost care as per
the prioritization techniques elaborated until now but Product Manager cannot follow
similar diligence for prioritization of features for future releases. Prioritization of
features for future releases cannot be done due to uncertainty surrounding customer
requirements, business environments etc. However, product roadmap should typically
contain requirements or features for future releases to indicate the overall direction in
which product is heading. The scope of this discussion is specifically for external
roadmap. Therefore, the product roadmap for future releases should typically contain
needs or jobs-to-be-done (highlighting only outcomes) or combination of features that
can unambiguously represent the needs or jobs-to-be-done. Customers care about
outcome rather than individual features that can deliver outcome. Features sound alien
to customers, so I would prefer to list the outcomes in product roadmap corresponding
to future releases. Ideally, Product Manager can identify job-to-be-done based on
anticipation of customer business challenges, pain points and desired business
outcomes. Jobs-to-be-done can be an outcome or a solution for some of the major
customer business needs or problems that the product is poised to address in future in
accordance with overall product vision and strategy. Another reason for focusing on
jobs-to-be-done is that the specific features that can facilitate the product to address
those jobs cannot be determined without doing exhaustive feasibility analysis by
engineering team.
Product Manager need not essentially list entire set of jobs-to-be-done in each release.
Probably providing a partial list directly tied to addressing critical business outcomes
and problems would be sufficient. In general, Product Manager could adapt the
following guidelines for deriving list of items highlighted in roadmap for future releases
1. Identify top must-to-be addressed jobs in accordance with customer business
challenges, pain points and desired business outcomes
2. Validate alignment of those jobs-to-be-done to product strategy
3. Ensure uncertainty of accomplishing those jobs-to-be-done is minimal
4. Conduct high-level feasibility of addressing those jobs-to-be-done.
Even though roadmap is a plan and not a commitment, customers might not appreciate
drastic changes to the product roadmap, so it is better to evaluate the feasibility of
addressing jobs-to-be-done in the product. In addition, ensure that the roadmap lists

82. Page | 81
www.ProductGuy.in
Pragmatic Guide for Great PRODUCT ROADMAPPING
only 70%-80% of what engineering team could deliver in each release. Nothing is
definitive in this world, so leave room to accommodate changes to the roadmap.
Long term product roadmap – Is it mandatory?
I would not say so. It really depends on the product, nature of the market and other
factors. For instance, if the market is evolving or the technology is evolving resulting in
lots of uncertainties on what customers might require or how technology would evolve
or mature, Product Manager would possibly be engaging in building MVPs to study the
market or validate the technology. In such cases, it would not be ideal to provide a long-
term roadmap.

83. Page | 82
www.ProductGuy.in
Pragmatic Guide for Great PRODUCT ROADMAPPING
Deadly mistakes to avoid during prioritization of requirements
Scorecard technique would definitely help eliminate all possible mistakes that could be
committed while prioritizing requirements, however not everyone does follow
scorecard technique. Therefore, I thought it would be appropriate to list down all
possible blunders committed by Product Manager while prioritizing requirements.
 Prioritizing product requirements purely based on revenue potential
It is always nice to focus on requirements that have higher revenue generating
potential, as revenue is possibly one of the most important reasons for existence
of the product. Ironically, Product Managers are also evaluated based on short-
term revenue gains instead of evaluating based on strategic activities that can
possibly have positive implications on the long-term growth of the product.
Prioritization process discussed earlier exactly balances strategic and tactical
activities. Product Manager should not get too much obsessed with revenues
losing sight of the long-term objectives. Even though without revenues,
management would cut down the resources and Product Manager might have to
evolve the product with less resources. The ideal scenario for a Product Manager
is adeptly balancing both short term and long-term priorities while ensuring
steady flow of revenue.
 Prioritizing product requirements of customers with loud voice
Customers with loud voice often have their way through escalations or making
noises at right place to right people. It is always easy for Product Manager to
succumb to pressures, but it might not end with just one request and it might
continue as a trend. If product requirements of such customers are reasonable
then there is no trouble, but prioritizing requirements just because someone is
exerting pressure is not an ideal scenario. It is better to nip such requests in the
bud without yielding to the pressure outlining the implications of acknowledging
Ironically, Product Managers are also evaluated
based on short-term revenue gains instead of
evaluating based on strategic activities that can
possibly have positive implications on the long-
term growth of the product

84. Page | 83
www.ProductGuy.in
Pragmatic Guide for Great PRODUCT ROADMAPPING
such requirements to the management. In the later part of this eBook, I have
outlined some actionable points on how to say ‘NO’ to customers hijacking the
product roadmap in a convincing manner without antagonizing them.
 Prioritizing product requirements concurring with engineering team
Product Manager can have possibly two extreme types of engineering team (i)
Sluggish and (ii) Motivated. Either way it would be trouble managing them.
(i) Sluggish team
They always look for reasons to turn down high effort requirements and probably
enjoy basking themselves committing to low effort requirements. They are
mostly risk averse. Product Manager should primarily be ruthless while dealing
with sluggish team.
(ii) Motivated team
Technology trends and advancement captivate them and they mostly look
forward to do stuff that is cool. They enjoy challenges thrown by complex
problems. Their aspiration is around technology and not around customers.
Product Managers should always stay on top of them to guide and steer their
efforts in appropriate direction that might add lots of value to customers.
Product Manager cease to exist if (s)he let engineering team take a decision on
prioritizing the requirement for a simple reason that Product Manager is either
lazy or could not grasp technical nuances to understand what value is rendered
by each requirement to customer business environment and how the
requirement is aligned with overall product purpose. Product Manager is a
gatekeeper of the product and (s)he should be aware of every change made to
the product.
ProductManager isa gatekeeper of the product
and (s)he should be aware of every change
made to the product

85. Page | 84
www.ProductGuy.in
Pragmatic Guide for Great PRODUCT ROADMAPPING
Irrespective of the complexity of the product, Product Manager should have
absolute awareness of every single change made to the product.
 Prioritizing product requirements because you (Product Manager) felt that
those requirements add value to customers
Being a hands-on Product Manager is a nice quality and I do insist on Product
Managers getting their hands dirty with the product, so Product Manager can
independently evaluate the product gaps when trying to understand the
customer needs without troubling engineering team. Such hands-on quality will
also allow Product Manager to independently identify product gaps, however the
requirements has to be judiciously prioritized after gaining a thorough
understanding of what kind of value could be rendered by those requirements to
customers.
Product Manager should step aside for a while and move to other side of the
fence to evaluate whether those requirements would be valued by customers
and try to estimate the amount of value rendered to customers. There should not
be any bias towards requirements identified by Product Manager while
prioritizing entire gamut of product requirements for each release.
 Prioritizing product requirements of the user instead of the buyer
User and buyer are two different entities in case of B2B product. In most cases,
Product Manager would talk to both buyer and user. While buyer can throw light
about his/her potential business challenges, user can throw light about his/her
experiences using the product and feedback on how the product could be further
improved. I am not advocating that Product Manager should only prioritize buyer
needs over user needs, even though buyer needs gain relatively higher priority as
those needs directly influence the customer business. I would rather insist that
Product Manager should appropriately recognize the role of the entity
communicating the need and prioritize the need at the face value of it by
determining whether the need is enhancing the usability of the product or
addressing any critical business challenges.
 Prioritizing requirements without a common theme
Theme is a unifying factor for majority of product requirements prioritized in
each release. Why do we need a theme or unifying factor for each release? Each

86. Page | 85
www.ProductGuy.in
Pragmatic Guide for Great PRODUCT ROADMAPPING
person might have their own views on the need for themes, some outline that
themes help in better prioritization. At least, I opine that themes help in better
marketing of the product release. If product requirements prioritized in a release
were scattered across multiple areas such as usability, performance, stability etc.,
it would be tough to construct a unified message to indicate the value delivered
in each release. I have earlier talked about identifying product objectives and
attributes, later measure how each requirement is performing against those
attributes. Doing so, majority of the features are categorized under one or two
product attributes and those attributes can provide a unifying theme for the
entire release. I derive the theme from the list of prioritized features.
Certain experts do recommend listing down themes and start prioritizing
requirements based on themes. Alternately, list down all the prioritized
requirements and categorize them into themes, later deliver requirements of one
or two themes in each release. Honestly, there is no right or wrong approach.
Even the scorecard methodology that I had outlined in the previous section will
let the Product Manager indirectly prioritize requirements based on themes
through assigning more weights to specific product attributes.
 Prioritizing requirements yielding to the pressures of sales team
Sales Manager is one of the stakeholders that can discover and communicate
product requirements because they interface with customers regularly and keep
tab of their expansion plans. While communicating product requirements, Sales
Manager attach revenue figures that can aid Product Manager better prioritize
those requirements. In most cases, the revenue figure would be most optimistic
and it might not often reflect the real potential. Least in some cases, the revenue
would not realize even after delivering those requirements. Yet Product Manager
has to gamble especially if the revenues are either dying or dwindling. However,
(s)he can go for a calculated gamble instead of purely relying on the data
provided by sales manager.
a) Does customer has compelling reasons to buy the product.
b) Is customer evaluating any competition?
c) What is the budget allocation of customer? Do they have money left to buy
the product?

87. Page | 86
www.ProductGuy.in
Pragmatic Guide for Great PRODUCT ROADMAPPING
d) Is there any prior incident of customer requesting product features promising
revenue? Did they consistently bought the product or just got their job done
under the veil of promising revenue opportunities?
In a different scenario, Sales Manager will close certain deals promising few
requirements on roadmap even though roadmap is a plan and not a
commitment. In such cases, Product Manager would add exceptions to provide a
commitment to customers. Product Manager should not allow Sales managers to
make the promise. Instead, Product Manager should analyze entire set of
customer requirements and after careful evaluation of already planned activities
should make a commitment to the customer. Product Manager should be
confident enough to deliver the committed features within the promised
timelines in addition to existing commitments.

88. Page | 87
www.ProductGuy.in
Pragmatic Guide for Great PRODUCT ROADMAPPING
Product requirement backlog – How to manage
Discovery of needs is a continuous activity that would span across 365*24*7 and there
is never an end to the process. While discovering needs, I would insist to focus on
quantity and not on authenticity or veracity of the needs. I do not mind digging my way
through a maze to find out most valuable needs to incorporate in the product, but I hate
or rather dread to encounter a situation where competitors spot a need before we do.
Therefore, I always advocate collating as many needs as possible from various entities
(Engineering, Sales, BDMs, and Account Managers etc.) as they could possibly perceive,
anticipate and understand.
Certain problems are good to have. Huge product requirement backlog will definitely
complicate prioritization process of product requirements. However, it is a good
challenge for Product Manager to encounter.
Record needs
In the initial section of this eBook, I had elaborated about need vs requirement. I would
prefer to document needs as it is in the product backlog tool. As I indicated in my
definition of need vs requirement, requirement is outlined from engineering perspective
while need is outlined from customer perspective. Therefore, the ideal location to
translate need into requirement and record it is in PRD. The appropriate timeframe to
translate needs into requirements is while drafting PRD. The methodology to store
needs could be the prerogative of the Product Manager. There are many tools to store
needs. For convenience, let me assume that Product Manager uses excel.
While discovering needs and recording them in the product backlog tool is a continuous
activity, Product Manager periodically gets into the below mentioned sequence of linear
activities before the start of each release
1. Needs triage
2. Categorize needs
3. Refine needs
4. Draft PRD
5. Prioritize requirements and
6. Organize product backlog

89. Page | 88
www.ProductGuy.in
Pragmatic Guide for Great PRODUCT ROADMAPPING
Product Manager should plan the entire sequence of activities in such a way that on the
1st
day of the start of development work for a release, Product Manager should clearly
outline the list of prioritized requirements. I repeatedly insist that the list should be
actionable and well-articulated, so engineering team does not get into repeated cycles
of requirement clarification. The primary purpose of engineering team is to either build
or evolve products. Product Manager will plan his activities meticulously to let the
engineering team focus on what they do best. The worst thing that could happen is
engineering team hanging on Product Manager for clarifying requirements, making
decisions etc.
Figure 14: Organizing product requirement backlog
Needs triage
I derived the title for this section from ‘Defects triage’. It is similar to defects triage
conducted by engineering team. Product Manager has to analyze each need and
categorize them. The entire purpose of needs triage is to identify subset of needs that is
worth prioritizing for upcoming release.
Refine needs
Draft the
PRD/Prirotize
needs
Organize
product
backlog
Draft the PRD
Needs triage
Categorize
needs
Discover needs – Add to product backlog tool

90. Page | 89
www.ProductGuy.in
Pragmatic Guide for Great PRODUCT ROADMAPPING
Categorize needs
The outcome of needs triage is to filter them under one of the possible categories
1. Discarded - The needs under this category are not worth pursuing further for one
of the following reasons
 Duplicate – Already tracked through another need or rather combined with
another need
 Product currently has the capability to address the need – In addition to
discarding the need, there is a necessity to educate the requested customer(s)
how their need could be addressed using existing product capabilities
 Does not align with overall purpose of the product
 Not feasible – The product could not address the need, Product Manager took
the decision after careful evaluation with engineering team. Even before
handing over the requirements to engineering in the form of PRD, there can
be little informal discussions around needs.
 Age out – The need exists in product backlog for a long time and no customer
seems to be interested in it and it does not even fall under ‘Parked for future’
category, so the need ages out. Discarded automatically after existing in the
backlog for a certain duration, Product Manager should define the duration
for aging based on the nature of the product.
2. Parked for future - As the heading implies, the need is reserved for future triage
 Existence of dependent need or infra – The need could only be addressed
after addressing a dependent need or providing support for dependent
infrastructure.
 Ahead of its time – Product Manager should evaluate every individual
requirement for its timing. The requirement might have dependencies or
customer just not ready to consume it. Either way, if the timing is not right,
Product Manager should hold the requirement in abeyance for later
prioritization.
3. To be prioritized - The needs under this category will be converted into
requirements added to PRD and will be prioritized for the upcoming release. The
requirements under this category will undergo the prioritization process
explained earlier.

91. Page | 90
www.ProductGuy.in
Pragmatic Guide for Great PRODUCT ROADMAPPING
Refine needs
Once the list of ‘To be prioritized needs’ are derived. Ensure each need has sufficient
information for translating into a requirement. In addition, categorize the need into i)
tactical, ii) strategic or iii) disruptor. For more clarity and inputs, please refer to
‘Categorizing requirements’ section
Draft the PRD
Remember the tenets of requirements, Product Manager has to ensure that each
requirement has ‘WHAT’ and ‘WHY’, most importantly ‘CONTEXT’ as well. Product
Manager has to strive to make each requirement as detailed as possible and ensure that
the requirements are actionable. Immediately after drafting all the requirements in the
PRD, share the PRD with engineering team to facilitate further discussions on the each
of the requirements.
Prioritize the requirements
Drafting requirements and deriving solution to address those requirements does not
happen in linear fashion, while discussing the requirements with engineering based on
their inputs certain requirements take even better shape. Exactly for those reasons,
Product Manager has to complete the exercise of drafting the PRD at least 3-4 weeks
before the start of the development and use remaining 3-4 weeks for brainstorming
with engineering and rest of the stakeholders for crystalizing and refining each of the
requirements. After all the requirements are refined, Product Manager has to derive the
prioritized list of requirements for the upcoming release.
Organize backlog
Entire set of needs under product backlog are classified into 3 broader categories
 Open
 Completed
 Ongoing
If I use excel for maintaining product backlog, I maintain 3 tabs for each of the above
categories. Under the open category, I would classify entire needs as identified below
and use color codes for differentiation. Next time Product Manager attempts to triage,
(s)he need not triage all the needs, instead triage the needs color coded in RED and
ORANGE

92. Page | 91
www.ProductGuy.in
Pragmatic Guide for Great PRODUCT ROADMAPPING
Triaged Needs
Not Triaged Needs
Parked for Future Needs
Completed category would have all the needs incorporated into the product along with
the release numbering. I use this list as a reference to identify the list of needs
incorporated in each release or identify the release that addressed a specific need.
Ongoing category would have all the unfulfilled needs for accomplishing in future
product releases. After finalizing the list of needs that will be addressed in the upcoming
release, I will move the contents of previous release from ongoing to completed
category and update the release number with the version of previous release. Later
move the prioritized list of needs in the ongoing release from open category to ongoing
category.
Figure 15: Categorizing requirements backlog
Open Ongoing Completed
Prioritized
Requirements
Completed
Requirements

93. Page | 92
www.ProductGuy.in
Pragmatic Guide for Great PRODUCT ROADMAPPING
Measure the efficacy of product roadmap
Product roadmap is one of the most critical elements that determine long-term success
of the product. If Product Manager does not measure the efficacy of the product
roadmap, it is not possible to improve the process of preparing product roadmap that
fuel product success. To measure anything, we need to set goals. I have already outlined
that product roadmap is a plan of execution to accomplish product objectives. There
would be a timeframe to accomplish the product objectives and Product Manager
should periodically assess the contribution of product roadmap in realization of product
objectives. Product Manager should assess whether product is on right path to
accomplish product objectives. Product objectives could be targets related to one or
more of the following: revenue, growth, margins, market expansion etc.
Understanding customer needs and addressing needs valued most by customers is a
means to achieving product objectives but it is not the only means. I always maintained
that merit of the product contributes utmost 50% (or little higher but definitely not
100%) to a successful sale. In any selling process, customers evaluate the product
against certain set of attributes. The attributes include both product and non-product;
both of them jointly influence the selling process. For instance, in case of restaurant
where food is a product, ambience and location of the restaurant is as important as the
taste of the food. In case of B2C, marketing plays a critical role in communicating the
value of the product and establishing an emotional connect. In case of B2B, the
existence of reliable support system, brand, and distribution network are other
important factors that complement the core product. So establishing a direct causal and
effect relation between product roadmap and product objectives is not foolproof.
Therefore, in addition to using product objectives as a means to measure efficacy of
product roadmap, I am also advocating the use of feature usage metric.
During prioritization of product requirements, I indicated about the need to pick right
product attributes valued most by customers and assign appropriate weights. While
measuring the efficacy of product roadmap, the single most important criteria is to
evaluate whether Product Manager has picked the right product attributes that will
influence the selling process. Two methodologies indicated earlier will be used to
measure the efficacy of product roadmap and to provide reinforcing feedback back into
product requirements prioritization process, so right product attributes that are valued
most by customers could be used to prioritize requirements.

94. Page | 93
www.ProductGuy.in
Pragmatic Guide for Great PRODUCT ROADMAPPING
Product objectives (aka goal) metrics
The purpose is to continuously ascertain the progress and identify whether the product
is on the right track to accomplish the objectives. Product Manager has to identify and
establish a causal and effect relationship between features introduced in each release
and product objectives (growth, margin, revenues) measured post the release.
How do we know whether features X, Y & Z introduced in a release has contributed to
accomplishing product objectives? How do we know there are no other factors (possibly
marketing campaigns, discounts etc.) that could have positively influenced product
objectives? It is a tough to establish such absolute correlation between features
introduced and product objectives. Feature usage metrics elaborated in later section
talks about the usage density of features introduced in each release, Product Managers
could presumably use the data to establish a correlation between features and product
objectives.
Figure 16 – Product prioritization cycle
Product Manager can alternatively use conjoint analysis to determine the list of
attributes valued most by customers. Product Manager could later use the data to
determine whether (s)he has employed similar attributes for product prioritization
decisions. Conjoint analysis can help Product Manager understand whether customers
are buying the product for the same reasons that (s)he has envisaged. If customers are
buying the product for its reliability and price while Product Manager assuming that
customers are valuing the product for its design and usability might not be a nice
situation because any further prioritization decisions will be focused more on design and
usability instead of reliability. Each customer will have their own reasons and no two
Product
Objectives
aka Goals
Product
Roadmap
Deliver
Value to
Customers
Prioritize Features Accomplish

95. Page | 94
www.ProductGuy.in
Pragmatic Guide for Great PRODUCT ROADMAPPING
customers are alike. Yet, Product Manager has to wisely choose a sample of customers
and understand the common patterns that will influence their buying behavior.
Product Manager should conduct similar exercise if the product is far from realizing the
product objectives as well. Product Manager should always identify reasons behind
success and failure. Product Manager had to analyze the losses to determine whether
the losses are due to lack of understanding of product attributes valued most by
customers or due to any other factors (probably related due to lack of non-product
attributes or due to lack of awareness among customers etc.)
In either case, Product Manager has to identify the set of product attributes valued
most by customers and reinforce the feedback back into product prioritization process
to ensure that prioritization of product features is always based on right attributes
valued most by customers.
Figure 17 - Product attributes feedback loop
I wrote another eBook ‘Comprehending Customer Buying Process’ to understand the
psyche of a customer during buying process and to understand the combination of
attributes (both product and non-product) that influences the buying decision of
customers. The eBook is an attempt to explore the list of product attributes that plays a
vital role in successful sale of a product and Product Manager can use the
Product
Roadmap
Product
Objectives
Measure Objectives
Reinforce Feedback

96. Page | 95
www.ProductGuy.in
Pragmatic Guide for Great PRODUCT ROADMAPPING
methodologies explored in the eBook to identify the list of product attributes that can
positively affect product objectives.
Feature usage metrics
The idea of feature usage metrics is to understand whether top prioritized features are
mostly used features by customers. If not, something might be terribly going wrong with
the process of prioritizing product requirements. The primary premise of the exercise is
that customers use features only if they are useful for them. They do not use features
just because they are available on the product. Not every product would have a direct
mechanism to understand on how many customers are using each feature, in such
scenario I normally take the help of support system.
Every organization has an impeccable support system to address customer issues
promptly in a satisfying manner within the limits of well-defined SLA. The customer
support software that manages the entire support infrastructure would have the basic
capability to raise tickets, re-submit tickets, provide feedback, assign engineer and close
tickets etc. In addition, the customer support software would also have analytics
support to provide below highlighted insights that can help measure the efficacy of the
support systems
 How many support cases does each customer raise?
 How many support cases each support engineer resolve?
 How many support cases were resolved within the guidelines of SLA?
 What is the lean period and peak period for receiving cases?
 ….
The discussion of the current topic is to go beyond those traditional insights. I am not
trying to open a debate on the nature of the support system and I am only trying to
emphasize that Organization can process the data gathered by support system for
insights that are more meaningful. The information when analyzed properly can provide
lot more insights which when acted upon can effectively strengthen the product. One
key insight would be list most-used or least-used features. In addition, support cases can
provide lot more additional data that can strengthen the process of preparing great
product roadmap. Please be aware that some of the insights are based on the premise
that no product is DEFECT FREE.

97. Page | 96
www.ProductGuy.in
Pragmatic Guide for Great PRODUCT ROADMAPPING
Most used/ least used features
Such list can help Product Managers better prioritize features. Most used features can
provide a clear view of what interests most to customer and Product Manager can
target to evolve those features to create a stickiness factor. In case of least used
features, Product Manager can understand the reason behind prioritizing those features
and later revisit the feature prioritization strategy. Product Manager can take a
conscious look at the attributes used for prioritization of features. Also in case of an
attempt to eliminate unnecessary features to make a lean product, list of least used
features will be handy.
Feature usage metrics will reflect the efficiency of product requirements prioritization
process. Product Manager can use those metrics to revisit the prioritization process
whether (s)he is choosing right attributes (product attributes are already defined in
‘Prioritizing product requirements’ section) to identify requirements that are valued
most by customers. In this methodology, the underlying assumption is that the
customer is aware of all the features available in the product and lack of usage of any
features is not due to lack of awareness.
In the event of no proper mechanism to derive feature usage metrics even with the help
of support system, identify how many customers are at least migrating to the latest
releases. If the majority of customers are still stuck with older releases, then Product
Manager could at least presume that there is nothing exciting for customers to migrate
to latest release unless the migration process is hindered by the complexity in migrating
from older releases to newer releases.
Gauge the mood – Measure the perception
I would not call it as a methodology as it is more subjective. In general, the said
methodology does not indicate any thing specifically about the prioritization process
and effectiveness of the chosen attributes. This methodology is to measure the
perception of everyone (primarily customers) especially when the business model
supports sharing of product roadmap. When Product Manager shares the roadmap with
customers elaborating about features available in the product over the next couple of
years and what outcomes to they deliver, Product Manager has to understand the
reaction of each customer. Do customers get excited and enquire eagerly of features
available in subsequent releases or do they not react or express anguish over the

98. Page | 97
www.ProductGuy.in
Pragmatic Guide for Great PRODUCT ROADMAPPING
inability of product roadmap to match their business requirements. Sometimes, silence
is no good. As I have been stating all along, no two customers are alike, so look for
generalized reaction of broader set of customers.
Perception of customers reflects in their actions and therefore measuring the
perception is critical to make customers invest in the product. Perception sometimes
contradicts the ground reality and if it does so in a negative way, nothing could be more
disastrous. The ground reality might be that the product is at the forefront of innovation
and perfectly evolving to meet the business challenges of customers. If customer(s)
perception about the product is contradictory and it would obviously reflect in their
decision to invest on the product. Customer visits, escalations are quite a few ways to
measure the perception and Product Manager could measure perception through
product roadmap presentations as well.
Promising product roadmap creates positive vibes among internal stakeholders too
(more importantly engineering and sales team). Present the roadmap to them as well. I
have earlier talked about leveraging the expertise and experience of sales and
engineering team to discover customer needs, so it is only appropriate to share the
roadmap throwing signals that preparing roadmap is an inclusive approach. Take their
feedback and gauge their perception as well, product roadmap should motivate
engineering team to build better product and sales team to sell more. Internal
stakeholders should be excited about the product roadmap and should be convinced
about the direction in which product is heading.

99. Page | 98
www.ProductGuy.in
Pragmatic Guide for Great PRODUCT ROADMAPPING
Customer hijacking the product roadmap – How to avoid
I have talked about prioritizing requirements to list them in chronological order in
product roadmap. Product Manager diligently prepares the product roadmap to reflect
the product growth strategy. Nevertheless, nothing works as per the plan. First
roadblock that every Product Manager face is some unexpected product requirement
requests from their customers and those product requirements will be total deviation
from the items planned in the roadmap.
I bet every Product Manager would face this situation on every day basis. So how do
Product Managers stop their customers from hijacking the product roadmap? Before
Product Manager definitely puts his/her foot down and says NO irrespective of revenue
contributing potential of the customer, I shall suggest Product Manager to follow the
following steps (aka decision tree) to mitigate the situation in a way that it is win-win for
both the Customer and Product Manager.
The entire exercise might not be required if the business model is to entertain
customizations or handle specific customer requirements for additional $$$.
Step 1: Understand the requirement – WHY?
It does not suffice if Product Manager is aware of what the requirement is. (S)He needs
to have a broader understanding of why customer has asked for the requirement.
Unless Product Manager gets a grasp of the underlying reason or cause behind the
product requirement, (s)he will not be able to make informed decisions in the
subsequent steps. Understanding WHY behind every requirement is critical because on
most occasions the requirements are merely symptoms of customer problems
manifested as solutions.
Also, please look at my blog on ‘Understanding customer requirements’ @
ProductGuy.in.
Understanding WHY behind every requirement
is critical because on most occasions the
requirementsare merely symptoms of customer
problems manifested as solutions

100. Page | 99
www.ProductGuy.in
Pragmatic Guide for Great PRODUCT ROADMAPPING
Step 2: Validate the requirement
Is the requirement valid? In certain cases, (mostly in B2B environment) because of lack
of product awareness or technology, customer raises product requirement that is either
invalid or not feasible within the scope of the product. If the requirement is invalid, we
should definitely attempt immediately communicating the information back to the
customer with appropriate reasoning.
Step 3: Understand the business criticality
Understand the potential business impact to the customer because of not fulfilling the
product requirement. Does the requirement have any potential revenue impact, is the
requirement to enhance the usability of the product, or is the requirement just nice to
have a feature? In case of revenue impact (either direct or indirect), the stakes for
delivering the product requirement goes HIGHER.
Step 4: Identify alternate (optimal) mechanisms to accomplish the requirement using
existing infra of the product
In the initial step, I suggested to look for actual reasons behind the requirement ie
Product Manager needs to understand the WHY part of the requirement in addition to
WHAT part of the requirement. Having known the WHY part, Product Manager needs to
figure out whether there are any alternate optimal mechanisms to address the WHY
using existing product infra. If yes, communicate the alternate mechanisms to the
customer provided Product Manager gets convinced that the alternate mechanism is
actually the optimal way of addressing WHY.
In case of no alternate mechanism to address the requirement, let us proceed with next
steps.
Step 5: Is the requirement generic or customized
Is product requirement custom or generic? Understand whether the requirement is
customized to the requested customer or it can be generalized for broader segment of
customers. In case of generic, Product Manager might not have discovered the need and
it is good that some customer has brought this to his/her attention. Product Manager
adds the requirement to the requirements backlog tool and determines the timeline to
deliver it depending on the business criticality and requirements prioritization process.
In fact, I have talked in detail about how to prioritize requirements in earlier section. If
the delivery timeline conflicts with the expectations of the customer, then Product
Manager has to negotiate – move to step 7.

101. Page | 100
www.ProductGuy.in
Pragmatic Guide for Great PRODUCT ROADMAPPING
Step 6: Understand other additional requirements of customer
We have reached this step because the product requirement is customized. In case of
customized product requirement, please do not look at the requirement in isolation.
Take a look at other requirements from that customer, also take a look at the
requirements available in the roadmap and figure out how many of them would be
applicable to the requested customer.
Step 7: Negotiate
Identify possibilities to trade the customer requirement with any of the generic
requirement(s) already available in the product roadmap. Even if the customer
requirement is critical, as long as Product Manager is able to compensate with other
requirements that matter most to the customer, it would definitely be a WIN-WIN
situation. If someone insists there is nothing to compensate and there are no product
requirements in the roadmap that would suit the customer, then I could only think 2
possibilities (i) our understanding of the customer is flawed (ii) customer does not
actually belong to the target segment. Please note that it is worthy to forego a sale
rather than selling to a wrong customer.
Earning the trust and credibility of the customer is mandatory to engage in a meaningful
conversation and to communicate the NO for any product requirement request in a
convincing manner.
It is worthy to forego a sale rather than selling
to a non-target customer

102. Page | 101
www.ProductGuy.in
Pragmatic Guide for Great PRODUCT ROADMAPPING
Concluding thoughts
Product roadmap can either make or break a product and therefore product roadmap
demands high attention from the Product Manager. Product roadmap is a combination
of tactical and strategic steps to secure short term and long-term revenues respectively.
Product roadmap ensures that the product is evolving with changes in technology,
customer behaviors and business challenges etc. to stay ahead of the curve. It might be
appropriate to call ‘Product Roadmap’ as a continuous journey with a primary
motivation of evolving the product in the face of uncertainties and unknowns both from
the perspective of customer problems/needs and corresponding solutions to address
those problems or needs. Product roadmap not only determines the longevity of the
product but also of the product line, it is the responsibility of the product manager to
suggest alternate break through products anticipating that the existing product would
face its decline eventually.
During my MBA days, I constantly hear a phrase ‘there is never a right strategy, there is
never a right approach, there is never a right solution’. True to those statements, any
write-up on roadmap can only provide guidance or framework. What I had shared in this
eBook is entirely based on my experiences of building product roadmap for the past 5
years for B2B HW product. I tried to focus on methodologies for drafting product
roadmap independent of development approaches. For those reasons, there will not be
any jargons related to agile, waterfall or any other development methodology.
Development methodologies should have no impact on the approaches adopted to
prepare a roadmap.
I really appreciate any feedback about the contents. Please drop your comments either
at my blog (www.ProductGuy.in) or via murali.erraguntala@gmail.com.
Happy Evolving Products 

103. Page | 102
www.ProductGuy.in
Pragmatic Guide for Great PRODUCT ROADMAPPING
Annexure A
IOT – Internet of Things. The Internet of Things (IoT, sometimes Internet of Everything)
is the network of physical objects or "things" embedded with electronics, software,
sensors and connectivity to enable it to achieve greater value and service by exchanging
data with the manufacturer, operator and/or other connected devices based on the
infrastructure of International Telecommunication Union's Global Standards Initiative.
Internet of Things connect physically and remotely by individuals, for both public sector
and private sector, in the sense of a computer network grid, of a created electrical
device that is in place, with economic benefit and potential usefulness. Each thing is
uniquely identifiable through its embedded computing system but is able to
interoperate within the existing Internet infrastructure. Experts estimate that the IoT
will consist of almost 50 billion objects by 2020.
B2B – Business-to-Business. Business-to-business (B2B) refers to a situation where one
business makes a commercial transaction with another. This typically occurs when:
I. A business is sourcing materials for their production process, e.g. a food
manufacturer purchasing salt
II. A business needs the services of another for operational reasons, e.g. a food
manufacturer employing an accountancy firm to audit their finances
III. A business re-sells goods and services produced by others, e.g. a retailer buying
the end product from the food manufacturer
PRD – Product Requirement Document. A Product Requirements Document (PRD) is a
document containing all the requirements to a certain product. It is written to allow
people to understand what a product should do. A PRD should, however, generally
avoid anticipating or defining how the product will do it in order to later allow interface
designers and engineers to use their expertise to provide the optimal solution to the
requirements.
MVP – Minimum Viable Product. Minimum viable product (MVP) is a product with just
enough features to gather validated learning about the product and its continued
development. Gathering insights from an MVP is often less expensive than developing a
product with more features, which increase costs and risk if the product fails, for
example, due to incorrect assumptions. The term was coined and defined by Frank

104. Page | 103
www.ProductGuy.in
Pragmatic Guide for Great PRODUCT ROADMAPPING
Robinson, and popularized by Steve Blank, and Eric Ries. It may also involve carrying out
market analysis beforehand.
ISPs – Internet Service Providers. An Internet service provider (ISP) is an organization
that provides services for accessing, using, or participating in the Internet. Internet
service providers may be organized in various forms, such as commercial, community-
owned, non-profit, or otherwise privately owned.
NFV - Network Function Virtualization. Network functions virtualization (NFV) is a
network architecture concept that proposes using IT virtualization related technologies
to virtualize entire classes of network node functions into building blocks that may be
connected, or chained, to create communication services.
SDN - Software Defined Network. Software-defined networking (SDN) is an approach to
computer networking that allows network administrators to manage network services
through abstraction of lower-level functionality. This is done by decoupling the system
that makes decisions about where traffic is sent (the control plane) from the underlying
systems that forward traffic to the selected destination (the data plane). The inventors
and vendors of these systems claim that this simplifies networking.
M2M – Machine-to-Machine. Machine to Machine (M2M) refers to technologies that
allow both wireless and wired systems to communicate with other devices of the same
type. M2M is a broad term as it does not pinpoint specific wireless or wired networking,
information and communications technology. This broad term is particularly used by
business executives. M2M is considered an integral part of the Internet of Things (IoT)
and brings several benefits to industry and business in general as it has a wide range of
applications such as industrial automation, logistics, Smart Grid, Smart Cities, health,
defense etc. mostly for monitoring but also for control purposes.
HW – HW is the abbreviation for ‘hardware’
B2C (Business to Consumer). The final customer is the consumer with a B2C business.
Housecleaning services, restaurants and retail stores are examples of B2C companies.
Websites that offer consumer products are B2C. The B2C sales cycle is shorter.

105. Page | 104
www.ProductGuy.in
Pragmatic Guide for Great PRODUCT ROADMAPPING
The Unique Selling Proposition (USP) or Unique Selling Point is a marketing concept
first proposed as a theory to explain a pattern in successful advertising campaigns of the
early 1940s. The USP states that such campaigns made unique propositions to
customers that convinced them to switch brands. The term was developed by television
advertising pioneer Rosser Reeves of Ted Bates & Company. Theodore Levitt, a
professor at Harvard Business School, suggested that, "Differentiation is one of the most
important strategic and tactical activities in which companies must constantly engage."
SLA – Service Level Agreement. A service-level agreement (SLA) is a part of a service
contract where a service is formally defined. Particular aspects of the service - scope,
quality, responsibilities - are agreed between the service provider and the service user.
A common feature of a SLA is a contracted delivery time (of the service or performance).
As an example, Internet service providers and telecom companies will commonly
include service level agreements within the terms of their contracts with customers to
define the level(s) of service being sold in plain language terms. In this case the SLA will
typically have a technical definition in terms of mean time between failures (MTBF),
mean time to repair or mean time to recovery (MTTR); identifying which party is
responsible for reporting faults or paying fees; responsibility for various data rates;
throughput; jitter; or similar measurable details.
PLM - In industry, product lifecycle management (PLM) is the process of managing the
entire lifecycle of a product from inception, through engineering design and
manufacture, to service and disposal of manufactured products. PLM integrates people,
data, processes and business systems and provides a product information backbone for
companies and their extended enterprise
The definition provided for the above acronyms are directly picked from WIKI.