Ce diaporama a bien été signalé.
Nous utilisons votre profil LinkedIn et vos données d’activité pour vous proposer des publicités personnalisées et pertinentes. Vous pouvez changer vos préférences de publicités à tout moment.

Product roadmap 101

531 vues

Publié le

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.

Publié dans : Business

Product roadmap 101

  1. 1. Product Roadmap 101 Translating Product Strategy into Product Roadmap for Enterprise Products
  2. 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. 3. Product Manager needs a roadmap
  4. 4. Most Product Managers build Good Product Roadmaps … but … to build Great Product, we need Great Product Roadmap
  5. 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. 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. 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. 8. Course Outline
  9. 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. 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. 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. 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. 13. Fundamentals of Product Roadmap
  14. 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. 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. 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. 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. 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. 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. 20. Product Vision, Strategy and Roadmap
  21. 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. 22. How often did you care about alignment to Product Vision?
  23. 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. 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. 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. 26. Similar Companies, Similar Products… But, Different Principles
  27. 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. 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. 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. 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. 31. Creation of Product Backlog
  32. 32. Product Backlog vs Prioritization Product Backlog Prioritization x.y release x.z release Product Objectives We PRIORITZE what EXISTS in product backlog
  33. 33. Process to gather exhaustive customers’ needs
  34. 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. 35. Dilemma?
  36. 36. But… How do we gather exhaustive set of customer needs?
  37. 37. Product Backlog – Accumulating Needs Needs not realized by customers Needs recognized by customers Discovering Needs Understanding Needs
  38. 38. Understanding of Customers’ Needs
  39. 39. Understanding Customer Needs – Why? Understanding customers is delivering what they require and not what they ask for
  40. 40. Why to deliver what customers need and not what they ask for?
  41. 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. 42. Breakaway With Tradition
  43. 43. Never ask customers what they need, always always always ask why they need
  44. 44. Understanding Customer Needs – How? Listen to understand Empathy Map Power of Why
  45. 45. Need for Empathy Map? What people say, what people do, and what they say they do are entirely different things Margaret Mead
  46. 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. 47. Discovery of Needs
  48. 48. Discovery of Needs – Why?
  49. 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. 50. Discovery of Needs – Customer Focus Know your customers better than they know about themselves Anticipate what they might require in short-term
  51. 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. 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. 53. Collaborative Gathering of Needs
  54. 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. 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. 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. 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. 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. 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. 60. Five Ws – Requirements Gathering Tool
  61. 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. 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. 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. 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. 65. Journey of Needs  Requirements
  66. 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. 67. Need  Requirement Need Requirement Customers Product Manager Engineer
  68. 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. 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. 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. 71. Formulating Vision, Objectives, and Strategy
  72. 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. 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. 74. Understanding Lay of the Land Know your Industry Know your customers Know your competition Know your technology
  75. 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. 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. 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. 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. 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. 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. 81. Prioritization of Product Requirements Objectives  Strategy  Roadmap
  82. 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. 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. 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. 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. 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. 87. Product Prioritization Methodology - Scorecard
  88. 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. 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. 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. 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. 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. 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. 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. 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. 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. 97. Right Prioritization Model?
  98. 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. 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. 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. 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. 102. Categorization of Product Requirements
  103. 103. Categorization of Requirements – McKinsey Model ● Tactical - Run the business ● Strategic - Grow the business ● Disruptor - Transform the business
  104. 104. S-Curve – Disruption Cycle Strategic Disruptor
  105. 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. 106. Connecting the Dots Identifying Needs Understanding Needs Tactical Discovering Needs Customer Needs Strategic Market Needs Disruptor
  107. 107. Ratio of Each Category – Ideal Scenario Tactical Strategic Disruptor
  108. 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. 109. Strategic Requirements - Examples Started with a single blade Extended the product line adding more blades and new features
  110. 110. Disruptor Examples – Rental to Streaming
  111. 111. Inflection Point – Seizing the Opportunity
  112. 112. What is an Inflection Point
  113. 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. 114. ‘The Disruptor’ or ‘The Disrupted’
  115. 115. Evolution of Music Industry No one company has dominated successive era of technology transition
  116. 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. 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. 118. Beating Inflection Point – Roadmap Strategy
  119. 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. 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. 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. 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. 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. 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. 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. 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. 127. Measuring Efficacy of Product Roadmaps
  128. 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. 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. 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. 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. 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. 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. 134. How to say ‘NO’? Yet, Make Customer Happy 
  135. 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. 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. 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. 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. 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. 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. 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. 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. 143. Mistakes to Avoid During Prioritization
  144. 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. 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. 146. Do no let customers with a loud voice hijack the product roadmap
  147. 147. Concurring with engineering team and toeing their line
  148. 148. PM believes few requirements add value to customers I Know
  149. 149. Always putting the user first over buyer Buyer vs User Personas
  150. 150. Release sans a common theme
  151. 151. Yielding to pressures of sales team
  152. 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. 153. Be wary of domino effect
  154. 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. 155. Thank You Connect me @emurali or murali.erraguntala@gmail.com https://www.linkedin.com/in/muralierraguntala/
  156. 156. THANK YOU See you soon