Pragmatic Guide for GREAT Product Roadmapping

I consolidate all my recent blog articles related to preparation of product roadmap into a .PDF document and uploaded it to slideshare. Please take a look and let me know your feedback.

The eBook could be directly downloaded by SlideShare

Measuring the efficacy of product roadmap

Product roadmap is one of the most critical elements that determine the long term success of the product and if it cannot be measured, it cannot be improved. To measure anything, we need to set goals. I have already outlined that product roadmap is a plan of execution to accomplish product objectives. There would be a timeframe to accomplish the product objectives and Product Manager has to periodically assess how product roadmap is contributing to the realization of product objectives. Product objectives could be targets related to either revenue, growth etc.

Understanding customer needs and addressing the needs that are valued most by customers is a means to achieving product objectives but it is not the only means. I always maintained that merit of the product contributes utmost 50% (or little higher but definitely not 100%) to a successful sale. In any selling process, customer evaluates the product against certain set of attributes. The attributes include both product and non-product; both of them jointly influence the selling process. For instance, in case of restaurant where food is considered a product, the ambience and the location of the restaurant is as important as the taste of the food. In case of B2C, marketing play a critical role in communicating the value of the product and establishing an emotional connect. In case of B2B, the existence of reliable support system, brand, and distribution network are other important factors that complement the core product. So establishing a direct causal and effect relation between product roadmap and product objectives is not foolproof. Therefore in addition to using product objectives as a means to measure efficacy of product roadmap, I am also advocating the use of feature usage metric.

During prioritization of product requirements, I indicated about the need to pick right product attributes that are valued most by customer and assign appropriate weights. While measuring the efficacy of product roadmap, the single most important criteria is to evaluate whether Product Manager has picked the right product attributes that will influence the selling process. Two methodologies indicated earlier will be used to measure the efficacy of product roadmap and to provide reinforcing feedback back into product requirements prioritization process, so right product attributes could be used to prioritize requirements that are valued most by customers.

Product objectives (aka goal) metrics

The purpose is not to validate whether we have accomplished the objectives, but to ascertain the progress and identify whether the product is on the right track to accomplish the objectives. If the product is indeed on the right track to accomplishing the objectives, Product Manager can presume that roadmap has played it role because existence of both product and non-product attributes is mandatory to a successful sale. Even so, Product Manager has to understand whether customers are buying the product for the same reasons that Product Manager has envisaged. If customers are buying the product for its reliability and price while Product Manager assuming that customers are valuing the product for its design and usability might not be a nice situation because any further prioritization decisions will be focused more on design and usability instead of reliability. Each customer will have their own reasons and no two customers are alike. Yet, Product Manager has to wisely choose a sample of customers and understand the common patterns that will influence their buying behavior.

Similar exercise needs to be done if the product is far from realizing the product objectives as well. Product Manager should always identify the reasons behind success and failure. Product Manager has to analyze the losses to determine whether there is lack of proper understanding of the product attributes that are valued most by customers and reinforce the feedback back into the product prioritization process to evolve the product with right set of requirements.

Measuring product objectives

Feature usage metrics

The idea of feature usage metrics is to understand whether top prioritized features are most used by customers. If not, something might be terribly going wrong with the product prioritization process. The primary premise of the exercise is that customers use features that are really useful for them. They do not use features just because they are available on the product. Not every product would have a direct mechanism to understand on how many customers are using each feature, in such scenario I normally take the help of support system. Please take a look at my earlier blog post to understand how support data can be gleaned to derive feature usage metrics. Feature usage metrics will reflect the efficiency of product requirements prioritization process. Product Manager can use those metrics to revisit the prioritization process whether (s)he is choosing right attributes (product attributes are already defined in ‘Prioritizing product requirements’ blog) to identify requirements that are valued most by customers. In this methodology, the underlying assumption is that the customer is aware of all the features available in the product and lack of usage of any features is not due to unawareness.

Gauge the mood – Measure the perception

