The slides are for a course that is LIVE on Udemy.com (https://www.udemy.com/product-roadmap-101/) The slides outline how to build an effective product by translating product strategy into product roadmap for enterprise products.

1. Product Roadmap 101
Translating Product Strategy into Product
Roadmap for Enterprise Products

2. Why a Course on Product Roadmap
Among many things that a Product Manager does, (s)he
● Aligns the product to the Organizational goals and objectives
● Build consensus on product vision, strategy, and objectives
● Say NO to lots of things – To focus on a few things that can help accomplish product objectives
● Realign investments and provide directions on resource allocation and prioritization
● Unambiguously communicate the overall direction of the product
But, to accomplish them….

3. Product Manager needs a roadmap

4. Most Product Managers build Good Product Roadmaps … but
… to build Great Product, we need Great Product Roadmap

5. Objectives of this Course
Facilitate Product Managers to build Great Product Roadmap on the foundation of Product Vision and Product
Strategy
Product
Roadmap
Product
Strategy
Product Vision

6. Key Takeaways of this Course
At the end of this course
You will realize that Product Roadmap is not just a tactical tool, it is a strategic tool.
You will start using Product Roadmap for
● Building consensus among stakeholders
● Defining the strategic direction of the product
● Communicating the product direction
● Saying ‘NO’ to lots of things while saying ‘YES’ to few things that really matter
● Clarity on what is required to – Run Business, Grow Business and Transform Business
● Making rational decisions – realigning investments, resource allocation, and prioritization
● Making a successful product or technology transitions at every inflection point
● Saying ‘NO’ to a customer and yet make the customer happy 
Finally, how to evaluate the efficacy of the product roadmap

7. Targeted Audience of this Course
Obviously, Enterprise Product Managers who are on a mission to build great products
But… applicable to Development Engineers, Sales Engineers, Account Managers and BDMs (Business
Development Managers) as well
When Product Manager declines a request to approve an awesome idea or decides to let go off a $M
opportunity or says ‘NO’ to one of the key customers
The rationality lay in the PRODUCT ROADMAP
It is essential for every stakeholder involved to understand the process of roadmap preparation

8. Course Outline

9. Course Outline
Starts with defining why Product Roadmap should be built on a foundation of Product Vision and
Product Strategy
Next outline the journey of Product Roadmapping
From creating product backlog to accomplishing product objectives through ruthless prioritization
process
Product
Roadmap
Product Strategy
Product Vision

10. Course Outline (contd…)
Product Backlog
Categorization of
Requirements
Tactical
Strategic
Disruptor
Prioritization
x.y release x.z release
Measure efficacy of
prioritization process
Product Objectives
Translation of Needs  Requirements
Discovery and Understanding Needs
Collaborative Gathering of Needs

11. Course Content
The Journey of Product Roadmapping
● Introduction
○ Course Outline
● Fundamentals of Product Roadmap
● Product Vision, Strategy and Roadmap
● Product Backlog
○ Discovery and Understanding of Needs
○ Collaborative Gathering of needs
○ Journey of Needs  Requirements
● Prioritization Process
○ Objectives  Strategy  Roadmap
○ Prioritization Methodology - Scorecard
● Categorization of Requirements
○ Tactical, Strategic and Disruptor
● Inflection Point – Seizing the Opportunity
○ How Incumbents can cause disruption
● Efficacy of Product Roadmap
● How to say ‘NO’ – Yet, Not lose Customers 

12. About Me
Hi Everyone!
I am an Enterprise Product Manager and
Blogger @ ProductGuy.in
Connect me @emurali or
Murali.Erraguntala@gmail.com
https://www.linkedin.com/in/muralierraguntala/

13. Fundamentals of Product Roadmap

14. Why Product Roadmap?
● The product sans roadmap would render it directionless
● Stakeholders will steer the product in multiple conflicting
directions
● Lack of clarity on the overall direction of the product
● No immediate impact, slowly but steadily
○ Sales plummets
○ The acquisition rate of new customers dwindles
○ Gaps widen with competitor products
○ Customers whine about lack of new features that excites them
○ Lack of innovation and
○ Exodus of all the best performing employees

15. Purpose of Product Roadmap (1/3)
Customers
• Provides a confidence that the product is actively evolving
• Helps them plan their business
Sales Team
• Sell the vision of future to customers
• Close deals with the help of product roadmap

16. Purpose of Product Roadmap (2/3)
Business Development Managers
• Plan expansion into new markets
Engineering Team
• Alignment of engineering resources
• Creating a sense of purpose and excitement about the overall
direction of products

17. Purpose of Product Roadmap (3/3)
Executive Team
• Communication tool
• Unambiguously articulate how the work done by different teams
steer the products in its planned directions
Product Managers
• The impetus to consciously focus on Product Vision, Product
Strategy
• Alignment of Product Roadmap to Vision and Strategy

18. Internal vs External Roadmap
External Roadmap
Audience – Customers, Sales Team, Account
Managers and BDMs
External facing – Strictly driven by PMs
Outlines outcomes or value delivered to customers in
each release
Conceals certain internal features that do not directly
impact customers
Reviewed by various stakeholders to determine –
what to share, how much to share and when to share
Internal Roadmap
Audience – Engineering team
Strictly internal facing – Driven by both PMs and
Engineering team
Outlines exhaustive list of features delivered in each
release
Every feature committed in each release will be
visible
Reviewed and mutually agreed by both PM and
Engineering team

19. What is (not) a Product Roadmap
● Not a committed plan
● Adapts to changes in business – Roadmap is not carved on rocks
● Not prepared in haste and definitely not in reactive mode
● Every item added to the roadmap is carefully evaluated by the following criterion
○ How it helps customers’ business?
○ How it helps in achieving product objectives?
○ How it helps in realizing product purpose?
○ Is it in alignment with the product strategy?

20. Product Vision, Strategy and Roadmap

21. Definition of a Product Roadmap
The product roadmap is a plan of action that
outlines a series of tactical steps to execute the
product strategy pushing the product ahead in
the trajectory of planned direction in alignment
with the product vision while accomplishing
short-term and long-term product objectives.

22. How often did you
care about
alignment to
Product Vision?

23. Tangible goals i.e. OKRs (Objectives and Key Results)
● Increase in market cap
● Expansion into new markets (aligning to market trends)
● Growth in sales, revenues, and margins
● Addition of new technology (aligning to technology trends)
What is the core belief of the Organization?
What is the true purpose and reason behind the creation of
products?
What is the future that the Organization intends to create?
Product Vision
Product Purpose aka Product Principles Product Objectives
Moving target – In accordance with the Organization objectives
and product adoption lifecycle
Product Principle – Aids in making better product decisions
Defines THE WHY? Defines the true purpose of the product i.e. why the product exist
Defines the overall direction of the product
Product Vision

24. Product Principles
● Isn't the vision statement of great companies like Apple, Google, Toyota reflect their beliefs.
● Are n’t the products they create is a testimonial to their beliefs

25. Product Vision - Examples
We believe that we’re on the face of the Earth to make great
products.
We believe in the simple, not the complex.
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.”

26. Similar Companies, Similar Products… But, Different Principles

27. Product Strategy
Outlines the path to accomplish product objectives within the boundaries of product purpose
E.g., Introducing new products, altering existing products, targeting new markets/segments, launching new
marketing campaigns, etc.
Product Strategy
Product roadmap executes a subset of the strategy related to the product

28. Definition of a Product Roadmap – A Recap
The product roadmap is a plan of action that
outlines a series of tactical steps to execute the
product strategy pushing the product ahead in
the trajectory of planned direction in alignment
with the product vision while accomplishing
short-term and long-term product objectives

29. How do we build Product Roadmap
The product roadmap should always be built on the foundation of Product Vision and Product Strategy
Product
Roadmap
Product Strategy
Product Vision
Series of tactical steps to execute the product
strategy
Defines path to accomplish the product vision
Overarching goals – Product purpose and
objectives

30. Product Roadmap vs Product Objectives
T + 12M
Release IV.
T + 9M
Release III
T + 6M
Release II
T + 3M
Release I
Product Objectives
aka Goals
Product objectives are split into sub-goals, each release accomplishes at least one sub-goal
Sub-goal defines the theme of each release, i.e. compelling reason for customers to adopt it
Change in objectives, changes the sub-goals and the direction/contents of the product roadmap

31. Creation of Product Backlog

32. Product Backlog vs Prioritization
Product Backlog
Prioritization
x.y release x.z release
Product Objectives
We PRIORITZE what EXISTS in product backlog

33. Process to gather
exhaustive
customers’ needs

34. Product Backlog – Role of Great Product Roadmap
Great product roadmaps are just not known for
their ability to prioritize effectively but also for their
ability to gather exhaustive set of customers’ needs
Drawback – Bloating of product backlog – It is a
good problem to encounter

35. Dilemma?

36. But… How do we gather exhaustive set of
customer needs?

37. Product Backlog – Accumulating Needs
Needs not realized by customers Needs recognized by customers
Discovering Needs Understanding Needs

38. Understanding of Customers’ Needs

39. Understanding Customer Needs – Why?
Understanding customers is
delivering what they require and not
what they ask for

40. Why to deliver what customers need and not what they ask for?

41. Customers do not think twice to dump the
product that exactly contains what they
asked for in favor of the product that
optimally addresses their needs

42. Breakaway With Tradition

43. Never ask
customers what
they need,
always always
always ask why they
need

44. Understanding Customer Needs – How?
Listen to
understand
Empathy Map
Power of Why

45. Need for Empathy Map?
What people say, what
people do, and what they
say they do are entirely
different things
Margaret Mead

46. Empathy Map
• What users think and feel about
addressing the need
• What users say about the need and how
do they address it
Eliminate inconsistencies among actions
thoughts and emotions

47. Discovery of Needs

48. Discovery of Needs – Why?

49. Discovery of Needs
Customer Focus
• Knowing customers better than they know themselves
• Telling customers what they need even before they tell us
Market Focus
• Anticipate the overall direction of the market
• Predict or foresee shifts in the market

50. Discovery of Needs – Customer Focus
Know your customers better than they know about
themselves
Anticipate what they might require in short-term

51. Discovery of Needs –Market Focus
Source: https://designabetterbusiness.com/2016/05/12/how-understand-your-market-crush-competition/
• Anticipate and survive shifts in the market
• Identify the impact of technology trends,
altering customer behaviours, changes in
regulation, etc. on customers’ business

52. Discovery of Needs – How?
Immerse in customer business
Eliminate bias
Open-minded
Get ready to be surprised
Firm understanding of technology, industry, and
competition

53. Collaborative Gathering of Needs

54. Gathering of needs either through discovery or understanding should be a collaborative effort involving
However, the PMs are responsible to facilitate collaboration
Collaborative Gathering of Needs
Support Team
Engineering Team
Sales Team
Business Development
Team

55. Collaboration – Support Team
Support Team
Scale enhancements
• ‘Gangnam Style’ views broke the views counter
Outcome of support cases
1. Lack of intuitiveness – Customers lack of knowledge about product
2. Inability to achieve desired outcome – Quality issues or Design issues
3. Incompleteness – Gap between what customers desire and what is delivered
4. New feature requests

56. Collaboration – Engineering Team
Engineering Team
Product Managers own problem space (Why and What)
Engineers own solution space (How)
Magic happens when two come together to deliver
• New outcomes – Making the product better
• Technology integration – Making bets on the right emerging technology
• Value engineering - Increasing efficiencies, reducing COGs

57. Collaboration – Sales Team
Sales Team
Win/Loss analysis of
• Why do customers buy our products?
• Why are customers whining?
• What deals did the product lose? Is there any trend?
• Is there a pattern of new requests in RFPs?
Helps Product Manager identify
• Product gaps – Competition
• Identify areas of investment
• Altering customer behaviours and needs

58. Identify opportunities for product growth
• Grow the business
• What contributes to product growth?
• How to capture it?
• Demand generation – Identify white spaces
• Same product – New use-case, new target segment
• Identify risks of adjacencies
• What smartphones did to cameras and navigation devices?
• What phones did to pagers?
Collaboration – Business Development Team
Business Development Team

59. Collaborative Gathering of Needs – Basic Tenets
● Never demand – Influence without authority
● Nurture relationship before collaboration
● Unfair to expect them to deliver needs in a platter
● Each collaborator might provide a small piece of a puzzle
● Help them ask the right questions – Make them think like a Product Manager
● Aid them with tools – 5Ws

60. Five Ws – Requirements Gathering Tool

61. Five Ws – Washington Monument Example
● Most needs are a manifestation of a solution
● There is always a gap between what customers say they need and what
they actually need
● Product backlog should accumulate problems or needs, not solutions
● Understand what triggers the need
● Comprehend cause and the effect
● 5Ws through an iterative process of Why? - An ideal tool to understand the
REAL PROBLEM or REAL NEED

62. Five Ws Approach
Why were gnats on the monument?
Because the gnats were attracted to the lights at dusk
Why were spiders on the monument?
Because spiders feasted on all the gnats there
Why did the Monument attract birds?
Because birds feasted on all the spiders
Why the Monument should be cleaned?
Because of the bird droppings?
Why the Washington Monument was falling apart?
Because harsh chemicals were used to clean it

63. Five Ws Approach – Effect vs Cause
Effect
Cause
Washington
Monument was
falling apart Monument was
1st to turn on
lights
Why? Why? Why? Why? Why?Effect Cause

64. Traditional Approach vs 5Ws Approach
Problem • Washington Monument was falling apart
Analysis • WHY? Because of using harsh chemicals
Solution • Use alternate chemicals that can clean without harming
the monument
Problem • Washington Monument was falling apart
Analysis • WHY? Because the monument was 1st to turn on lights
Solution • Turn on lights 30 minutes later

65. Journey of Needs  Requirements

66. ● Each stakeholder speak unique language
○ Customers’ talk about outcomes
○ Sales team talk about deals, discounts, pipeline etc.
○ Engineering team talk is laced with technical
jargons
● Product Manager should communicate in the
language of the stakeholder
Each Stakeholder is Unique BDM
Customers
Sales Team
Support Team
Executives
Engineer
Product Manager

67. Need  Requirement
Need Requirement
Customers Product Manager Engineer

68. Need vs Requirement
Need
● A need is any customer business challenge or pain point or a
desired business outcome.
● Also referred to as job-to-be-done (JTBD).
● Need outlines the WHY
● Example – ISP (Internet Service Provider) is looking for
opportunities to monetize subscribers’ traffic
Requirement
● A requirement is a need when translated into a form
understandable by the engineering team.
● Requirement outlines WHAT
○ Functional spec to implement the need describes the HOW.
● The PRD should contain both WHY and WHAT.
● Example – Outlines specific features or solutions when
added to the product will facilitate ISPs to monetize their
subscribers’ traffic

69. Context of Requirement
Lots of possibilities… But, which is the RIGHT SOLUTION?
Context is required to determine the RIGHT SOLUTION
What is a context?
Context defines the circumstances that form the setting for a
need
How to derive contexts? Five Ws and a H
• WHY?
• WHAT?
• WHEN?
• WHO?
• WHERE?
• HOW?
Need? – Shopping Cart

70. Five Ws and a H
The actual purpose of the requirement?Why
What would customers accomplish?What
When would customers use itWhen
User Personas?Who
Where do customers use it?Where
How do customers desire to use it?How

71. Formulating Vision, Objectives, and Strategy

72. Prioritization of Product Requirements
Identifying the right set of requirements that fit within the framework of product purpose and yet has the potential
for collectively accomplishing product objectives
Objective

73. Where do we start?
Tangible goals i.e. OKRs (Objectives and Key Results)
● Increase in market cap
● Expansion into new markets (aligning to market trends)
● Growth in sales, revenues and margins.
● Addition of new technology (aligning to technology trends)
What is the core belief of the Organization
What is the true purpose and reason behind creation of
products?
What is the future that the Organization is intending to create?
Product Vision
Product Purpose aka Product Principles Product Objectives
Outlines the path to accomplish product objectives within the boundaries of product purpose
E.g. Introducing new products, altering existing products, targeting new markets/segments, launching new marketing campaigns etc.
Product Strategy
Moving target – In accordance with the product lifecycle stages

74. Understanding Lay of the Land
Know your Industry
Know your customers
Know your competition
Know your technology

75. Know Your Industry
● How industry has progressed until now?
● What has caused transformation of the
industry in the past?
● What might potentially transform the
industry in the future?

76. Know Your Customers
● How did customers needs and behaviours
change until now?
● What new customers could get added to the
target segment?
● What emerging technologies could trigger
changes in customers needs and
behaviours?

77. Know Your Competition
● What is the current state of the competition?
● Who are the prominent players? What will be
their direction going forward?
● Are there any new players that can be a
potential threat?

78. Know Your Technology
● How has technology progressed over the
last few years?
● Which emerging technology has the
potential to transform the industry?
● What new outcomes can emerging
technology deliver to disrupt the industry?

79. Understanding Lay of the Land
Know your Industry
Know your customers
Know your competition
Know your technology
Anticipate the overall
direction of the market
in 2 – 3 years
Analyse strengths,
overall position of the
market and competition.
Later, define your
direction

80. Outline Product Vision and Strategy
Product Vision
Product Purpose (Customer Centric) Product Objectives (Organization Centric)
- What is your belief?
-
-
-
- What is your vision for the product in the future? Market leader
or niche player?
-
-
-
Product Strategy
- What is the path to accomplishing the product vision?
-

81. Prioritization of Product Requirements
Objectives  Strategy  Roadmap

82. Product Objectives  Strategy Customer Value
Scenario – Enterprise IoT Product for Retail Stores
● Product Objectives – Customer Acquisition, Revenue
● Strategy – Outlines how to accomplish product objectives (measurable goals) – Expansion into new markets, new
business models (SaaS), new channels (Cloud), etc.
○ Translate objectives into sub-goals
○ Derive 3-month, 6-month and 12-month plan to accomplish those sub-goals
● Customer Value – Identify value when delivered in the product will help accomplish sub-goals (e.g., expand to new
markets, migrate customers to new business models and channels, etc.)
Market
Expansion
New
Channels
(Cloud)
New
Business
Models
3M 6M 12M

83. Focus on Customer Value… Not on Objectives
Product Objectives are by-product of delivering right customer value
So… Focus on delivering the RIGHT CUSTOMER VALUE
Product
Roadmap
Customer
Value
Product
Objectives
Prioritize Requirements
Accomplish

84. Think Long-Term, Act Short-Term
T + 12M
Release IV.
Market Expansion
T + 9M
Release III
Market Expansion
T + 6M
Release II
New Channels (e.g. Cloud)
T + 3M
Release I
New Business Models
Product Objectives aka
Goals
1. Customer Acquisition
2. Revenue Increase
Each release focus on delivering some customer value that can accomplish sub-goal
Customer value delivered in each release provides the foundation for a THEME
Cumulative value delivered by subsequent release accomplishes products objectives

85. Product Objectives vs Customer Value
Scenario – IoT product for B2B Retailers
● List ‘Product Objectives’ in the order of priority
● List ‘Customer Value’ in the order of their ability to accomplish product objectives
● Accomplish 1 or 2 customer values in each release
Product Objectives Customer Value
1. Customer Acquisition
2. Revenue
1. Omni Channel Experience
2. Customer Insights
3. Grab and Go
4. Cost Reduction
5. Search my Store

86. Identification of Product Attributes
● Identify product attributes - Tangibly measure the ability of a feature to deliver the chosen customer value
● Assign weights to each attribute (in %) depending on their relative importance to deliver customer value
● Don’t pick more than 5 attributes – Otherwise, it is tough to quantify the ability of each feature to deliver customer
value
Customer Value – Omni Channel Experience and Insights
Product Attributes Attribute Weights (in %)
Notifications 10
Sensors, Beacons 35
Personalization 15
Customer Insights 25
User Experience 15

87. Product Prioritization Methodology - Scorecard

88. A Quick Recap
Scenario – IoT product for B2B Retailers
Product Objectives Customer Value
1. Customer Acquisition
2. Revenue
1. Omni Channel Experience
2. Customer Insights
3. Grab and Go
4. Cost Reduction
5. Search my Store
Customer Value – Omni Channel Experience and Insights
Product Attributes Attribute Weights (in %)
Notifications 10
Sensors, Beacons 35
Personalization 15
Customer Insights 25
User Experience 15

89. Scorecard Methodology – Assign Value
● Measure each feature relatively on a scale of 1-10 against each attribute.
● 10 indicates that the feature has a higher impact on the corresponding attribute
Attributes Notifications Sensors,
Beacons
Personalization Insights User
Experience
Feature1 7 10 9 9 8
Feature2
Feature3
…
…
FeatureN

90. Brainstorming
• Multiple PMs manage most enterprise products
• Avoid unduly importance given to HIPPO (Highest Paid Person’s Opinion)
• Adds pluralism of thoughts ensuring appropriate evaluation of each feature
• Establishes transparent guidelines for prioritizing features
WHY?
• Ensures commonality of product purpose, objectives, and strategy among participants
• Discuss, debate and argue among PMs on the ability of each requirement to deliver customer value
• Challenge others viewpoint and be ready to be challenged
• Engage in dialogue and aim for collective good, not for individual wins
• Facilitated and moderated by a Lead PM
HOW?

91. PM – Engineering Collaboration
● Outline ‘WHAT’ and ‘WHY’ of each requirement
● Involve Engineering team earlier to provide a big picture view
● Outline the overall product direction and how it is influencing the prioritization process
● Instil a sense of ownership to deliver the right product and not just delivering it right
● Every engineer should be aware of why the product does, what it does

92. Scorecard Methodology – Total Value
● Multiply each value by the weights of corresponding attributes
● Repeat the process for every feature
Attributes Notifications Sensors,
Beacons
Personalization Insights User
Experience
Total Value
Feature1 7 * 10 10 * 35 9 * 15 9 * 25 8 * 15 90
Feature2
Feature3
…
…
FeatureN
+ + + + =

93. Scorecard Methodology - Cost
● Cost is the effort in relative terms to build each feature
● Cost is measured in a scale of 1-100 in relative terms and not in
absolute terms
● Identify a feature that consumes most man-months or man-weeks –
Tag the cost of that feature as 100
● Measure the cost of every other feature proportionally
● Assume that the max man-weeks of Feature3 is 15 and the man-weeks
of Feature2 is 6, then the cost of Feature 2 is measure through ratios –
15 : 6 = 100 : ?
Total
Value
Cost
Feature1 90 70
Feature2 70 40
Feature3 40 100
Feature4 35 25
Feature5 90 15
Feature6 60 80
Feature7 60 25
Feature8 90 70

94. Technical Debt
● Quick fixes accumulate technical debt
● Technical debt is a cost, add it to the cost of the corresponding
feature
● Identify cost vs. benefit analysis to rationalize the
accumulation of technical debt
● Accumulation of technical debt is catastrophic – Cost
outweighs the benefit in the long run
● Never exceed technical debt beyond the tolerance level
Tolerance
Level

95. Cost vs Value – Prioritization Graph
● Highly Likely – High Value, Low Effort. Low hanging
items on the roadmap. Definite YES
● Most Likely – High Value, High Effort. Deliver if they
are sustainable delighters or differentiators
● Less Likely – Low Value, Low Effort. Deliver if they are
only basic features
● No – Low Value, High Effort. Strictly NO

96. Total
Value
Cost Absolute
Value
Stack
Rank
Feature5 90 15 6.00 1
Feature7 60 25 2.40 2
Feature2 70 40 1.75 3
Feature4 35 25 1.40 4
Feature1 90 70 1.30 5
Feature6 60 80 0.75 6
Feature8 20 40 0.50 7
Feature3 40 100 0.40 8
Scorecard Technique – Stack Ranking
● The absolute value is the ratio of cost to total value
● Stack rank in descending order of absolute value
● As expected – Features in ‘HIGHLY LIKELY’ category –
F5, F7 and F2 are ranked TOP. Features in ‘NO’
category – F3 is ranked at the BOTTOM
● But F4 in ‘LESS LIKELY’ category is ranked above F1
in ‘MOST LIKELY’ category.
● Use stack rank only as a REFERENCE

97. Right Prioritization Model?

98. Is Scorecard Methodology Ideal?
What works
● Ensures alignment of every stakeholder on
○ Product Purpose
○ Product Objectives
○ Product Strategy
○ What value to deliver to customers and
○ Finally, to quantify the ability of each feature to deliver the desired value
● Provides a rational view to prioritization of product features
What does not work
● Works best only if there is absolute clarity on what value to deliver to customers
● Purely left-brain approach but prioritization is a combination of left-brain and right-brain
● Features to validate new outcomes in alignment with technology trends and identifying next market shifts will not
get prioritized
● Basic features that customers expect will never score high on value index

99. When to use Scorecard Methodology?
● For alignment of every stakeholder on a commonality of
○ Product Purpose
○ Product Objectives
○ Product Strategy
● Traditionally there are 3 categories of requirements
○ Short-Term - Capture prevalent opportunities
○ Near Long-Term - Identify emerging opportunities
○ Long-Term - Anticipate market shifts
● Use it only on short-term requirements that have absolute clarity on what value is delivered to customers
● Split the roadmap to prioritize each category separately
● Never use it as THE METHODOLOGY

100. Kano Model
Basic
● Features that customers expect to exist in a product
● All competitors deliver it
● Points of parity
Performance or Satisfiers
● Good to have features
● Increase customers satisfaction and excitement
Delighters
● Points of difference
● Excites or delights customers
● Deliver sustainable delighters. Otherwise, they will soon become ‘BASIC’

101. As always, there never exists the RIGHT MODEL
Scorecard works best to create an alignment of product objectives, objectively measure the value delivered by each
feature
Kano in comparison works best to identify delighters and basic features
Prioritization of product feature is entirely not a science… It does not hurt to use both the methodologies
Nevertheless… Kano and Scorecard cannot balance short-term and long-term priorities
Ideal approach is to categorize requirements and adopt separate prioritization techniques for each category
What is the Right Model?
But what are those other categories… How to categorize them?

102. Categorization of Product Requirements

103. Categorization of Requirements – McKinsey Model
● Tactical - Run the business
● Strategic - Grow the business
● Disruptor - Transform the business

104. S-Curve – Disruption Cycle
Strategic
Disruptor

105. Categorization – How To?
Tactical Strategic Disruptor
Scope
• Focus on addressing
existing business
challenges
• Product growth in near
long-term
• Emerging opportunities –
Delivering differential
outcome embracing
technology
advancements.
• Anticipate market shifts
• Opportunities with
potential to disrupt the
market
• Validate next big ideas
Customer Value
• Absolute clarity • Partial clarity
• Hypotheses to validate
exists
• No clarity
• Rigorous cycle of build,
measure and learn
Duration
• Short-term • Near Long-term • Long-term
Outcome
• Steady flow of revenues • Capture growth and
extend the lifetime of the
products
• Beat inflection point

106. Connecting the Dots
Identifying
Needs
Understanding
Needs
Tactical
Discovering
Needs
Customer
Needs
Strategic
Market Needs
Disruptor

107. Ratio of Each Category – Ideal Scenario
Tactical
Strategic
Disruptor

108. Ratio of Each Category vs Product LifeCycle
Growth - Focus on
evolving business
challenges -
Tactical + Strategic
P-M Fit - Focus on
current business
challenges – Mostly
Tactical
Validate next big
ideas
Tactical + Strategic +
Disruptor
Optimize the
product – Re-align
resources to new
product – Only
Tactical
Harden the product
– Only Support

109. Strategic Requirements - Examples
Started with a single blade
Extended the product line adding more blades and new features

110. Disruptor Examples – Rental to Streaming

111. Inflection Point – Seizing the Opportunity

112. What is an Inflection Point

113. Why does an Inflection Point Important
• Inflection point gives rise to new normal
• Old ways of doing business become irrelevant
• Product line perishes unless it adapts to new ways of doing business
• Ability to beat inflection points determines whether Organization is
‘The Disruptor’ or ‘The Disrupted’
• The faster adoption rate of new technology

114. ‘The Disruptor’ or ‘The Disrupted’

115. Evolution of Music Industry
No one company has dominated
successive era of technology
transition

116. Why does Incumbents Fail?
1. Risk of cannibalization
2. Re-alignment of resources
3. Baggage of existing customers
4. Failing to adapt
5. Short-sighted and arrogance
Addressed through
roadmaps

117. What has caused Disruption?
• Technology is only an enabler
• Outcomes centred around customer needs have caused disruption
• Never validate TECHNOLOGY… Validate OUTCOMES with prospective customers
• UBER, AIRBNB and AMAZON disrupted by delivering unique OUTCOMES embracing TECHNOLOGY
Never fall in love with technology,
fall in love with problems
Technology sans OUTCOME is no
good for anyone

118. Beating Inflection Point – Roadmap Strategy

119. New Outcomes at Inflection Point
Birth of new outcomes
displacing older products at
Inflection point
Roadmap Strategy
Conceptualize, Validate and
Increase Adoption of Newer
Outcomes

120. Roadmap Strategy - Conceptualize, Validate and Increase Adoption of Newer Outcome
• Take small and substantial steps
• Don’t adopt a herd mentality
• Choose lighthouse customers
• Measure the adoption rate
• Trigger transition of customers to newer outcomes. Realign resources
• Newer outcomes with the potential to disrupt are mostly delivered by extending the product line
Systematically re-align and re-prioritize resources to deliver newer OUTCOMES, validate them and increase
adoption without impacting REVENUES
Objective

121. Small and Substantial Steps
• Focus on identifying the right problem
• Create choices and converge on a choice for the problem and the solution
• Adapt lean practices to validate the solution
Identify the right problem and the right solution
Spend no more than 10% of your resources to eliminate uncertainties and identify the right solution
Objective

122. Do Not Adopt Herd Mentality
• Herd Mentality is riskier - Everyone is testing waters
• None is aware of what customers need
• Uncertainty in markets, technology and outcomes
• Do not panic
• New outcomes do not cause disruption immediately
• Always rationalize why you are doing, what you are doing
Disruption
occurs here

123. Lighthouse Customers
• Light house customers are your learning laboratory
• For eliminating uncertainties around market, technology and outcomes
• Pick your lighthouse customers who are
• Trend setters and thought leaders
• Early adopters of innovations that could shape the industry
• Rest of the industry keenly observe them to follow
• Revenues are never the criteria for selecting lighthouse customers
• Priority in the order of product market fit, growth and revenues

124. Be Quick to Discard or Pivot
• Not every idea works
• Be nimble – To quickly validate ideas
• Be data-driven
• Do not irrationally stick to an idea until its get too late
• Never be afraid to fail – Pivot is not a failure, it is a learning

125. Measure Adoption
Disruptions occur at the convergence of multiple factors
• Affordability of technology
• Increasing performance curve of technology
• Evolution of an eco-system
• Viable business model for newer outcomes
• Increasing number of customers embracing newer outcomes
Adoption is to measure the convergence of above factors
Foresee signs of convergence and accelerate them to cause disruption
Objective

126. Trigger Transition of Customers to New Outcomes
After achieving P-M fit and as adoption increases
• Prioritize only ‘MUST HAVE’ features of older outcomes
• Prioritize features of older outcomes that deliver immediate value
• Prioritize features that can aid customers to migrate to newer
outcomes
• Prioritize features that can stabilize older outcomes
• Prioritize more features of newer outcomes
Excite customers to embrace newer outcomes by delivering more value
Re-align resources to newer outcomes
Objective

127. Measuring Efficacy of Product Roadmaps

128. Measuring Product Objectives aka Goals
● Feature usage metrics - Measure correlation between customers value and product objectives
Product
Roadmap
Customer
Value
Product
Objectives
Prioritize Requirements
Accomplish

129. Feature Usage Metrics
● Pick top stack ranked features in last few releases
● Identify their usage metrics
● Top stack ranked features presumably deliver more value to customers and should be used more
● Understand reasons for top-ranked features not utilized appropriately
○ Are customers aware of those features?
○ Do those features address real needs?
○ Do those features address the need appropriately?
○ Do those features deliver needs as desired by customers i.e., whether the outcomes are desired by customers?
○ Finally, what new outcomes will be embraced by customers?

130. Intercom Model – Feature Audit
Top stack ranked
features should
exist in this zone
Increase adoption
or kill top stack
ranked features in
this zone
Source: https://www.intercom.com/blog/before-you-plan-your-product-roadmap/
Strategize to hook
customers more to
features in this zone

131. Conjoint Analysis
According to Wikipedia - 'Conjoint analysis' is a survey-
based statistical technique used in market research that
helps determine how people value different attributes
(feature, function, benefits) that make up an individual
product or service

132. A Quick Recap (Product Objectives vs Customer Value)
Product Objectives Customer Value
1. Customer Acquisition
2. Revenue
1. Omni Channel Experience
2. Customer Insights
3. Grab and Go
4. Cost Reduction
5. Search my Store
Product
Roadmap
Customer
Value
Product
Objectives
Prioritize Requirements
Accomplish

133. Conjoint Analysis
Organization perception of what customers values vs What customers really value
Search my Store
(10%)
Omni-Channel Experience (35%)
Cost Reduction (15%)
Customer Insights (25%)
Grab & Go (15%)
Organization Perception Customer Perception

134. How to say ‘NO’?
Yet, Make Customer Happy 

135. Saying ‘NO’ to a Customer – 10 Step Process
1. Understand the requirement
2. Evaluate type of requirement
3. Validate the requirement – Alignment with product purpose
4. Fitment with the current strategy
5. Is it generic or custom requirement
6. Analyse the business impact
7. Evaluate alternate proposals
8. Any additional requirements
9. Negotiate and finalize
10. Lookback
It is not a formulae or a silver bullet… It is a thought process

136. Step 1 – Understand the Requirement
● Understand why they require what they require
● Always remember - What customer say they need is entirely different from
what they actually need
● Understand the real need using 5Ws
● Understand the context of the requirement using 5Ws and 1H

137. Step 2 – Type of Requirement
Scenario 1 - Existing capability – Not delivering desired outcome
○ Why has the feature not met customers expectations?
○ What has gone wrong during the process of understanding and gathering requirements?
○ Is the requirement has to be genuinely addressed? Will it increase the adoption of the feature?
• GO Ahead and commit in the roadmap without altering existing items
○ Is existing outcome acceptable to most customers and improving has no positive impact on adoption? Check for alternatives
and convince the customer. Probably, customer is too demanding.
Scenario 2 - Extension to an existing capability to deliver additional outcomes
Scenario 3 - New request
○ Proceed to next step

138. Step 3 – Validate the Requirement
● Is it a valid or a reasonable requirement?
● Does it fit within the overall purpose of the product?
○ Often customers expect the product to do stuff outside its boundary
○ Example – Expecting a concierge service in a B&B hotel
Scenario 1 - Not a valid requirement
● Elaborate the rationale on why the product cannot deliver their asks
● Educate the customers about what the product is expected to deliver and what it is not expected to deliver
● Never discard any requirement abruptly – Park aside and analyse what competitors are doing
○ Probably, engage a 3rd party to provide concierge service
Scenario 2 – Valid requirement
● Proceed to the next step

139. Step 4 – Fitment with the Current Strategy?
● Does the requirement fit within the current plans
● Can the requirement deliver customer value pre-determined during the prioritization process
● There is always a possibility not to discover all the right set of requirements
Scenario 1 – Fits with current strategy
● Add to the product roadmap and share the roadmap with the customer
● Analyse why the requirement was not discovered earlier
Scenario 2 – Do not fit with current strategy
● Proceed to the next step

140. Step 5 – Generic or Custom Requirement
● Is it a custom requirement or applicable to other broader segment of customers?
● Does the requirement have a domino effect?
● What is the cost involved in delivering the requirement?
● Any prior history of product requests deviating against the overall direction of the product?
Step 6 – Analyse the Business Impact
● What is the business impact of not delivering the requirement?
● What is the impact of delivering the requirement to the customer?
● Understand the impact of both the scenarios
● Is the business impact on the customer immediate or in the future?

141. Step 7 – Alternate Proposals
● Identify alternate ways to address customer requirement
● Aim for an optimal solution, not necessarily an ideal solution
Step 8 – Additional Requirements
● Check if there are any other additional requirements from the same customers
● Identify the business criticality of those requirements vs. the requirement under contention
● Is it a WRONG customer? Does the customer belong to the target segment?

142. Step 9 – Negotiate
● Leverage information sought in step 1 – 7 to identify the right course of action (YES or NO?)
● Evaluate both short-term gains and long-term gains of every possible outcome
● Identify a WIN–WIN situation for the customer and the product
● Rationalize your decision with the customer
● Final decision should be unambiguous
● Not worth saying YES to a customer at the cost of other customers
● Finally, it is sometimes worth forgoing a WRONG customer
Step 10 – Lookback
● The process is not just to evaluate whether to say ‘YES’ or ‘NO’.
● The process is also about gathering more insights
● It also offers feedback back to Product Managers

143. Mistakes to Avoid During Prioritization

144. Mistakes to Avoid
Common mistakes of a Product Manager during the prioritization
process
1. Using revenue as the only criterion
2. Preferential treatment to Customers with a loud voice
3. Concurring with the engineering team
4. PM believes those requirements add value to customers
5. Always putting the user first over the buyer
6. Release sans a common theme
○ Inability to articulate the benefits of a release in a single tweet
7. Yielding to the pressures of the sales team
8. It’s low effort – Let’s deliver it
○ Cost to the feature = development cost + maintenance cost
9. Beware of domino effect
○ One requirement leads to a chain of related requirements

145. Revenues are never the criteria for prioritizing features.
• Revenues are always outcome
of delivering the right customer
value
• Fitment to product purpose and
strategy

146. Do no let customers with a loud voice hijack the product roadmap

147. Concurring with engineering team and toeing their line

148. PM believes few requirements add value to customers
I Know

149. Always putting the user first over buyer
Buyer vs
User
Personas

150. Release sans a common theme

151. Yielding to pressures of sales team

152. Low effort – Let’s do it. We often neglect maintenance cost
Source: https://www.mindtheproduct.com/2017/07/enter-matrix-lean-prioritisation/
It takes a week to
develop the
feature, let us
deliver it

153. Be wary of domino effect

154. Roadmap Tips
● Never plan for 100% of the capacity
○ If your engineering team can deliver 10 features, plan your roadmap with 8 features
○ Allow room for changes
● Constantly revisit your roadmap
○ Ensure constant alignment among Requirements Customer Value Product Objectives
○ Customers might not appreciate too many changes as well
● Roadmap items in immediate future should be deterministic and less deterministic as it heads farther into
future
● Always add a disclaimer stating that the items in the roadmap are prone to changes
● Content is king. Yet, make roadmap visually appealing
● Discovering and understanding of needs is a continuous process

155. Thank You
Connect me @emurali or
murali.erraguntala@gmail.com
https://www.linkedin.com/in/muralierraguntala/

156. THANK YOU
See you soon