O slideshow foi denunciado.
Utilizamos seu perfil e dados de atividades no LinkedIn para personalizar e exibir anúncios mais relevantes. Altere suas preferências de anúncios quando desejar.

Pragmatic Approach for Building GREAT Product Roadmap

4.056 visualizações

Publicada em

The eBook is now translated into a course and live on Udemy. Check http://productguy.in/udemy-course/ for more details.

GREAT product roadmap evolves from the product vision and product strategy. Further, it acts as one of the single most important documents that provide a unified and consistent view of where the product is heading to all the relevant 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. eBook attempts to define the approach to building GREAT product roadmap with product vision and strategy as its guiding principle.

Publicada em: Negócios
  • DOWNLOAD FULL. BOOKS INTO AVAILABLE FORMAT, ......................................................................................................................... ......................................................................................................................... 1.DOWNLOAD FULL. PDF EBOOK here { https://tinyurl.com/y8nn3gmc } ......................................................................................................................... 1.DOWNLOAD FULL. EPUB Ebook here { https://tinyurl.com/y8nn3gmc } ......................................................................................................................... 1.DOWNLOAD FULL. doc Ebook here { https://tinyurl.com/y8nn3gmc } ......................................................................................................................... 1.DOWNLOAD FULL. PDF EBOOK here { https://tinyurl.com/y8nn3gmc } ......................................................................................................................... 1.DOWNLOAD FULL. EPUB Ebook here { https://tinyurl.com/y8nn3gmc } ......................................................................................................................... 1.DOWNLOAD FULL. doc Ebook here { https://tinyurl.com/y8nn3gmc } ......................................................................................................................... ......................................................................................................................... ......................................................................................................................... .............. Browse by Genre Available eBooks ......................................................................................................................... Art, Biography, Business, Chick Lit, Children's, Christian, Classics, Comics, Contemporary, Cookbooks, Crime, Ebooks, Fantasy, Fiction, Graphic Novels, Historical Fiction, History, Horror, Humor And Comedy, Manga, Memoir, Music, Mystery, Non Fiction, Paranormal, Philosophy, Poetry, Psychology, Religion, Romance, Science, Science Fiction, Self Help, Suspense, Spirituality, Sports, Thriller, Travel, Young Adult,
       Responder 
    Tem certeza que deseja  Sim  Não
    Insira sua mensagem aqui
  • Njce! Thanks for sharing.
       Responder 
    Tem certeza que deseja  Sim  Não
    Insira sua mensagem aqui

Pragmatic Approach for Building GREAT Product Roadmap

  1. 1. Pragmatic Approach for Building Great PRODUCT ROADMAP Translating Product Strategy into Product Roadmap Murali Erraguntala www.ProductGuy.in 2016 (2nd Edition)
  2. 2. Page | 1 www.ProductGuy.in Pragmatic Guide for Great PRODUCT ROADMAPPING Table of Contents TABLE OF CONTENTS...................................................................................................................... 1 TABLE OF FIGURES.......................................................................................................................... 3 INTRODUCTION .............................................................................................................................. 4 WHAT IS PRODUCT ROADMAP?.................................................................................................... 6 NEW PRODUCT ROADMAP.................................................................................................................. 8 FEATURE ROADMAP .......................................................................................................................... 9 WHAT IS NOT A PRODUCT ROADMAP?.................................................................................................. 9 WHY PRODUCT ROADMAP .......................................................................................................... 10 PURPOSE OF PRODUCT ROADMAP ............................................................................................. 11 PRODUCT MANAGER....................................................................................................................... 11 CUSTOMERS.................................................................................................................................. 11 ENGINEERING MANAGER ................................................................................................................. 12 SALES ........................................................................................................................................... 12 BUSINESS DEVELOPMENT MANAGER (BDM)....................................................................................... 12 INTERNAL ROADMAP VS EXTERNAL ROADMAP......................................................................... 13 REQUIREMENT VS NEED............................................................................................................... 16 CONTEXTOF REQUIREMENTS............................................................................................................. 17 FIVE WS ....................................................................................................................................... 18 DISCOVERY OF NEEDS .................................................................................................................. 20 DISCOVERING VS UNDERSTANDING REQUIREMENTS ............................................................................... 20 DISCOVER OF CUSTOMER FOCUSED NEEDS ........................................................................................... 20 DISCOVERY OF MARKET FOCUSED NEEDS.............................................................................................. 22 COLLABORATIVE DISCOVERY OF NEEDS – WHO CAN PARTICIPATE?......................................... 27 NEEDS FROM SUPPORT TEAM............................................................................................................ 28 NEEDS FROM ENGINEERING TEAM...................................................................................................... 30 NEEDS FROM SALES......................................................................................................................... 31 NEEDS FROM BDMS....................................................................................................................... 32 BASIC TENETS OF COLLABORATIVE DISCOVERY....................................................................................... 33 NEEDS FROM CONFLUENCE OF MULTIPLE MINDS ................................................................................... 34 IMPORTANCE OF ‘WHY’.................................................................................................................. 34 ABILITYOF PRODUCT MANAGER TO FACILITATE COLLABORATION............................................................. 35 CATEGORIZATION OF REQUIREMENTS – TACTICAL, STRATEGIC AND DISRUPTORS................. 37 TACTICAL...................................................................................................................................... 37 STRATEGIC .................................................................................................................................... 37
  3. 3. Page | 2 www.ProductGuy.in Pragmatic Guide for Great PRODUCT ROADMAPPING DISRUPTOR ................................................................................................................................... 39 PRODUCT OFFERING VS MARKET MATRIX ............................................................................................. 39 RATIO OF TACTICAL/ STRATEGIC / DISRUPTOR REQUIREMENTS IN ROADMAP....................... 41 INFLECTION POINT – SEIZING THE OPPORTUNITY...................................................................... 49 PERILS OF INFLECTIONPOINT............................................................................................................. 49 OPPORTUNITY –TO DISPLACE INCUMBENTS......................................................................................... 50 RISK – TO AVOID BEING DISPLACED .................................................................................................... 51 PRIORITIZATION OF PRODUCT REQUIREMENTS......................................................................... 58 IDENTIFICATION OF PRODUCTOBJECTIVES (AKA GOALS).......................................................................... 58 IDENTIFICATION OF PRODUCT ATTRIBUTES............................................................................................ 60 PRODUCT ATTRIBUTES VS PRODUCT LIFECYCLE..................................................................................... 63 SCORECARD TECHNIQUE - GUIDELINES................................................................................................ 64 BRAINSTORMING............................................................................................................................ 67 PM-ENGINEERING JOINT OPERATION................................................................................................. 68 COST VS VALUE .............................................................................................................................. 69 TECHNICAL DEBT............................................................................................................................ 74 WHY I DON’T ENTIRELY RELY ON SCORECARD METHODOLOGY?................................................................ 74 ACTIVITY VS TASKS.......................................................................................................................... 76 HOW TO PRIORITIZE SMALLER FEATURES.............................................................................................. 77 PRIORITIZATION OF DEFECTS VS REQUIREMENTS.................................................................................... 79 IDENTIFICATION OF FEATURES FOR FUTURE RELEASES ............................................................................. 80 LONG TERM PRODUCT ROADMAP –IS IT MANDATORY?.......................................................................... 81 DEADLY MISTAKES TO AVOID DURING PRIORITIZATION OF REQUIREMENTS.......................... 82 PRODUCT REQUIREMENT BACKLOG – HOW TO MANAGE......................................................... 87 RECORD NEEDS .............................................................................................................................. 87 NEEDS TRIAGE................................................................................................................................ 88 CATEGORIZE NEEDS......................................................................................................................... 89 REFINE NEEDS................................................................................................................................ 90 DRAFT THE PRD............................................................................................................................. 90 PRIORITIZE THE REQUIREMENTS......................................................................................................... 90 ORGANIZE BACKLOG........................................................................................................................ 90 MEASURE THE EFFICACY OF PRODUCT ROADMAP..................................................................... 92 PRODUCT OBJECTIVES (AKA GOAL) METRICS......................................................................................... 93 FEATURE USAGE METRICS................................................................................................................. 95 GAUGE THE MOOD – MEASURE THE PERCEPTION.................................................................................. 96 CUSTOMER HIJACKING THE PRODUCT ROADMAP – HOW TO AVOID....................................... 98 CONCLUDING THOUGHTS .......................................................................................................... 101 ANNEXURE A............................................................................................................................... 102
  4. 4. Page | 3 www.ProductGuy.in Pragmatic Guide for Great PRODUCT ROADMAPPING Table of figures FIGURE 1: WHY? WHAT? AND HOW? OF PRODUCT VISION, STRATEGY AND ROADMAP.......................7 FIGURE 2 - TIME TO ANNOUNCE ROADMAP......................................................................................14 FIGURE 3 - SHOPPING CART..............................................................................................................18 FIGURE 4 - CATEGORIZING REQUIREMENTS ......................................................................................38 FIGURE 5 - PRODUCT OFFERING VS MARKET.....................................................................................40 FIGURE 6: MCKINSEY 3 HORIZON FRAMEWORK................................................................................41 FIGURE 7: TECHNOLOGY HYPE CYCLE (SOURCE:GARTNER)................................................................46 FIGURE 8: ADOPTION CURVE AND MATURITY CURVE (SOURCE: GARTNER)........................................48 FIGURE 9: INFLECTION POINT...........................................................................................................49 FIGURE 10: ADOPTION RATE OF DEVICES IN US HOUSEHOLD.............................................................52 FIGURE 11: ADOPTION RATE OF PERSONAL COMMUNICATION DEVICE .............................................53 FIGURE 15 – PRODUCT PRIORITIZATION CYCLE..................................................................................60 FIGURE 12 - FEATURE VALUE VS EFFORT ...........................................................................................72 FIGURE 13: ORGANIZING PRODUCT REQUIREMENT BACKLOG ...........................................................88 FIGURE 14: CATEGORIZING REQUIREMENTS BACKLOG......................................................................91 FIGURE 15 – PRODUCT PRIORITIZATION CYCLE..................................................................................93 FIGURE 15 - PRODUCT ATTRIBUTES FEEDBACK LOOP.........................................................................94
  5. 5. Page | 4 www.ProductGuy.in Pragmatic Guide for Great PRODUCT ROADMAPPING Introduction GREAT product roadmap evolves from product vision and product strategy. Further, it acts as a single most important document that provides a unified and consistent view of where the product is heading to all the concerned stakeholders (Engineering Team, Sales Team, Account Team, Business Development Team, Sr. Management, Customers, and Partners). Product vision and strategy should provide a framework and guidance for the preparation of GREAT product roadmap, and it should be the overarching principle that governs the process of preparing product roadmaps. The process for the preparation of GREAT product roadmap involves a series of linear and nonlinear activities planned and executed meticulously by Product Manager. The process is also collaborative comprising of all the stakeholders either directly or indirectly involved with the product. The process triggers with the discovery of needs through broader understanding and anticipation of customer business challenges, pain points, and desired business outcomes. Discovery of needs is a never-ending activity and Product Manager periodically branches out a linear set of activities from discovery of needs to perform the following  Convert needs into requirements  Draft requirements into PRD (Product Requirements Document)  Categorize requirements into tactical, strategic, and disruptor categories  Identify percentage split for each of those categories  Socialize requirements with engineering team,  Derive metrics for prioritization of requirements using scorecard methodology and  Ruthlessly prioritize requirements balancing both short-term and long-term objectives in alignment with the product strategy. In addition, Product Manager should evaluate the efficacy of product roadmap and should provide a mechanism to reinforce the feedback back into prioritization process for effective and efficient prioritization of product requirements. When the industry is going through the cusp of enormous technological changes related to IoT (Internet of Things), Big Data, Mobility, Cloud, Virtualization etc., the role of GREAT product roadmap is indispensable for a successful technology transition. The
  6. 6. Page | 5 www.ProductGuy.in Pragmatic Guide for Great PRODUCT ROADMAPPING GREAT product roadmap plays a dominant role in forking out resources from the current product (aka Cash Cow) for validating the new technology. It does through applying lean techniques to eliminate uncertainties surrounding the application of new technology towards creating a better value for customers. GREAT product roadmap does it without affecting the revenues of existing products. Roadmap further plays a critical role during the technology shift from older product to newer prototype as new technology matures and old technology marches into sunset mode. When the older product is inching closer to the inflection point, the roadmap should systematically shift the revenues and resources from the older product to newer prototype while possibly accelerating the technology shift to reduce transition time. Rest of the eBook elaborates on aspects outlined above. Contents of this eBook were available as a series of blog posts on my blog (www.ProductGuy.in). I deeply appreciate your efforts to drop thoughts or comments on my blog or through email. The entire content is born out of my experiences of being a B2B (Business-to-Business) Product Manager for the hardware product, so there is a possibility of certain bias in the methodologies outlined in this eBook towards B2B products. A copy of the eBook is downloadable from www.ProductGuy.in/eBooks Happy Translating Product Strategy into GREAT Product Roadmap!!! Murali Erraguntala Blog| Email
  7. 7. Page | 6 www.ProductGuy.in Pragmatic Guide for Great PRODUCT ROADMAPPING What is product roadmap? The product roadmap is a plan that outlines a series of tactical steps in alignment with product strategy to push the product ahead in the trajectory of planned direction. Every product should have a vision that defines the purpose and reason for the existence of the product and where the product should be heading. The strategy would then define a path to get there by drafting a plan of action detailing how to get there. The strategy involves aspects related to both product and non-product (e.g. marketing campaigns, support, pricing etc.). Product roadmap captures part of the strategy related to the product. The product roadmap is a plan of action that reflects product strategy. Let me take a step back for further pondering upon what is product vision, product strategy, and product roadmap. How does each of them are interrelated? Product vision defines why the product exists - what is the single most important purpose both from the perspective of customers and organization that the product is intending to fulfill. Product Manager is often busy conceiving features that should be added to the product, but (s)he loses sight of the fundamental foundation upon which the product is built. The foundation that defines what organization believes in and the belief that dictates what product should stand for, why does it exists and what it is intended to achieve. Have you ever wondered what does great companies like Apple, Google, Facebook, Toyota, and Honda etc. believe in, are n’t their products direct reflection of what they believe. Therefore, every product should embody the beliefs and product vision should be a reflection of those beliefs. What does Apple believe in – Shall I state ‘Innovation, Simplicity and Building Great Products’. In the words of Tim Cook1 , following are the values that define Apple. We believe that we’re on the face of the Earth to make great products” We believe in the simple, not the complex” 1 Source: https://hbr.org/2012/04/its-not-what-you-sell-its-what
  8. 8. Page | 7 www.ProductGuy.in Pragmatic Guide for Great PRODUCT ROADMAPPING “We believe in saying no to thousands of products, so that we can really focus on the few that are truly important and meaningful to us” Are n’t all the products that Apple build and evolve revolve around the above stated beliefs? Often over time, what the product does, who are its target customers, what it intends to achieve for an organization (in terms of revenue, growth, market expansion etc.) can change. However, there will not be a change in what the organization believes in and how the belief dictates the way Organization build, evolve and design products, unless there is a change in the overall direction of the organization. What products does an Organization build and how does an Organization build those products are centered on the belief that defines the purpose behind its existence. Product strategy outlines the path to evolve the product during the course of its life cycle guided by the product vision. While the vision sets the overarching goal of where the product should head in accordance with the product purpose and product objectives (WHY?), strategy defines the patch to accomplish the product vision (WHAT?) and product roadmap defines the exact steps or procedures executed along the path to realize product vision (HOW?) Figure 1: Why? What? and How? Of Product Vision, Strategy, and Roadmap Product Vision Product Strategy Product Roadmap
  9. 9. Page | 8 www.ProductGuy.in Pragmatic Guide for Great PRODUCT ROADMAPPING “Product roadmap is a plan of execution that reflects how the product will be evolved both in short-term and in long-term in accordance with the product strategy. Product roadmap outlines the list of product requirements, solutions or new products planned to be released over a period of time that would precisely reflect the direction in which the product is heading” At the outset, product roadmap is definitely not a discreet list of features. It has a theme or purpose attached to it and delivery of items outlined in the product roadmap will contribute either directly or indirectly to the realization of product objectives and product purpose. New product roadmap As the name suggests, this roadmap will outline new products or platforms planned for launch in future. Duration of new product roadmap is long term (around 2 years, assuming new product introduction takes 12-18 months). If there is a plan to roll out successive products in the product line, then new product roadmap will generally span for 2-3 years. The actual duration of new product roadmap will primarily depend on the nature of the product (hardware or software), complexity of the product and duration to develop new products. The roadmap actually captures the timeline to build and roll out a full-fledged product for general availability and not just the beta version. Product roadmap for new product definitely goes beyond the MVP (Minimum Valuable Product). Product roadmap is definitely not a discreet list of features; it has a theme or purpose attached to it and delivery of items outlined in the product roadmap will contribute either directly or indirectly to the realization of product objectives
  10. 10. Page | 9 www.ProductGuy.in Pragmatic Guide for Great PRODUCT ROADMAPPING Feature roadmap Feature roadmap would contain product requirements addition to an existing product line. The product requirements could be segregated based on themes (usability, performance, technology, new solutions, etc.) or market segments. The duration of feature roadmap will be utmost 12-18 months in general. The duration essentially depends on the timeline of each release. I generally suggest capturing utmost 3-4 releases in the roadmap. If it is agile development methodology with a quarterly release window, then feature roadmap could span for a year. In the case of new product just launched into the market, it might be tough to prepare a long-term roadmap especially if the product is addressing a new or emerging market and the customer needs are not lucid. The duration of the feature roadmap is therefore dependent on the volatility of the market in addition to several other factors. What is not a product roadmap? The product roadmap is definitely not a committed plan. It evolves with changes in business, customer needs, and other related factors. It is not prepared in haste and definitely not in a reactive mode, product roadmaps are prepared pro-actively to set the direction for the product. The addition of features to the product roadmap does not happen randomly to fill the roadmap. Instead, Product Manager adds features to the product roadmap after careful evaluation of roadmap under the below mentioned parameters and prioritized accordingly: 1. How it helps customers’ business 2. How it helps in achieving product objectives 3. How it helps in realizing product purpose 4. How it is aligned with product strategy ‘The purpose of roadmap’ and ‘why roadmap is required’ might throw lot better perspective of what constitutes a product roadmap and what does not constitute a product roadmap.
  11. 11. Page | 10 www.ProductGuy.in Pragmatic Guide for Great PRODUCT ROADMAPPING Why product roadmap Lack of product roadmap is akin to the famous quote of Benjamin Franklin If you fail to plan, you are planning to fail” Lack of product roadmap would render product directionless and Product Manager is possibly providing an opportunity to all the stakeholders to steer the product in different conflicting directions without any purpose or objective. Without any appropriate approach to building product roadmaps, every product release will contain bug fixes and a small set of insignificant features or features that require less effort. There is no immediate impact, but slowly and steadily the sales would decline, the rate of new customer acquisition dwindles, the gap widens with competitor products, customers whine about the lack of features that really excite them and they lose confidence in further investing in the product. It is highly crucial that product roadmap has to be driven and prepared meticulously by Product Manager in consultation with all the relevant stakeholders (Customers, Engineering Team, Sales, BDM etc.) in a compelling manner such that the product roadmap reflects product growth strategy. Please be aware that product roadmap is just a plan and not a commitment, so Product Manager should add necessary disclaimers to product roadmap providing sufficient indications that it is prone to changes. Lack of product roadmap is akin to the famous quote of Benjamin Franklin - ‘If you fail to plan, you are planning to fail’
  12. 12. Page | 11 www.ProductGuy.in Pragmatic Guide for Great PRODUCT ROADMAPPING Purpose of product roadmap The product roadmap apart from providing a blueprint of where the product is heading and how the product will evolve over the next few years, they also serve a specific purpose to various stakeholders and I have highlighted those purposes explicitly in this section. Each of those purposes further emphasizes the importance of product roadmap and why it is essential for Product Manager to have an exclusively focus on preparing product roadmap. Product Manager - Product roadmap preparation as a regular activity pushes the Product Manager to explicitly outline product purpose and consciously rethink about product objectives. Later outline the product growth strategy to accomplish product objectives based on the findings from competitive, customer and market analysis. Preparation of product roadmap as a well-defined process will therefore consciously let Product Manager ponder upon the product growth strategy to accomplish product objectives. Typically, the preparation of product roadmap should be a top-down activity but in the event of no conscious effort by Product Manager to construct product vision and strategy, the process to the definition of product roadmap as outlined in this eBook will allow Product Manager to explicitly focus on product vision and strategy. Product Roadmap is also an important document that can aid Product Manager to reason out or justify the budget requirements for product development. Customers – Primarily, product roadmap provides confidence that the product is evolving. Secondly, it indicates the direction in which the product is heading. The information is critical for customers to understand whether the evolution of the product is in alignment with their business objectives. Thirdly, it provides timelines and list of product requirements available in each product release. Fourthly, customers can plan their business (expansion, launch of new services etc.) accordingly. Finally, roadmap when shared with customers regularly eliminates conflicts or ambiguity between requirements expected by customers and requirements delivered in future releases. On the 4th point, many of you might question if product roadmap is just a plan, how customers could plan their business in accordance with the product roadmap. When I talk about the roadmap, I am talking about a timeframe of 18-24 months and I generally split the roadmap into multiples pieces depending on the duration of each release. The probability that the contents of the product roadmap will change is relatively higher as
  13. 13. Page | 12 www.ProductGuy.in Pragmatic Guide for Great PRODUCT ROADMAPPING we inch closer to the end of 2nd year. Nevertheless, the initial contents (0-6 months and 6-12 months) do not change much and customers can use that data for half-yearly or yearly planning. Under certain exceptional conditions, Product Manager sells the product to customers promising some set of features. In such scenario, the roadmap will act as a commitment to deliver the promised features within the committed timeframe. Failing to do so might attract penalties (depending on the clause signed with a customer). Engineering Manager – Even though product roadmap would have been derived in consultation with the engineering team, it provides direction to engineering manager on how to align his/her resources to deliver requirements added to the product roadmap. In the case of new technology introduction or new product development, engineering team can also fathom about the need for new competencies accordingly can plan to either build or acquire those competencies. Sales – Sales team can use the roadmap to close deals, to retain existing customers and to attract prospective customers because roadmap provides the following inherent advantages:  Product roadmap, when planned and prepared well, can provide the competitive advantage.  Product roadmap can commit product requirements of either current or prospective customers. The product roadmap is mostly a plan but in certain cases, few deals beget a need for commitment to deliver new requirements or new product. In such specific scenarios, product roadmap acts as a commitment to deliver requested requirements or new product within promised duration.  The product roadmap is a sign that the product is evolving to meet future business challenges of both existing and prospective customers. Business Development Manager (BDM) – BDMs can look forward to expanding the business into new territories or new market segments if Product Manager prioritizes product requirements specifically for foraying the product into new geographical regions or new market segments. Even otherwise, BDMs can estimate the revenue potential in their territory not only based on the current product capabilities but also based on the product capabilities available in future.
  14. 14. Page | 13 www.ProductGuy.in Pragmatic Guide for Great PRODUCT ROADMAPPING Internal roadmap vs External roadmap In most cases, there would be an internal and external roadmap. Product Manager does not directly add a requirement to the external roadmap and share it with customers. Most likely scenario is that after Product Manager discovers a customer need, he will convert the need into a product requirement and discuss with engineering team to give a proper shape to the requirement. What I precisely meant by giving proper shape to the requirement is that while Product Manager will explain ‘What’ and ‘Why’ of the requirement, engineering team can figure out ‘How’ part of the requirement to conduct a high-level feasibility analysis and estimate the time frame required to deliver the requirement. Internal roadmap could be termed as a work-in-progress item trying to finalize the contents of the roadmap collaborating with internal stakeholders and later pushing it to the external roadmap after getting a buy-in internally. There are other notable differences between an internal and external roadmap.  The engineering team is the audience for internal roadmap while Customers, Sales Team, Account Managers, and BDMs are the audience for an external roadmap.  The internal roadmap is engineering focused and it will be too technical. The external roadmap is customer focused and therefore the use-cases or solutions that provide tangible benefits to customers will be part of the external roadmap. For instance, if there is a feature that changes certain algorithms to improve the efficiency or make the product scalable, internal roadmap list the exact technical changes done to the product while external roadmap will abstract customers from technical nitty-gritty and reveal only the possible benefits. Therefore, Product Manager while adding the exact technical requirements to the internal roadmap will add only the tangible benefits to the external roadmap.  In a case of external product roadmap, Product Manager has to ascertain, (i) what to share (ii) how much to share and (iii) when to share. In the preceding section, I have talked about (i) what to share and (ii) how much to share. Regarding (iii) when to share, there are no hard and fast rules. In a case of new product arrival, even though the news might excite customers sometimes Product Manager might decide against sharing the details with customers for the fear of cannibalizing the sales of existing products. So simple thumb rule that I
  15. 15. Page | 14 www.ProductGuy.in Pragmatic Guide for Great PRODUCT ROADMAPPING follow is to ascertain the risks vs benefits of sharing the news over a time interval (probably 4 quarters) and identify at which specific interval does the benefits exceeds the risks. If Product Manager plots a simple graph of risks vs benefits on Y-axis and time interval on X-axis, the risks and benefits will be mostly linear with each of them following an inverse pattern. Figure 2 - Time to announce roadmap  An external roadmap is a subset of an internal roadmap with an exclusive focus on the value rendered to customers. Customers only care about the value delivered to their business environment. List of features delivered in each release is of little significance to them. Product requirements, new technology or new platforms that are under evaluation might not find space in an external roadmap. An external roadmap is also a selling tool. Any feature or solution that does not directly contribute to the purpose of selling will not find space in an external roadmap. For instance, changes to the product to make it more stable or efforts to reduce the defects found is purely an internal item and therefore external roadmap will not enlist those items. I attempted to provide an example of internal vs external roadmap for the connected car. In a case of external roadmap, I have listed the benefits of advanced diagnostics and indicated about the feature to allay fears about data security. In an internal roadmap, the focus is also on features contributing to the reliability of the product. Customers implicitly expect for the availability of those features and it do not make sense Q3 Q4Q2Q1 TimeT0 Time to announce roadmap
  16. 16. Page | 15 www.ProductGuy.in Pragmatic Guide for Great PRODUCT ROADMAPPING explicitly listing them in external roadmap. Nevertheless, an internal roadmap should explicitly list those features, as nothing is left to the imagination of engineering team. The engineering team will outline a solution (HOW) to the requested features in functional specification document. Connected Car Roadmap Internal External On Board Diagnostics  Identify the list of vital parameters that can help in early detection of potential failures  Communicate vital parameters to the diagnostic servers for analysis  Ensure reliability in case of failure of diagnostic servers  Diagnostic server to pick relevant data for offline and online analysis respectively  Identify the list of roadside assistance providers and add them to the database  Integration with maps to locate the nearest roadside assistance provider  List and identify multiple channels to communicate with every roadside assistance provider On Board Diagnostics  Pro-active predictive failure detection and display of relevant warning messages and possible steps to overcome them.  Automatically call the nearest available roadside assistance provider for immediate help in case of no possibility for auto-recovery Table 1 - Internal vs external roadmap Customers only care about the value delivered to their business environment. List of features delivered in each release is of little significance to them
  17. 17. Page | 16 www.ProductGuy.in Pragmatic Guide for Great PRODUCT ROADMAPPING Requirement vs Need In the entire eBook, I had interchangeably used both the terms ‘requirement’ and ‘need’. It is appropriate to differentiate a need from a requirement, so my readers can get a better perspective when I refer to either ‘requirement’ or ‘need’.  Need – A need is any customer business challenge or pain point or desired business outcome. Need is also referred to as job-to-be-done by customers. The need could be untold (understood by Product Manager without being explicitly mentioned by customers) or unmet (no product has addressed it) or underserved (existing product is only addressing it partially) or overserved (existing product deliver more than what customers need). A classic example of overserved product is Microsoft Office – most users do not use 90% of the functionalities of office. Need is primarily defined from the perspective of a customer. Typically, MRD captures a need. The existence of a challenge or a pain point would be single most compelling reason for customers to buy a product that addresses their pain point in a most optimal way while delivering the best possible experience. Identifying and anticipating customer business challenges or pain points is critical for building the new product. The business outcome can be termed as a solution derived to address a business challenge or pain point. ISPs (Internet Service Providers) are grappling with challenges of reduced or flat ARPU (Average Revenue Per User) resulting in not so significant growth. Therefore, the desired business outcome for ISPs is an opportunity to monetize their network and ISPs will rightly embrace any product that can aid in such business outcome.  Requirement – A requirement is a need when translated into a form understandable by the engineering team. While need outlines the WHY, requirement outlines the WHAT and functional spec written by engineering to implement the need outlines the HOW. The PRD mostly contain requirements, while it is worthy of mentioning need as a means to outline the purpose behind the requirement. While need will outline that an ISP customer is looking forward to an opportunity to monetize their network, the requirement will outline the exact list of features or solutions when added to the product will facilitate customers to monetize their network.
  18. 18. Page | 17 www.ProductGuy.in Pragmatic Guide for Great PRODUCT ROADMAPPING Context of requirements Every need when translated into a requirement has three facets. Let me illustrate through an earlier example of how to help ISPs increase revenues.  What is the requirement? – Focusing on outcome o Opportunity to monetize the network  Why is the requirement important to customers? – Focusing on customer pain points or challenges o Revenues are flat causing negligible growth  How to address the requirement? – Focusing on solution While translating need into requirement and adding it in the PRD, Product Manager has to focus on the first two aspects leaving the last one to the engineering team. However, in addition to those three tenets, another additional tenet is relevant today called context. Context highlights the exact environment in which customers operate. Accordingly, engineering team can build a solution that exactly fits customers’ environment. Product Manager can also use the context to pro-actively figure out any constraints. Constraints highlight the limitations thrown by the customers’ environment that might hamper the solution to work properly. For sake of illustration, let me take an example of connected car wherein the car updates the onboard diagnostics such as oil levels, braking, tire pressure, engine temperature, and system data etc. over the internet (What is the requirement?). The purpose of advanced diagnostics is to anticipate the failure based on a set of critical parameters going off the threshold mark and to warn the driver about the imminent failure. Behind the scenes, the data could be used to possibly auto rectify the failure. Otherwise, advanced diagnostics will alert support team to address the failure without any delay providing them with sufficient information to diagnose and fix the failure. The purpose is to alert the drivers of a rally before any potential life-risking failures and eventually save their lives (Why is the requirement important to customers?). I have precisely communicated what is the requirement and why it is required. Nevertheless, are those details sufficient to fulfill the requirement, but what about context? Without context, it is tough to understand whether it is possible to fulfill the requirement in the environment in which it aroused. User personas and user stories are probably one way of communicating the context but if personas or user stories are used, they had to be exhaustive to cover all possible scenarios. In our example, the
  19. 19. Page | 18 www.ProductGuy.in Pragmatic Guide for Great PRODUCT ROADMAPPING context is a car participating in a rally travelling at an average speed of 100 miles per hour in remote terrain. How does the context help? Context primarily helps in being aware of the constraints thrown by the environment. The success of the solution hangs on reliable connectivity continuously connecting the car with the base station while travelling at an average speed of 100 miles per hour and relaying the diagnostic data in real time. Product Manager has to anticipate whether there is sufficient infrastructure to ensure the success of the solution. Otherwise, Product Manager should defer the solution until the infra is ready or devise alternate measures to reliably transmit diagnostic data to the base station. Five Ws Let me illustrate another example for precisely understanding the context. While the 1st shopping cart was designed, the designer or the Product Manager would have asked customers (the customer could be Walmart, Tesco or anyone equivalent) how the shopping cart should look like. Instead, they should have focused on why the shopping cart is required. The purpose would have dictated the design and designers would have designed the shopping cart and there are at least two broader possibilities as shown below: Vs Figure 3 - Shopping cart How does context make the shopping cart design lot better? As I said context is all about going beyond ‘WHY’ of the requirements and understanding the environment that defines how customers will use the product and where they will use it. Product Manager initially started asking customers what exactly they need and Product Manager used to be self-contented that they are building products as requested by customers. For obvious reasons, the conversation changed from ‘WHAT’ to ‘WHY’. ‘WHY’ is crucial, but once Product Manager gets to know the 1st level of WHY. Product Manager will start
  20. 20. Page | 19 www.ProductGuy.in Pragmatic Guide for Great PRODUCT ROADMAPPING making his/her own assumptions to the remaining levels of WHY. I would rather prefer to understand the requirements as if the mind is a CLEAN SLATE. What happens if the mind is a CLEAN SLATE coupled with essential nature of Product Manager to be curious? Product Manager will start asking more questions, more Ws. That is precisely what we all should do, ask more Ws. When Product Manager asks for more Ws, they get the entire context. I formulated the essential five Ws that can possibly understand the context of a requirement.  WHY – What is the actual purpose behind the requirement? The requirement could be to provide a tool, a product, or a solution. For sake of discussions, let us call tool as a subset of the product, solution as hardware or software that integrates multiples products or tools.  WHAT – What would customers do with the tool, product or solution?  WHEN – When would customers use the delivered tool, product or solution?  WHO – Who will use the delivered tool, product or solution?  WHERE – Where do customers will use the tool, product or solution? Requirement: Connected Car – Diagnostics to detect early failures and provide preventive measures  WHY – To avoid deaths due to failures in the car  WHAT – Identify what failures can cause death and when those failures can occur? Through early detection of those failures, drivers and his/her support team will be alerted  WHEN – The proposed solution will be used during car RALLIES.  WHO – RALLY drivers and a team that inspects those failures to provide pro- active support to avert failures and saves lives of drivers will use the solution.  WHERE – Connected car solution is used during RALLY. It can be a rally in any terrain but preferably in a terrain where the possibilities of deaths due to negligence is higher
  21. 21. Page | 20 www.ProductGuy.in Pragmatic Guide for Great PRODUCT ROADMAPPING Discovery of needs A well-orchestrated discovery of all possible needs through broader understanding and anticipation of customer business challenges, pain points, and business outcomes, later converting those needs into product requirements is the ideal starting point for drafting a GREAT product roadmap. Unless Product Manager discovers and understands the entire gamut of unmet, untold, latent, overserved and underserved needs, later translates them into product requirements, the process of prioritizing product requirements will not be effective. Product Manager can only prioritize what (s)he has discovered, so it is ideal that Product Manager discovers right set of exhaustive needs. The foundation for evolving a product readily embraced by target customers and which does not decline prematurely rests on effectively formulating the product roadmap with a right set of requirements prioritized at right time intervals. Discovering vs understanding requirements Terms ‘discovering requirements’ and ‘understanding requirements’ were interchangeably used in this entire section. Discovering requirements refers to the process of identifying needs that customers did not recognize yet. There are always needs that customer do not recognize but Product Manager has the responsibility to spot those needs while building and evolving the product by observing customers in their natural habitat and developing a thorough understanding of customer business environment. I refer to identification process of those needs and translating those needs into requirements as discovering requirements. On the other hand, understanding requirements is the identification of needs recognized by customers. Product Manager understands those needs by explicitly talking with customers and the thumb rule that I follow for understanding requirements is ‘Never ask customers what they need, always always always ask why they need’. Discover of customer focused needs Product Manager should be all ears while talking with customers to grasp their business challenges and pain points. ‘Listen to your customers’ is an age old adage that is followed by every business and I am not advocating doing anything differently. I am just Never ask customers what they need, always always always ask why they need
  22. 22. Page | 21 www.ProductGuy.in Pragmatic Guide for Great PRODUCT ROADMAPPING trying to emphasize that Product Manager should both listen and understand customer needs, but (s)he does not let customers decide the contents of the product roadmap. Product Manager should not let customers dictate what features to develop. Instead, Product Manager will let customers focus on their business challenges (needs) and the Product Manager (in collaboration with engineering team) should derive the optimal solution that would address business challenges of customers. Otherwise, customers do not think twice to dump the product that contains exactly what they asked for in favor of the product that optimally addresses their business challenges (needs). Even in the case of customers outlining the expected business outcome, Product Manager has to thoroughly analyze the reasons for customer proposing such outcome and suggest other viable alternatives on a need basis. On the related context, I want to quote the words of Henry Ford even though it is a cliché. If I had asked people what they wanted, they would have said faster horses.” Ford while listening to his customers understood their innate needs of travelling quickly from A  B. So understanding customer untold/unmet needs along with explicit needs is critical to evolve the product roadmap. Yet does listening and understanding customer needs alone would suffice? Before I go any further let me clarify my definition of customer focus, “CUSTOMER FOCUS embodies everything that product attempts to understand and address unmet/untold/underserved needs of existing customers of the product”. In short being customer focus is delivering what customers require instead of delivering what they asked for. Sometimes an exclusive focus on customers might be a trap, it leaves Product Manager to be very narrow and short term focused. While it is always better to focus on exclusive segments to ensure that the product will address their Customers do not think twice to dump the product that contains exactly what they asked for in favor of the product that optimally addresses their business challenges
  23. 23. Page | 22 www.ProductGuy.in Pragmatic Guide for Great PRODUCT ROADMAPPING needs, but to attain long-term success Product Manager has to look beyond the needs of a select group of customers. Discovery of market focused needs In several of my blog posts (@ www.ProductGuy.in), I have repeatedly stressed that most of the customer business challenges are short term. However, both short-term and long-term business challenges and pain points of customers should be the focal point for evolving the product. The pitfalls of listening to customers and acting accordingly is that someone might suddenly pop-up disrupting the entire market with new technology or new offering and customers might not think twice to switch sides. While it is required to keep focused on prospective customers of the existing product, it is also essential listening to market to understand how it might evolve. The market is no different from customers and indeed market is a generic representation of a broader segment of customers. When I insist on market focus, I was looking forward to constructing a generic representation of the entire customer segment and start assessing how their needs will evolve with changes in dependent macro factors. More often, there is an inevitable necessity to go beyond the boundaries of the existing needs and existing customers to identify or grasp what is changing outside and build a mental map of how those changes might alter the customer behavior or create new needs. Customer focus is about delivering what customers require instead of delivering what they asked for The pitfalls of listening and understanding customers is that someone might suddenly pop- up disrupting the entire market with new technology or new offering and customers might not think twice to switch sides
  24. 24. Page | 23 www.ProductGuy.in Pragmatic Guide for Great PRODUCT ROADMAPPING At a tactical level, it always augurs well to look at every individual customer needs to ensure a steady flow of revenue. However, at a strategic level while Product Manager has to envision how the product should evolve, (s)he has to create a mental map of how the generic needs of the broader segment of customers evolve and how they will probably respond to new technology innovations or any products in adjacency space that can address the needs of customers. To be more precise, in case of market focus, I was rather thinking strategically to fathom the long-term evolution of the market needs or long-term relevance of the product due to changes in market/technology or customer behaviors through explicitly pondering over the following  Attacking growth – If it is a growing market, there should be conscious effort to identify who is contributing to the growth and lay plans to capture it?  Capitalizing white space (aka demand generation) – Probably same product but new use-case and new target segment, Product Manager have to look out for such possibility. Otherwise, Product Manager has to spot customers trying to use the product differently from its intended use and should validate the possibility of either building a variation of the existing product or enhance the existing product to generate additional demand for the product.  Is there any product in the adjoining segment that has the potential to make the current product irrelevant (what Mobiles did to Pager, what Smartphones did to Camera and Navigation Devices) in near future? Is the existing product a disruptor or any other product(s) can potentially disrupt the new product? UBER leveraged technology to deliver better taxi services in comparison with traditional players. Identify or anticipate potential disruptors that have potential to displace the existing product from the market.  Who are customers of tomorrow – There was a wider perception that Internet Service Providers (ISPs) were primary target segment of networking devices not There is inevitable necessity to go beyond the boundaries of the existing needs and existing customers to identify or grasp what is changing outside and build a mental map of how those changes might alter the customer behavior or create new needs
  25. 25. Page | 24 www.ProductGuy.in Pragmatic Guide for Great PRODUCT ROADMAPPING until Amazon, Google, Facebook, and Microsoft started buying more networking hardware than ISPs. Not many vendors looked at the later as potential customers. In the case of consumer products, Product Manager can build and evolve better products by ascertaining the buying patterns or behaviors of Millennials, who might constitute a significant portion of the target market. Their choices might not be the same as existing customers. While building and evolving an existing product, there should be conscious effort to understand who customers of tomorrow are.  What are the customer needs of tomorrow – Can Product Manager anticipate those needs. Plan to evolve the existing product not for customers of today but for customers of tomorrow.  Is there any new technology or trends that when not accommodated might cause the product to be irrelevant? For instance, the effect of virtualization (Network Functional Virtualization-NFV/Software Defined Networking-SDN) on physical appliances in networking industry or Impact of IoT on industrial products  Is there any new technology or trends that when not accommodated might cause the new product to be irrelevant? For instance, effect of virtualization (Network Function Virtualization-NFV or Software Defined Networking-SDN) on physical appliance in networking industry or Impact of IoT on industrial products. Is the existing product negating all relevant trends? If so, Product Manager is seriously jeopardizing the longevity of the product. Product Manager will not be able to consciously ponder over the above items unless (s)he expands the horizon to go past the existing customers and existing products to understand the characteristics of the entire segment and comprehend how it will either react to external changes or impacted by external changes. Anticipate emerging needs In the case of market focus, Product Manager does not merely understand customer needs, (s)he should also anticipate how customer needs will evolve or what new needs will emerge with possible changes to dependent macro factors. Once Product Managers understands the dependent macro factors (such as economy, regulation, internet, technology etc.) that can directly or indirectly influence the products, there are 2 kinds of possibilities.
  26. 26. Page | 25 www.ProductGuy.in Pragmatic Guide for Great PRODUCT ROADMAPPING 1. Needs of tomorrow  With increased adoption of multiple devices (smartphones, tablets etc) by each user or family, will users start demanding new plans from ISPs?  With increased adoption of mobile devices in rural a segment and with the possibility of a decrease in internet connectivity costs, could the following new needs could emerge: (i) Mobile banking. Similar to the m-pesa model (ii) Sharing latest farming techniques and knowledge. (iii) Mobile commerce to sell directly to consumers – eliminate intermediary agents.  With the advent of IoT and wide spread adoption of IoT technologies to create smarter homes, what will be the impact to ISPs that provide pipes to carry data (specifically Machine-to-Machine - M2M)? How ISPs could monetize the data? 2. Customers of tomorrow  With the potential increase in disposable income of millennials, they can be possible target customers for real estate, luxury cars etc. Product Manager has to ascertain whether their needs will be the same as existing customers. What I have stressed so far is that certain needs will emerge and new customers will be added to the target segment in future with changes in the economy, technology, regulation etc., and it is the responsibility of Product Manager to anticipate both emerging needs and emerging customers. Later, track them in PRD. How far to look into the future Primarily, why should Product Manager anticipate, why not address the needs or target new customers after they emerge. Whether to anticipate or just wait until the need emerges primarily rests upon one factor – How long does it take to address a need? If the duration is really longer, then Product Manager has the responsibility to anticipate the needs to get the 1st mover advantage and to excite the customers before the competition does. In the case of automobile sector where the development cycles are BIG, Product Manager cannot wait to understand the needs and aspirations of millennials until they start buying cars. It would be tough to answer how far should Product Manager look into the future, I would only insist on a starting point that would
  27. 27. Page | 26 www.ProductGuy.in Pragmatic Guide for Great PRODUCT ROADMAPPING constitute the sum of the time taken to research, develop and validate the product. Since it would be tough to predict the future, Product Manager could better anticipate possible outcomes of the future through scenario analysis and use lean techniques of product development to build product increments to validate and ascertain which outcome is most likely to occur. Final thoughts Guess I have dropped sufficient hints on what I am trying to conclude, the contents of Product Roadmap should be a combination of both market and customer focused needs translated into product requirements. If I had to rephrase my earlier definition of roadmap – “Product Roadmap is indeed a collection of customer and market business challenges, pain points and business outcomes translated into product requirements and prioritized in accordance with the product strategy/product objectives and addressed through incremental product enhancements, or incorporating new technology, or building new platform or new product lines” Ideally, product roadmap should focus on both short-term and long-term evolution of the product.
  28. 28. Page | 27 www.ProductGuy.in Pragmatic Guide for Great PRODUCT ROADMAPPING Collaborative discovery of needs – Who can participate? One of the constant fears that every Product Manager share is: Competition identifying a customer need or an opportunity before (s)he or their peers do – Honestly, Product Manager need not feel bad about it. Such situations do occur and it can only testify that the discovery process is not rock solid and there are gaps. It gives one more reason for Product Managers to believe that they should think beyond themselves to expand their sources that can help them discover needs. Engineering, Sales, Account Managers, and Business Development Managers etc. always outnumber product Managers in an organization. One best piece of advice that I had received is that stacking more Product Managers is not feasible and it is not the right solution too. Instead, Product Manager has to scale with existing stakeholders to perform his/ her activities. Impact: Collaborate effectively with all the stakeholders to discover needs Product Manager is not alone in the process of discovering needs even though (s)he is exclusively responsible for discovering needs, corroborating needs and sometimes synthesizing inputs from various disparate sources to formulate a need. It might sound cliché, the truth is Product Manager does not have an authority to demand that every stakeholder has to discover needs and Product Manager cannot set goals for the discovery of needs to each stakeholder. What I had mostly observed is that when Product Manager walks that extra mile to facilitate Sales Manager close deals, help Account Manager maintain better relations with their customers, and aid Engineering Manager and his team accelerate development of better products, entire stakeholder will also walk that extra mile in assisting Product Manager to build better products. When ProductManager walksthat extra mile to facilitate Sales Manager close deals, help AccountManager maintain better relationswith their customers, and aid Engineering Manager and his team build products faster, entire stakeholders will also walk that extra mile in assisting Product Manager to build better products
  29. 29. Page | 28 www.ProductGuy.in Pragmatic Guide for Great PRODUCT ROADMAPPING For better clarity on how each stakeholder can help Product Manager in the discovery of needs, I have provided some illustrations to clarify on the kind of needs that each stakeholder can discover. Needs from support team  Product and Non-product enhancements (Usability, Features, Documentation etc.) - YouTube changed the VIEWS variable to 64 bit to accommodate more than 2 billion views after Google noticed increasing viewership for ‘Gangnam Style‘ video2 . Product Manager conceptualizes and builds a product with certain scale parameters assuming it would suffice. However, as time progresses and customer business grows, product might soon start hitting the limitations on certain critical scale parameters. Customers would raise a panic button immediately after hitting the limitation but support team can pro-actively raise an alarm through monitoring the critical parameters of the product. Support team will use support cases or other methodologies available to monitor and track the critical parameters of the product. When the critical scale parameters reach a threshold level, support team should immediately alert Product Manager to increase the value of the affected scale parameters. The support team is also equipped to analyze support cases and understand the trends to figure out the most common issues faced by customers, such analysis can help Product Manager understand the list of needs not optimally addressed by the product. Any improvements can lead to better customer experience thereby triggering higher retention rate leading to more up-sell or cross-sell opportunities. Increasing trend of support cases on a specific feature could also throw lot more possibilities for Product Manager to ponder upon the following:  The feature might be buggy – Wakeup call for engineering team to immediately address those issues, while Product Manager can plan for interim release to avoid further customer dissatisfaction  The feature is not intuitive – The feature might be working properly but customers are increasingly finding it difficult to operate. Either the feature is 2 source:https://plus.google.com/u/0/wm/4/+youtube/posts/BUXfdWqu86Q
  30. 30. Page | 29 www.ProductGuy.in Pragmatic Guide for Great PRODUCT ROADMAPPING not intuitive (usability constraints) or documentation is not clear. It is widely accepted principle that product should be intuitive enough for users to operate the product without the need for a documentation. However, from the perspective of HW (Hardware) product, documentation often plays a key role.  The feature is incomplete – Product feature does not completely address customer needs. Wake up call for Product Manager because (s)he has not properly analyzed the customer needs. Product Manager needs to take quick remedial action to bridge the gap between customer needs and product capabilities ASAP while performing a candid introspection of why the product could not address the customer needs properly.  New use-cases/ solutions There are classic examples of customers using the product quite distinct from its intended use. Every product has few innovative customers who are always step ahead of the product team in implementing new use cases independently through innovative changes in configuration or building new solutions through successfully aligning the product with other products. Those innovative customers whom I would comfortably refer to as Innovators or Visionaries as explained by Geoffrey Moore in his book “Crossing the Chasm” do dare to exploit the entire functionalities of the product to address challenges faced by them. Such customers constantly pose technical challenges and help Product Managers build better products, which eventually puts the product ahead of the competition. Personally, it is good to have such customers and they are worth more than a million-dollar customer. Support engineers should consciously look out for such unique use-cases or solutions through the aid of support cases to assist Product Manager to identify innovative customers and capture their innovations. Product Manager can later use the data to enhance the product that can supplement those innovations or draw plans for new product offering or new ways of positioning the product (aka demand generation).  New product requirements Customers ask about non-existing features through support probably because of lack of understanding of the entire functionality of the product. Product Manager
  31. 31. Page | 30 www.ProductGuy.in Pragmatic Guide for Great PRODUCT ROADMAPPING could use those inputs to understand new product requirements; this set of requirements will predominantly be incremental extensions of existing product capabilities. Sometimes support system is the single window for customers to vent their ire on the lack of any features that should have been available in the product by default. In B2C (Business to Consumer), customers do not think twice to raise their concerns through social media. The support system should have the facility to track the digital footprint for such messages. Needs from engineering team Engineering teams are masters of technology while product managers are presumably masters of problem space. Closer ties between the two entities triggering frequent discussion (not necessarily structured, probably unstructured discussions over coffee, lunch or in corridors) can create wonders. When Product Manager keeps engineering teams informed of the problem spaces, they can evaluate how advances in technology (probably new components in case of HW products, new algorithms) can address customer pain points in a much better way. For instance, in the case of VoIP products, engineering team can suggest alternate mechanisms that can increase voice and video quality, reduce latency and BW required etc. For same reasons, it is always better to provide outside view of the world to the engineering team. The engineering team has to be equipped with details about competition, customers’ wins & loses, and what differentiates our product from the rest. To further illustrate the importance of working with the engineering team, while I was working on new virtualized product I was interfacing a lot with engineering team to understand more about virtualization and how the performance could be improved. I did earlier talk about increasing the adoption rate of new technology. I saw the performance as one of the primary roadblocks for customers from adopting virtualized product. Engineering team did throw many ideas on how to improve performance and in fact, they did introduce me to Docker technology. Docker technology was gaining ground and engineering team educated me on how it works and potential advantages offered by Docker over hypervisor. I could leverage the technical details provided by the engineering team to understand how Docker can help provide better value to customers over hypervisor. End of the day, underlying technology does not make much difference
  32. 32. Page | 31 www.ProductGuy.in Pragmatic Guide for Great PRODUCT ROADMAPPING to customers as much as the value rendered by each of those technologies does. Nevertheless, technology awareness is critical for Product Manager to make informed decisions. Tagging with engineering team can help Product Manager to stay abreast of the latest technology and further understand the impact it could have on product evolution. Many would advise Product Manager to hang out with customers, sales team, and account managers. I would rather insist on hanging out with engineering team at an equal proportion to build better products. When Product Manager is close to the engineering team, it is better to leverage the opportunity facilitating the frequent exchange of thoughts, ideas, problems etc. I could only say that MAGIC would be created out of such interactions and if there is a distributed Product Management team, I would prefer to hand over the responsibility of building and evolving the product to the Product Manager closer to the engineering team. Closer interaction might often enable engineering team to understand the needs precisely, so they can deliver solutions that can amaze customers and create a WOW feeling. Needs from sales team No one interfaces closely with customers as much as Sales Manager does. Sales Manager can provide specific details on how each customer is using the product and they can help discover needs of an individual customer. Sometimes Sales Manager can also help understand the gaps with competitors that is haunting the product in closing deals. In addition, Product Manager can also seek Sales Manager input on the below items to get better knowledge about the product  Why is customer happy with our product? Seriously helps to know why we are winning.  Why is customer whining? With what aspects of the product (support, usability, reliability or lack of features) is the customer not happy about?  Many would advise Product Manager to hang out with customers, sales team, and account managers. I would rather insist to hang out with engineering team at equal proportion to build better products
  33. 33. Page | 32 www.ProductGuy.in Pragmatic Guide for Great PRODUCT ROADMAPPING  What deals did the product lose? Is the product losing because of lack of any capabilities? Is there any trend?  Is the product losing to any other product in the adjacency space? Another big source to discover needs is RFP, which Product Manager neglects often. In the case of a B2B segment, RFPs mostly precede sales and the RFP would contain more details about customer needs. RFP would also validate the ability of the product to handle future needs of customers. Analyzing multiple RFPs provides the direction in which customer businesses are evolving, look out for patterns of new needs and record them. Another possibility to identify customer needs is to spot star Sales Managers. Star Sales Managers sell more not because the product is in demand or the product is great or that (s)he is lucky. They sell more because of their deeper understanding of both the customer and the product combined with the ability to position the product effectively at the crossroads of problem and solution space. Working with such Sales Managers is extremely beneficial for gaining more insights into customer needs. Further, such Sales Managers are always on lookout for opportunities to generate the demand for the product. They equally look up to the Product Manager to share or contemplate new use-cases providing additional compelling reasons for customers to invest in the product. Needs from BDMs BDMs can mostly help discover strategic needs that can push the growth of the product. While talking about discovering needs, I stressed the importance of pondering on the following topics: Star Sales Managers sell more not because the product is in demand or the product is great or that (s)he is lucky. They sell more because of their deeper understanding of both the customer and the product combined with ability to position the product effectively at the cross roads of problem and solution space
  34. 34. Page | 33 www.ProductGuy.in Pragmatic Guide for Great PRODUCT ROADMAPPING  Attacking growth – If it is a growing market, there should be conscious effort to identify who is contributing to the growth and lay plans to capture it?  Capitalizing white space (aka demand generation) – Probably same product but new use-case and new target segment, Product Manager have to look out for such possibility. Otherwise, Product Manager has to spot customers trying to use the product differently from its intended use and check if there is an opportunity to build a variation of the existing product or extend the existing product to meet additional demand for new use-cases.  Is there any product in the adjoining segment that has the potential to make the current product irrelevant (what Mobiles did to Pager, what Smartphones did to Camera and Navigation Devices) BDMs do definitely play a greater role in helping Product Manager ponder over the above topics. BDMs by the virtue of their responsibility to identify new markets for the product and to put the product on growth trajectory should gain better knowledge about the market, trends etc. While interactions with Sales Manager(s) boil down to specific customer needs, interactions with BDMs revolve around discovering market needs. Role of BDMs do not just restrict them to help discover strategic needs, they can also play a greater role while the market is on the cusp of technology change. During discussions around inflection point, I did mention that Product Manager should also focus on accelerating the technology shift triggering the migration of customers from old to new technology. BDMs can help identify factors which when accomplished can trigger the acceleration of technology shift. The factors could be an improvement in performance of new technology or identification of widespread applications of new technology. Basic tenets of collaborative discovery In all the above cases, Product Manager do not blindly accept the needs and record them rather he opens a dialogue with the respective stakeholders to understand more about the need (WHAT part of the need) and develop a complete awareness of how unmet, underserved or latent need is impacting customers (WHY part of the need). Without the complete grasp of what and why of the need, it might be extremely difficult for Product Manager to convert the need into requirements and appropriately prioritize
  35. 35. Page | 34 www.ProductGuy.in Pragmatic Guide for Great PRODUCT ROADMAPPING it. In certain cases, stakeholders can merely provide some hints on customer needs and they might not be equipped to provide complete details. Incomplete information is still fine and Product Manager might have to build upon those hints. Product Manager should encourage stakeholders from sharing any kind of information about customer needs, pain points etc. and not penalize or reprimand them for sharing incomplete needs. The basic premise is that any information on customer need is worthy unless thoroughly corroborated. Product Manager should also follow inclusive approach while prioritizing requirements by thoroughly communicating the yardsticks used for prioritization of requirements to the entire team of need discoverers for allaying any fears of bias in the process of prioritizing requirements. Needs from confluence of multiple minds Needs are not always discovered by a single entity. Certain needs emerge at the confluence of multiple minds. Especially in the case of emerging technologies such as IoT, Virtualization, Big Data etc. where there is no clear definition of problem space because technology is evolving and the applications of the technology are evolving, the culmination of engineering, domain experts, Product Managers is essential to synthesize divergent thoughts into a concrete need. Unlike in earlier scenarios, I am focusing on structured methodology (like brainstorming) because each entity has many thoughts and they are worthless individually. The focus of brainstorming session is not to pick the best idea. Instead, Product Manager has to effectively moderate to facilitate a freewheeling conversation among all the participants to put on the table all the divergent thoughts including their assumptions, later participants would have built upon other thoughts to provide a shape to a new product need. The scenario is akin to each participant holding a partial solution to a riddle. Product Manager has to identify and bring together all the entities holding the partial solution to solve the riddle. To ensure success of this entire exercise, Product Manager has two challenges 1) Identifying right set of participants 2) Facilitating effective participation from all participants Importance of ‘WHY’ ‘WHY’ does not essentially mean that Product Manager fires a barge of questions either during brainstorming or while collating needs from various stakeholders, ‘WHY’ should not sound like an interrogation. The power of ‘WHY’ lay in enabling others to ponder, to
  36. 36. Page | 35 www.ProductGuy.in Pragmatic Guide for Great PRODUCT ROADMAPPING reason out their findings. Primarily ‘WHY’ should also let the other person break their assumptions. Every person has a certain set of assumptions and it guides their thinking process. Higher the assumption, more the limitations exists in expanding the thought process of an individual. Because of the limitation or inability to question the status quo, retailers thought people would never buy clothes online without touching. Executives at Nokia and BlackBerry thought mobile users would always be comfortable with QWERTY keypad. ‘WHY’ is critical when Product Manager has to think beyond the existing needs of customers and anticipate how new technology could influence them. ‘WHY’ would dig out all the assumptions related to customer behavior and ‘WHAT IF’ hypothetical analysis could be used to understand what changes in technology or product would trigger the change in customer behavior. The examples that I had highlighted is related to disruptor technology as asking ‘WHY’ creates much larger impact. Nevertheless, asking ‘WHY’ is essential for the critical understanding of tactical and strategic requirements as well. The exact definition of tactical, strategic and disruptor requirements is outlined in the following section. Ability of Product Manager to facilitate collaboration Honestly, there will never be a dearth of stakeholders discovering or contemplating needs based on their role and experience. Product Manager has to create an environment for facilitating the free flow of needs and information related to the product (drawbacks, needs, limitations etc.) from every stakeholder to Product Manager. Even if any of the needs sounds dumb, Product Manager should not dismiss it away, (s)he should explain the reasons for discarding and elaborate the yardsticks used to measure the value of a need. To check whether Product Manager could create a collaborative atmosphere, Product Manager(s) should try answering the following questions with YES/NO 1) Are you approachable? 2) Are you enthusiastic about listening to ideas that resolve customer problems? 3) Are you eager to know about the new business challenges of customers? 4) Are you interested in keeping yourself abreast with latest technology advancement surrounding your product? 5) Are you eager to know about the kind of implications that new technology can have on the product?
  37. 37. Page | 36 www.ProductGuy.in Pragmatic Guide for Great PRODUCT ROADMAPPING 6) Do you have the list of blogs or analyst data on your reading list as an everyday task? 7) Do you feel spending time with engineering is your primary responsibility? 8) Do you feel bad about dragging engineering team into all your calls with customers? If the answer to all the above questions is emphatic YES, then Product Manager is desperate to fill his/her head with information. Such Product Manager would never forego any opportunity to learn and (s)he would naturally facilitate an atmosphere to collaborate.
  38. 38. Page | 37 www.ProductGuy.in Pragmatic Guide for Great PRODUCT ROADMAPPING Categorization of requirements – Tactical, strategic and disruptors Explicit focus on customer and market is to discover all possible needs without leaving any needs behind. Unless Product Manager discovers all needs, (s)he will not be able to make right prioritization decisions and it will hamper the evolution of the product. After the discovery of all needs, trying to categorize and prioritize them based on market or customer hardly makes any sense. Discovery of customer-focused needs provides a foundation to build a generic representation of the broader segment of customers and to embark on the journey of discovering market focus needs. Therefore, somewhere deep down needs that are discovered through customer focus will ultimately overlap with the needs that are discovered through market focus unless the business models rest on customization. Therefore, categorizing requirements into customer focus and market focus could hardly be effective. Then, what would be the right set of parameters to categorize requirements? I have already provided hints of possible categories while talking about ‘Discovering of market focused needs’. Yes, you guessed it right. I am trying to categorize requirements into tactical and strategic. In addition, I have added a new category called disruptor. Tactical Tactical requirements are short term (mostly 1 year). Requirements listed under this category do not face any uncertainty. Tactical requirements are lucid and therefore there is hardly any risk in implementing them. Further, customers will readily embrace the requirements when incorporated into the product ensuring a steady flow of revenues. The requirements under this category address short-term business challenges of customers providing an attractive proposition for customers to invest in the product. The requirements under this category are mostly evolutionary in nature. Tactical requirements are essential to ensure a steady flow of revenues to meet revenue targets of the product. Strategic Strategic requirements are the near long-term (typically around 2-3 years). There is some amount of uncertainty on how customers would react to the proposed changes to the product and therefore the risk of implementing them is moderately higher. Therefore, the priority is to eliminate uncertainty through building a minimalistic
  39. 39. Page | 38 www.ProductGuy.in Pragmatic Guide for Great PRODUCT ROADMAPPING prototype, validating it, and soliciting feedback in an iterative manner until complete elimination of any uncertainty associated with the strategic requirement. The requirements under this category bring in entirely new value to customers but more often customers do not explicitly request them and customers can still live without them unless the requirement becomes parity. Online fashion store adding the capability of augmented reality to facilitate virtual dressing room is a fine example of strategic requirement. Figure 4 - Categorizing requirements Tactical What are the customer businesschallengesor paintpoints?Whatare the desiredbusiness outcomesandwhy? Is ita growingmarket? Who iscontributingto the growth?Which geo or whichsegmentof customers How to generate demand?How to add more customersto the targetsegment? Strategic Can the productbe usedforany alternate purpose?Canthe productbe tweakedto addressthe needsof new targetsegment? Who are the customers of tomorrow? What are the needsof tomorrow? Disruptor Is there anyproductin the adjoiningspace whichwhenimproved furthercouldbe a potential threat?Are youlosingcustomersto any productinthe adjoiningspace? Is there anynew technologyortrends that whennot accommodatedmight cause the productto be irrelevant. Customer Focus Market Focus
  40. 40. Page | 39 www.ProductGuy.in Pragmatic Guide for Great PRODUCT ROADMAPPING Disruptor Disruptor is a game changer. They uproot the entire market, create a new market and install new normal. Disruptors make old way of doing things irrelevant through creating a new product line, new consumption models, and new ecosystem that did not exist before. Disruptors do not evolve the product but they will extend the product line introducing new products embracing disruptive technology or innovations. Strategic requirements when chosen properly can extend the product life cycle without prematurely declining the product. However, they could not stop the product declining from disruptive innovations or technology. Focus on disruption is to embark on the journey of finding new technologies that have the potential to disrupt the entire market and create a new normal. Disruptors create viable options and alternatives for growth in long term. In the case of strategic requirements as well, we focus on imbibing innovation and new technology into the product to create a better value but those innovations or new technology are sustaining in nature and does not create new markets. While disruptor technology or innovation creates new market uprooting the older ones, an ideal way to tackle the disruptor technology is to embrace it and not to fight it. Organizations therefore have to start investing in new technologies that have the potential to disrupt the market and introduce new normal. Product offering vs market matrix In order to better explain tactical, strategic and disruptor, I derived product offering vs market matrix. I believe the diagram below is self-explanatory.  Incremental enhancements to existing product to better position the product in existing market belongs to tactical category.  Evolutionary changes to existing product offering to position in new market or creating new product offering for positioning in existing market belong to strategic category.  Revolutionary changes to create new markets through new product offerings belong to disruptor category. While I have exclusively talked about what is tactical, strategic and disruptor requirements. In the following chapter, the focus is on why it is essential to split the requirements into three categories and how to obtain such a split in alignment with overall product vision and strategy.
  41. 41. Page | 40 www.ProductGuy.in Pragmatic Guide for Great PRODUCT ROADMAPPING Strategic Disruptor Tactical Strategic Figure 5 - Product offering vs Market ExistingProduct Offering Existing Market New Market NewProduct Offering
  42. 42. Page | 41 www.ProductGuy.in Pragmatic Guide for Great PRODUCT ROADMAPPING Ratio of tactical/ strategic / disruptor requirements in roadmap The motivation to categorize the roadmap into (i) tactical, (ii) strategic and (iii) disruptor is derived from the 3-horizon framework described by McKinsey for products. Figure 6: McKinsey 3 Horizon Framework Source: http://www.mckinsey.com/insights/strategy/enduring_ideas_the_three_horizons_of_growth Horizon 1 - Tactical Focus on addressing existing business challenges to ensure flow steady of revenues in short term.
  43. 43. Page | 42 www.ProductGuy.in Pragmatic Guide for Great PRODUCT ROADMAPPING Horizon 2 - Strategic Focus on expanding the product through innovative solutions or addition of new technology for targeting additional growth or revenue in near long term. Innovative solutions or new technology delivering potential value to customers would act as key differentiators to retain customers and to facilitate revenues in near long term Horizon 3 – Disruptor Focus on creating viable options for future growth in long term through appropriately investing on technologies that have the potential to disrupt the market There will always be clamor to introduce tactical requirements that fetch product revenues in shorter run. Unless Product Manager determines the split and allocates some portion of roadmap for non-tactical requirements, strategic requirements will never surface when confronted with tactical requirements owing to their inability to bring immediate revenues. The bitter truth that most Product Managers often miss is that exclusive focus on tactical requirements will shrink the lifetime of the product, thereby causing the product to decline prematurely. Investment on strategic requirements is imperative to secure near future revenues and growth. By explicitly defining a ratio, I am only trying to strike the balance between tactical and strategic avoiding potential conflicts while prioritizing requirements. In order to figure out the ratio, Product Manager needs to understand what the product growth strategy is. Undeniably, the primary purpose of every product is to increase the bottom line and product growth strategy would exactly let everyone know what contributes (prospective customers, new market segment, new geo territories, new technology, or new solution?) to additional growth. Please refer to the related blog post Exclusive focus on tactical requirements will shrink the lifetime of the product, thereby causing the product to decline prematurely
  44. 44. Page | 43 www.ProductGuy.in Pragmatic Guide for Great PRODUCT ROADMAPPING on ‘Attacking White Space – Identifying Growth Opportunities’ @ ProductGuy.in. Accordingly, Product Manager could figure out that ratio. For instance, if existing customers contribute to more revenues in a saturated market than product requirements of existing customers should occupy higher ratio. In case of targeting new market segments, product requirements specific to those segments would occupy higher ratio. If anyone is hoping that I would suggest some scientific methodology to determine the ratio between each of the categories (tactical, strategic, disruptor), I hate to disappoint but to be honest there is no scientific way to derive the ratio. Drafting a scientific methodology is not ideal because road mapping is a combination of art and science. Instead, I will provide some guidelines that should equally translate into actionable items while determining the split. The success in determining the split clearly lay in formulating the product growth strategy. I have provided illustrations of most familiar product growth strategies as a reference for facilitating discussions on more such product growth strategies.  Leapfrog strategy – If the product is not a market leader and the intention is to leap frog the competition, do not act as fast follower and never attempt to accomplish everything that market leader has done. If the gap between your product and the incumbent product is too wide, trying to ape incumbent and following them will never let the product surge ahead. Instead, listen to the market, think ahead of time and try to imbibe new technology or new offerings to jump ahead of the market leader. Nintendo WII is a classic example of leapfrog strategy. While Nintendo’s competitors were busy driving the market towards expensive consoles and sophisticated graphics successfully, Nintendo did not follow them instead build WII leveraging new technology of gesture control and targeted a new segment of casual gamers with less expensive consoles driving huge margins.  Fast follower strategy – Companies adapt fast follower strategy when they are averse to spending money on R&D and experimental products to validate the market for uncertainty. The fast follower should be nimbler to quickly jump into the fray after the 1st mover has cleared the air on the uncertainty about new technology or innovation.
  45. 45. Page | 44 www.ProductGuy.in Pragmatic Guide for Great PRODUCT ROADMAPPING In either case, there is a precedent of what works and what do not work. Therefore, Product Manager while focusing on closing the parity has to leverage the experiences of incumbent to focus on requirements valued most by customers  Market leader strategy - If the product is a market leader, then it has to be at the forefront of innovation disrupting the market continuously. Something similar to what Microsoft and Intel did for Desktop. While Microsoft evolved Windows OS, Intel evolved the processors to meet the higher processing requirements of Windows OS. I do not think any customer have directed both Microsoft and Intel to evolve their products. What Intel and Windows did was to create a demand. I do not think they ever targeted to satisfy a demand.  Customer focus strategy - In case of mature or saturated market, existing customers constitute a majority contributor to revenues. In such scenario deriving a product roadmap constituting predominantly customer-focused features will yield better results however with some room for market features. Otherwise, there is always a possibility for someone to disrupt the saturated market and grab your customers. For instance, what OLA, UBER did for traditional taxi business. As long as there is steady flow of revenues, Product Manager will have a free hand in implementing his plans of incorporating strategic requirements into the product. However, decline in revenues of subsequent quarters will hit the overall resource allocation to the product eventually scuttling the plans of Product Manager to introduce any strategic requirements. Hardly Product Manager will have a free run, so it is vital to show gains in short run while simultaneously planning for long-term gains. De-facto, I generally adapt 80:20 rule to derive the split between tactical and strategic. Depending on the strategy, I utmost take +/-10 from strategic. In both leapfrog and market leader scenario, the emphasis will be on strategic requirements but definitely not on par with tactical requirements. I generally prefer allocating 30% of the overall roadmap for strategic requirements. The value 30% is just a hunch, the ultimate objective of the split is to retain inflow of revenues while focusing on strategic requirement. As long as
  46. 46. Page | 45 www.ProductGuy.in Pragmatic Guide for Great PRODUCT ROADMAPPING Product Manager follows rigid prioritization process, creating space for strategic requirements in the roadmap will never be an ordeal. Depending on the overall strategy of the organization, Product Manager has to determine % split for each of the 3 horizons in product roadmap. Wait! Why did not I talk about disruptor? Organizations has to focus on both strategic and tactical requirements, there is hardly no choice. Nevertheless, explicit focus to identify potential disruptors is purely by choice even though all the firms have to innovate continuously to stay afloat in the market. The reasons I said choice is that there is lots of uncertainty in disruptor technology even after they hit the market and until they mature. Organizations should cautiously validate disruptor technology. Further any new technology with exception of some take longer time to mature. Therefore, it is the prerogative of the organization depending on their overall strategy whether to exclusively invest or not invest their resources to anticipate or create new normal through identifying or creating disruptor innovations or technologies. Some organizations might not take the tedious journey of unraveling the mystery around new technology by resolving the uncertainty and identifying the potential market for those technologies, instead they chose to wait for someone to clear all uncertainties surrounding new technology and later start investing on them (fast follower) or acquire companies with the expertise on the new technology.
  47. 47. Page | 46 www.ProductGuy.in Pragmatic Guide for Great PRODUCT ROADMAPPING Figure 7: Technology hype cycle (Source: Gartner) Investing on disruptive technologies is not a norm as much as there is necessity to focus on both strategic and tactical. Technology adaption takes time and a quick look at the hype curve will reveal that most of the technologies take a minimum of 5 years to reach ‘Peak of Inflated Expectations’. At the height of inflated expectations, we could notice that the early adapters express interest to invest in technology. Yet, the technology is raw and validation of technology takes place during this period. The technology would be further refined based on the feedback received during validations by early adapters to reach mainstream. Obviously organizations do have time to keep a watch and assess the maturity of the technology (refer Gartner Maturity Curve and Adoption Curve below). While technology reaches the height of inflated expectations, organizations either have to be nimbler to enter the fray much faster or start acquiring companies investing in that technology. Uncertainties surrounding the technology would then be mostly resolved. The challenge is in the adaption of the technology to address appropriate business challenges that are critical to customers’ environment. To put in other words, the focus would be mostly on demand generation.
  48. 48. Page | 47 www.ProductGuy.in Pragmatic Guide for Great PRODUCT ROADMAPPING When I said investing on disruptor is not a norm does not essentially mean that I am advocating companies against investing on disruptor technology and such move would spell doomsday. What I had indicated is that depending on the overall strategy of the organization, they can adapt wait and watch approach. From the point of innovation trigger to reaching peak of inflated expectations, there was always sufficient time to take a note of how technology is evolving and to jump into the bandwagon. If you look at some of the earlier technologies, how long did it took Bluetooth to enter into the mainstream? How long did it took Digital Camera to enter mainstream market? While we are now talking about driverless cars and virtual reality etc., what is the right time to start investing on driverless cars before it is commercially viable. In fact, I am desperate to understand or figure out some frameworks or models to understand the right timing to invest on any technology. Much of the new technology although fascinating and tough to evade the hype surrounding it, how does one determine the actual potential and right time to start investing on it. I only have too many questions than answers. The idea is to enter the market just on time without being too early or too late. Much of the new technology although fascinating and tough to evade the hype surrounding it, how does one determine the actual potential and right time to start investing on it?
  49. 49. Page | 48 www.ProductGuy.in Pragmatic Guide for Great PRODUCT ROADMAPPING Figure 8: Adoption curve and maturity curve (Source: Gartner) Once the organization decides to make a move and start investing on disruptor technology, focus of discussion is to figure out the right balance between old and new technology. Unlike tactical and strategic, we cannot allocate a static % of the roadmap to disruptor. As the new technology evolves and matures, the old technology eventually declines. Inflection point is the point at which old technology dissolves and new technology emerges. Inflection point causes a shift in revenues, technology, customer preferences etc. Therefore, product roadmap has to be flexible to adapt to the shift in technology or rather pro-actively accelerate the shift. I will be elaborating on this topic in the next section.
  50. 50. Page | 49 www.ProductGuy.in Pragmatic Guide for Great PRODUCT ROADMAPPING Inflection point – Seizing the opportunity Every product has an Inflection point as defined by Andy Grove in his book “Only Paranoids Can Survive”. One simple case of the inflection point is technological change. The inflection point is both an opportunity (to displace incumbents) and a risk (to be displaced by new entrants or existing competitors), so it is critical to be wary of the inflection point. Figure 9: Inflection point Perils of inflection point Most of the companies basking in the glory of the success of its existing product(s) miss the inflection points. Intel was so obsessed with microprocessor business; it missed to dominate the chipset business in mobile space. Qualcomm and other players dominated the mobile chipset market3 . Nintendo was the leading game player in 32-bit games while Sega became the dominant player in 64-bit games and Nintendo lost the battle in 64-bit games. Likewise, Sony dominated 128-bit games and Sega lost the batter in 128- 3 Source: http://www.nasdaq.com/article/qualcomm-leads-mobile-baseband-chipset-market-analyst-blog- cm367305

×