I would not call it as a methodology as it is more subjective and in general it does not indicate any thing specifically about the prioritization process and effectiveness of the chosen attributes. This methodology is to measure the perception of everyone (primarily customers) especially when the business model supports sharing of product roadmap. When Product Manager shares the roadmap with customers and elaborates about what will be made available in the product over the next couple of years, Product Manager really needs to understand the reaction of customer. Do customers get excited and enquire eagerly of what is being made available or just don’t react or express anguish over the inability of product roadmap to match their business requirements. As I have been stating all along, no two customers are alike, so look for generalized reaction of broader set of customers.

Perception of customers reflects in their actions and therefore measuring the perception is critical to make customers invest in the product. Perception sometimes contradicts the ground reality and if it does so in a negative way, nothing could be more disastrous. The ground reality might be that the product is at the fore-front of innovation and perfectly evolving to meet the business challenges of customers. If customer(s) perception about the product is contradictory and it would obviously reflects in their decision to invest on the product. Customer visits, escalations are quite a few ways to measure the perception and same could be achieved through product roadmap presentations as well.

Promising product roadmap creates positive vibes among internal stakeholders too (more importantly engineering and sales team). Present the roadmap to them as well. I have earlier talked about leveraging the expertise and experience of sales and engineering team to discover customer needs, so it is only appropriate to share the roadmap throwing signals that preparing roadmap is an inclusive approach. Take their feedback and gauge their perception as well, product roadmap should motivate engineering team to build better product and sales team to sell more. Internal stakeholders should be excited about the product roadmap and should be convinced about the direction in which product is heading.

Prioritizing product requirements in alignment with product objectives

In all my earlier blogs, I was focusing on discovering and anticipating needs and who can help Product Manager discover those needs. After Product Manager collate all possible needs and start drafting requirements, there will not be dearth of product requirements but the next challenge is to prioritize those requirements. Product roadmap is a reflection of the product strategy and rightly so, product strategy should provide guidelines on what requirements to prioritize and it should also provide justification on why those requirements have to be prioritized.

Identifying Product objectives (aka Goals)

Product vision is the foundation for any product. Product vision encompasses everything related to the product – who are the customers, what does the product do, what is the competitive edge of the product, what is the unfair advantage that product has over competitors and finally what are the product objectives (how does the product help accomplish organizational goals). Rightly so, product vision provides guidance for every decision making related to the product – How sales should sell the product, how engineers should build the product, how marketing should promote the product and how Product Manager should draft the product strategy. Product strategy outlines the path to accomplishing product objectives abiding by guidelines laid by product vision. Let me revisit the product vision again and dissect it. At a high level, product vision embodies the following:

  • What needs to address?
  • Which customer segments to target?
  • What is the USP of the product? How effectively does the product will address the needs?
  • How the value is captured?

A little deeper look will reveal that product vision has 2 broad categories

  1. Product purpose
  2. Product objectives

Product Vision

Product Purpose (Customer Centric) Product Objectives (Organization Centric)
·        What needs to address?·        Which customer segments to target?

·        What is the USP of the product? How effectively does the product will address the needs?

·        How the value is captured?-   Increase in profits

–   Expansion into new markets

–   Opportunity to cross sell other products etc

 

Product purpose and Product objectives do change as the customer needs evolve, organization growth objectives change and product traverses through various stages of the product life cycle (launch, maturity and decline). Understand from your CEO or VP Product Management, how the product should contribute to overall organizational goals, accordingly Product Manager has to formulate product objectives. Product Manager would later perform thorough analysis of customer, market, competition and technology to understand what kind of augmented needs are valued most by customers and how effectively do those needs has to be addressed to achieve product objectives. In short, product prioritization process is all about identifying the set of requirements that fits within the framework of product purpose and yet has the potential to collectively accomplish product objectives.

Identifying attributes

When Product Manager starts prioritizing requirements, there should be an effective mechanism to understand how each requirement contributes to both product purpose and objectives. So we identify attributes (related to both purpose and objectives) that can help measure how each requirement is contributing to the overall product vision.

