Pragmatic Approach for Building GREAT Product Roadmap

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

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

Page | 2
www.ProductGuy.in
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

Page | 3
www.ProductGuy.in
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

Page | 4
www.ProductGuy.in
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

Page | 5
www.ProductGuy.in
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

Page | 6
www.ProductGuy.in
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

Page | 7
www.ProductGuy.in
“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

Page | 8
www.ProductGuy.in
“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

Page | 9
www.ProductGuy.in
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.

Page | 10
www.ProductGuy.in
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’

Page | 11
www.ProductGuy.in
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

Page | 12
www.ProductGuy.in
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.

Page | 13
www.ProductGuy.in
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

Page | 14
www.ProductGuy.in
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

Page | 15
www.ProductGuy.in
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

Page | 16
www.ProductGuy.in
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.

Page | 17
www.ProductGuy.in
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

Page | 18
www.ProductGuy.in
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

Page | 19
www.ProductGuy.in
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

Page | 20
www.ProductGuy.in
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

Page | 21
www.ProductGuy.in
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

Page | 22
www.ProductGuy.in
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

Page | 23
www.ProductGuy.in
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

Page | 24
www.ProductGuy.in
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.

Page | 25
www.ProductGuy.in
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

Page | 26
www.ProductGuy.in
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.

Page | 27
www.ProductGuy.in
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

Page | 28
www.ProductGuy.in
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

Page | 29
www.ProductGuy.in
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

Page | 30
www.ProductGuy.in
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

Page | 31
www.ProductGuy.in
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

Page | 32
www.ProductGuy.in
 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

Page | 33
www.ProductGuy.in
 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

Page | 34
www.ProductGuy.in
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

Page | 35
www.ProductGuy.in
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?

Page | 36
www.ProductGuy.in
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.

Page | 37
www.ProductGuy.in
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

Page | 38
www.ProductGuy.in
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

Page | 39
www.ProductGuy.in
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.

Page | 40
www.ProductGuy.in
Strategic Disruptor
Tactical Strategic
Figure 5 - Product offering vs Market
ExistingProduct
Offering
Existing
Market
New Market
NewProduct
Offering

Page | 41
www.ProductGuy.in
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.

Page | 42
www.ProductGuy.in
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

Page | 43
www.ProductGuy.in
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.

Page | 44
www.ProductGuy.in
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

Page | 45
www.ProductGuy.in
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.

Page | 46
www.ProductGuy.in
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.

Page | 47
www.ProductGuy.in
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?

Page | 48
www.ProductGuy.in
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.

Page | 49
www.ProductGuy.in
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

Pragmatic Approach for Building GREAT Product Roadmap

Pragmatic Approach for Building GREAT Product Roadmap

Empfohlen

Empfohlen

Weitere ähnliche Inhalte

Was ist angesagt?

Was ist angesagt? (20)

Ähnlich wie Pragmatic Approach for Building GREAT Product Roadmap

Ähnlich wie Pragmatic Approach for Building GREAT Product Roadmap (20)

Mehr von Murali Erraguntala

Mehr von Murali Erraguntala (8)

Kürzlich hochgeladen

Kürzlich hochgeladen (20)

Pragmatic Approach for Building GREAT Product Roadmap