Attributes of product purpose

Product addresses lots of needs, but there should be some primary needs that focus on the key pain points of the customers. I call them as core services and rest of them are allied services. List some of the core services as attributes. For the sake of discussions, let me assume a fictitious B2B IoT product targeted for retail stores that help in following

  • Insight – Provides insights on how customers are accessing the store
  • Generate revenue – Notifies customers through smartphone about the availability of goods that might interest them based on the behavioral pattern
  • Cut costs – Eliminates the need for sales person by flashing all information about goods on his/her smartphone
  • Operations – Aid in ordering of goods that are brought together (replicate Amazon model)
  • USP – Does the requirement contribute to enhancing the USP? In case of the fictitious product, the USP could be as simple as ‘easy to use’, ‘easy to maintain’, ‘compatible with all mobile devices’, ‘mobile payment to avoid long queues’ etc

Pick relevant attributes that represent the augmented needs and assign weights in accordance with how customers value them. Efficacy of product prioritization process lay in effectively picking the attributes that are valued most by the target customers. Existences of those attributes in the product should provide compelling reasons for target customers to buy the product.

Attributes of product objectives

Product manager identifies similar attributes for product objectives as well.

  • Revenue – Does the requirement directly contribute to increase in revenue
  • Customer – Does the requirement is applicable to all possible target segments or to only a section of target segment. It is an essential attribute if the focus is on expanding market
  • Competition – Does the requirement provides competitive edge or merely puts the product on par with competition
  • Cross sell – Does the requirement facilitate sale of other products
  • Stickiness – Does the requirement increase the switch over costs or create a stickiness factor facilitating recurring revenues

I have dropped down all possible attributes that I could imagine. I suppose it would be ideal to stick with utmost 3 attributes in purpose and utmost 2 attributes in objectives, otherwise the weights would be thinly scattered and it might be difficult to effectively prioritize the requirements.

Scorecard technique – Brainstorming

Every product would have a distributed team of Product Managers, each managing different components of a product or separate target markets or combination of both. The process of adding weights combined with brainstorming exercise would ensure that the respective Product Managers have done due diligence in evaluating each of their requirements, so relative prioritization could be done lot better.

There is no better option than brainstorming to discuss, debate, and argue on the ability of each of the requirement to contribute to product objectives. Brainstorming session when done effectively provide revelations that was not comprehended before by the Product Manager or rather by any other participant. How many times have we felt ‘Oh GOD, I never thought about it’! Brainstorming would help to identify such facets never thought earlier when done effectively. Efficacy of brainstorming sessions lies in the following

  • Each participant should challenge and be willing to be challenged.
  • Each participant should build upon the thoughts of other to add better clarity to ‘WHAT’ and ‘WHY’ of each requirement.
  • There should be a commonality of purpose, vision and direction among all the participants
  • Each participant should engage in dialogue. In dialogue participants aim for collective good and not for win of any specific participant
  • The session should be skillfully facilitated by one of the Product Manager

Much of what I had described above was borrowed from a book called ‘The Fifth Discipline’ by Peter M Senge, the book offers lots of tips for effective and efficient brainstorming session.

The process might be chaotic, exhausting and mostly Product Manager might feel tired about justifying each need. Yet such process adds pluralism ensuring healthy discussions and debates among divergent minds leaving no room for human errors in prioritizing requirements. The exercise is also an attempt to prove everyone that product requirements prioritization exercise is driven by a process backed with data and does not happen as per whims and fancies of the Product Manager.

It is also on opportunity to introduce BIG PICTURE to the engineering team:

  • What are the lists of product requirements?
  • Which segment of customers need those product requirements?
  • Why do the customers need each of those product requirements? What specific business challenges or pain points would be addressed by each of those product requirements?

I often insist that engineering should inculcate system thinking to have a holistic view of how each component in the product inter-operate to deliver value to customers. Engineering should be aware of the customers using the product and what are the essential needs for which the product is used. Unless engineering imbibe those details, I could only foresee lots of friction between what they should develop and what they develop. Including them early in the prioritization process is one way to reduce the friction even though I insist that during on boarding process of every engineer into the product team, (s)he has to undergo detailed training on (i) what is the product, (iii) who uses the product, (ii) why the customers are using the product, in addition to the regular agenda of (iii) how the product is built.

Involving engineering early in the process helps them obtain the bigger picture to avoid any ambiguity during development, estimate efforts required to address the requirements and most importantly Product Manager tries to instill a sense ownership highlighting that their comments are valuable to evolve the product. Making engineering realize that delivering right product is the priority and not delivering product right. Constantly attribute success of the product to their efforts and make them realize that they are entitled to demand more details from their Product Manager on why certain features are prioritized and for whom as much as Product Manager has every right to ruthlessly demand more from engineering team.

End of the brainstorming session, scorecard would be completed with appropriate weights for each of the requirements for all possible attributes. Further every stakeholder would be on the same page with regard to prioritization process. Remember, I was talking about inclusive approach to product requirements prioritization process under discovering needs section so every stakeholder would feel they are valued and they have better clarity on how requirements are prioritized. Guess there is no better technique than brainstorming to achieve an inclusive approach.

Why I don’t use scorecard methodology?

Wonderful… we got a scorecard that can let Product Manager pick the ‘top X’ requirements. But wait, did I ever say I will be using scorecard methodology to prioritize features. With all due respect, scorecard is an excellent methodology that helps Product Manager to ponder and diligently assess how each product requirement can help achieve product objectives. Yet, I do not rely blindly on scorecard methodology or any methodology. I merely use them as reference to understand the relative importance of each requirement under a specific category to make effective prioritization decisions. Let me assume for a moment that the primary product objective is to generate more revenues, so obviously revenue attribute would carry relatively higher weights along with other attributes corresponding to the product needs that are valued most by customers and can either directly or indirectly contribute to increase in revenues. If we apply scorecard, undeniably all the features that contribute to increase in revenue will be prioritized and Product Manager would have done a fantastic job.

Nevertheless did I not discuss in length about being market focus – delivering requirements that might excite customers, generate demand, attack growth. I also discussed about imbibing new technology to stay ahead of the curve and ensure the competitiveness of the product. Focusing on them (WoW requirements, new technology) will fetch revenue in long run in addition to allowing the product elude strategic inflection point. Customers will be glad to have those value adders but they would never ask for them explicitly. Scorecard methodology will not be able to strike a balance between short term and long term requirements.

For those exact reasons, I have earlier attempted to categorize the requirements as i) tactical, ii) strategic and iii) disruptor. In addition to avoid prioritization conflicts between requirements in each of those categories, I strongly advocated the need to allocate a portion of product roadmap for strategic and disruptor. In spite of all the categorization, I am still not convinced with using scorecard technique for prioritization of requirements within each category. Prioritization is more of an art than science, so employing pure scientific methodology might be disastrous. Even though I use scorecard techniques to ensure that I have done my due diligence in understanding how each requirement contributes to both product purpose and objectives, I firmly believe that common sense prevails over scorecard methodology.

In addition, prioritization of strategic and disruptor features is done after evaluating the degree of uncertainty and amount of efforts required to build product increment to eliminate uncertainty. Attributes and weights do not work in this situation. Little gut feeling and thorough analysis of the amount of efforts required to eliminate uncertainty, extent of risk and amount of efforts required to deliver product increments (apply lean techniques) plays a vital role in selecting requirements under strategic and disruptor category.

How to prioritize smaller features

I call them as low hanging requirement that will deliver reasonable value to customers and does not take too much effort to deliver them. Those requirements are not deal breakers but definitely good to have. When the small features are pitted against bigger ones, they would never find space in the roadmap. In OS, I could recollect the concepts of starvation wherein OS would employ aging technique to avoid any low priority process from resource starvation. I would be glad to employ such aging techniques; nevertheless I am not heading in that direction. Product Manager has to negotiate with engineering team to prioritize such features without impacting the original set. The efforts are little less in delivering those features and the risk to overall development would be minimal, engineering team can deliver those features by optimizing their development and test cycles.

Roles, responsibilities, authority, hierarchy etc nothing would help Product Manager to have his way as much as personal relationship does. The relationship between engineering team and Product Manager should be symbiotic in nature. Product Manager has to offer something before asking for favors. Among many other things that Product Manager can do to let engineering focus on what they do best in most optimal way is to

  • Add lot more clarity to the requirements (ensure it is actionable)
  • Freeze the requirements and clarify on all the open items before start of the development
  • Do not let engineering team wait on Product Manager for prioritization decisions.
  • Remove any obstacles or deviations that is clogging the development or test activities

I always believe in the principle ‘Do it right the 1st time’. The above activities of Product Manager would definitely aid engineering team to head in that direction and facilitate them to do ‘Deliver more (features) with less (resources)’.

Prioritizing defects vs requirements

I have seen some debate on how to prioritize defects against product requirements. Now my belief is that both are different and quality precedes everything. Yet Product Manager does not pit defects against product requirements. No product is defect free and every requirement added to the product begets defects. Product Manager would collaborate with engineering team to determine the tolerance level for the overall open defects or defects open rate and accordingly allocate a window open in each release for resolving defects avoiding any conflict with product requirements. Ultimately it is the responsibility of engineering team to prioritize and resolve defects within that window. I firmly believe that engineering team owns ‘Product Quality’ and they should have complete authority to mark the severity of the defects and resolve them within the guidelines of quality SLA. Product manager will be encroaching into the engineering space, if (s)he starts prioritizing the defects.

Why product roadmap?

This article is a 2nd part in the series of blog post on ‘A practical guide to product roadmapping’. In this blog, i am focusing on the importance and need for product roadmap

1st part – A practical guide to product roadmap – What is product roadmap?

Why Product Roadmap

Every product has one or more of the below mentioned objectives

  • Drive profitability
  • Diversification or Expansion into new market segments
  • Increase market share
  • Increase registered users (typically for online products).

Product Manager would then outline a product strategy that defines how the product line will be evolved to meet those objectives after thoroughly performing market analysis, customer analysis and competitive analysis etc. What is the role of Product roadmap then? Product roadmap is the single most important document that provides a blue print of the overall plan in alignment with product strategy to either add exciting features to existing product(s) or add new product(s). Product roadmap describes how the product line will be exactly evolved over a specific time period and it ensures that all the stakeholders are unambiguously informed about the product objectives and how those objectives will be accomplished. Further product roadmap would essentially act as foundation in decision making process of any of the stakeholders (Sales Managers, BDMs, and Account Managers etc). For instance, if the overall objective is to drive profitability then the team can look forward to increase the overall sales margins by cutting down the discounts. If the overall objective is to purely expand into new markets, then team can focus on selling more possibly at the expense of margins.

Lack of product roadmap is akin to the famous quota 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 letting all the stakeholders steer the product in different conflicting directions without any purpose or objective. Every product release would be filled with small set of insignificant features or features that require less effort and bug fixes. The impact might not be felt immediately, but slowly and steadily the sales would decline, rate of new deals acquisition dwindles, gap widens with competitors products, customers whine about lack of features that really excite them and they lose confidence to further invest in the product.

It is highly imperative that product roadmap had to be driven and prepared meticulously by the Product Manager consulting all the relevant stakeholders (customers, development team, sales, BDM etc) in a compelling manner such that the product roadmap reflect product growth strategy. Please be aware that product roadmap is just a plan and not a commitment, so every product manager should add necessary disclaimer to the product roadmap providing sufficient indications that product roadmap is prone to changes.

In the next part, i will talk about the various purposes of product roadmap.