Should Product Manager prioritize defects?

I have seen many debates on Quora and other related forums regarding how Product Managers should prioritize defects against product requirements. Now my belief is that both are different and I am a firm believer in ‘Engineering owns quality’. Even though quality precedes everything, Product Manager does not pitch defects against product requirements. No product is defect free and every requirement added to the product begets more defects. Product Manager would collaborate with engineering team to determine the tolerance level for the overall open defects or defects open rate. Accordingly, allocate a window 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. Engineering team should have complete authority over prioritization of defects and resolve them within the guidelines of quality SLAs (Service Level Agreements) even it is a severity defect affecting customers’ business. Product Manager will be encroaching into their space, if (s)he starts prioritizing defects.

I would definitely loathe if my engineering team is busy fixing defects at the cost of evolving the product. As I had said earlier, both engineering team and Product Manager should agree on the tolerance level for defects, if occasionally the defect rate goes higher because of certain unforeseen reasons, I would urge Product Manager to make more room for resolving defects probably at the expense of not addressing few requirements. However, if it happens too often, then the problem is addressed by identifying the actual root cause. What is causing more defects and what is causing the decline in quality should be ascertained to improve quality in a long run instead of continuing fixing defects at the expense of evolving the product. It is as important to continuously evolve the product as it is to maintain the quality of the product. There cannot be any trade-off between them.

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

How to avoid customers from hijacking the product roadmap

I have talked about prioritizing requirements to list them in chronological order in product roadmap. Product Manager diligently prepares the product roadmap to reflect the product growth strategy. Nevertheless nothing works as per the plan. First roadblock that every PM face is some unexpected product requirement requests from their customers and that product requirement will be total deviation from the items planned in the roadmap.

I bet every Product Manager would face this situation on every day basis. So how do Product Managers stop their customers from hijacking the product roadmap? Before Product Manager definitely puts his/her foot down and say NO irrespective of revenue contributing potential of the customer, I shall suggest Product Manager to follow the following steps (aka decision tree) to mitigate the situation in a way that it is win-win for both Customer and Product Manager.

The entire exercise might not be required if the business model is to entertain customizations or handle specific customer requirements for additional $$$.

Step 1: Understand the requirement – WHY?

It does not suffice if Product Manager just knows what the requirement is. (S)He needs to have a broader understanding of why customer has asked for the requirement. Unless Product Manager gets a grasp of the underlying reason or cause behind the product requirement, (s)he will not be able to make informed decisions in the subsequent steps.

Also please take a look at my blog on ‘Understanding customer requirements’.

Step 2: Validate the requirement

Is the requirement valid? In certain cases (mostly in B2B environment) because of lack of product awareness or technology, customer raises product requirement that is either invalid or not feasible within the scope of the product. If the requirement is invalid we should definitely make attempts to immediately communicate the information back to the customer with appropriate reasoning.

Step 3: Understand the business criticality

Understand the potential business impact to the customer because of not fulfilling the product requirement. Is the requirement has any potential revenue impact or is it just to enhance the usability of the product or is it just nice to have a feature. In case of revenue impact, the stakes for delivering the product requirement goes HIGHER.

Step 4: Identify alternate (optimal) mechanisms to accomplish the requirement using existing infra of the product

In the initial step, I suggested to look for the actual reasons behind the requirements ie Product Manager needs to understand the WHY part of the requirement in addition to WHAT part of the requirement. Having known the WHY part, Product Manager needs to figure out whether there is any alternate optimal mechanisms to address the WHY using existing product infra. If yes, communicate the alternate mechanisms to the customer provided Product Manager gets convinced that the alternate mechanism is actually the optimal way of addressing WHY.

In case of no alternate mechanism to address the requirement, let us proceed with next steps.

Step 5: Is the requirement generic or customized

Is product requirement custom or generic? Understand whether the requirement is customized to the requested customer or it can be generalized for broader segment of customers. In case of generic, Product Manager could not have discovered the need and it is good that some customer had brought this to his/her attention. Product Manager now adds the requirement to the requirements backlog, the timeline to deliver could be figured out depending on the business criticality and requirements prioritization process. In fact, I have talked in detail about how to prioritize requirements in in my earlier blog. If the delivery timeline conflicts with the expectations of the customer, then Product Manager has to negotiate – move to step 7.

Step 6: Understand other additional requirements of customer

We have reached this step because the product requirement is customized. In case of customized product requirement, please do not look at the requirement in isolation. Take a look at other requirements from that customer, also take a look at the requirements available in the roadmap and figure out how many of them would be applicable to the requested customer.

Step 7: Negotiate

Identify possibilities to trade the customer requirement with any of the generic requirement(s) already available in the product roadmap. Even if the customer requirement is critical, as long as Product Manager is able to compensate with other requirements that matter most to the customer, it would definitely be a WIN-WIN situation. If someone insists there is nothing to compensate and there is no product requirement in the roadmap that would suit the customer, then I could only think 2 possibilities (i) our understanding of the customer is flawed (ii) customer does not actually belong to the target customer. Please note that it is worthy to forego a sale rather than selling to a wrong customer, this topic definitely needs more attention.

Final Thoughts

Earning the trust and credibility of the customer is mandatory to engage in a meaningful conversation and to communicate the NO for any product requirement request in a convincing manner.

Managing product requirement backlog

Discovery of needs is a continuous activity that would span across 365*24*7 and there is never an end to the process. While discovering needs, I would insist to focus on quantity and not on authenticity or veracity of the needs. I don’t mind digging my way through maze to find the most valuable needs to incorporate in the product, but I hate or rather dread to encounter competition spotting a need that was missed by the team. So I always advocate collating as many needs as possible from various entities (Engineering, Sales, BDMs, and Account Managers etc) as they could possibly perceive and understand.

Record needs

In the initial section of this document, I had elaborated about need vs requirement. I would prefer to document the needs as it is in the product backlog tool. As I indicated in my definition of need vs requirement, the requirement is outlined from engineering perspective while need is outlined from customer perspective. Therefore the ideal location to translate need into requirement and record it is in PRD. The appropriate timeframe to translate the need into requirements is while drafting the PRD. The methodology to store the needs could be the prerogative of the Product Manager. There are lots of tools to store the needs. For convenience, let me assume that Product Manager uses excel.

While discovering needs and recording them in the product backlog tool is a continuous activity, Product Manager periodically gets into the below mentioned sequence of linear activities before the start of each release

  1. Needs triage
  2. Categorize needs
  3. Refine needs
  4. Draft the PRD
  5. Prioritize requirements
  6. Organize product backlog

The entire sequence of activities has to be planned in such a way that on the 1st day of the development work for next release, the Product Manager should clearly outline the list of prioritized requirements for the upcoming release. I repeatedly insist that the list should be actionable and well-articulated, so development team does not get into repeated cycles of requirement clarification. The primary purpose of development team is to either build or evolve products. Product Manager will plan his activities meticulously to let the development team focus on what they do best. The worst thing that could happen is development team hanging on Product Manager for requirements clarifications, decision making etc.

Product requirement backlog

Needs triage

I derived the title for this section from ‘Bugs triage’. It is similar to bugs triage conducted by engineering team. Product Manager has to analyze each need and categorize the need. The entire purpose of needs triage is to identify the subset of needs that is worth prioritizing for the upcoming release.

Categorize needs

The outcome of needs triage is to filter them under one of the possible categories

  1. Discarded – The needs under this category are not worth pursuing further for one of the following reasons
  • Duplicate – Already tracked through another need or rather combined with another need
  • Product currently has the capability to address the need – In addition to discarding the need, there is a necessity to educate the requested customer(s) how their need could be addressed using existing product capabilities
  • Does not align with overall purpose of the product
  • Not feasible – The need could not be addressed by the product, the decision is taken after careful evaluation with engineering team. Even before handing over the requirements to engineering in the form of PRD, there can be little informal discussions around the needs.
  • Age out – The need exists in product backlog for a long time and no customer seems to be interested in it and it does not even fall under ‘Parked for future’ category, so the need ages out. Discarded automatically after existing in the backlog for a certain time period, the time frame should be defined by the Product Manager depending on the nature of the product.
  1. Parked for future – As the heading implies, the need is reserved for future triage
  • Existence of dependent need or infra – The need could only be addressed after addressing a dependent need or providing support for dependent infrastructure.
  • Ahead of its time – There would be always a reason for Steve Jobs introduce iPhone first and iPad latter. Some suggest that iPhone is introduced earlier to validate the touch behavior of the users. Irrespective of the reason, not only products but also every individual requirement has to be validated for its timing. If the timing is not right, the requirement has to be parked for later prioritization.
  1. To be prioritized – The needs under this category will be converted into requirements added to PRD and will prioritized for the upcoming release. The requirements under this category will undergo the prioritization process explained earlier.

Refine needs

Once the list of ‘To be prioritized needs’ are derived. Ensure each of the need has sufficient information to be translated into a requirement. In addition, categorize the need into i) tactical, ii) strategic or iii) disruptor. For more clarity and inputs, please refer to ‘Categorizing requirements’ section

Draft the PRD

Remember the tenets of requirements, Product Manager has to ensure that each requirement has ‘WHAT’ and ‘WHY’, most importantly ‘CONTEXT’ as well. Product Manager has to strive to make each requirement as detailed as possible and ensure that the requirements are actionable as well. Immediately after drafting all the requirements in the PRD, share the PRD with engineering team to facilitate further discussions on the each of the requirements.

Prioritize the requirements

Drafting requirements and deriving solution to address those requirements does not happen in linear fashion, while discussing the requirements with engineering based on their inputs certain requirements take even better shape. Exactly for those reasons, Product Manager has to complete the exercise of drafting the PRD at least 3-4 weeks before the start of the development and use remaining 3-4 weeks for brainstorming with engineering and rest of the stakeholders for crystalizing and refining each of the requirements. After all the requirements are refined, Product Manager has to derive the prioritized list of requirements for the upcoming release.

Organize backlog

Entire set of needs under product backlog are classified into 3 broader categories

  • Open
  • Completed
  • Ongoing

If I use excel for maintaining product backlog, I maintain 3 tabs for each of the above categories. Under the open category, I would classify entire needs as identified below and use color codes for differentiation. Next time Product Manager attempts to triage, (s)he need not triage all the needs, instead triage the needs color coded in RED and ORANGE

Triaged Needs
Not Triaged Needs
Parked for Future Needs

Completed category would have all the needs incorporated into the product along with the release numbering. I use this list as a reference to identify the list of needs incorporated in each release or identify the release in which a specific need was addressed.

Ongoing category would have all the needs addressed in the ongoing release. After finalizing the list of needs to be addressed in the ongoing release, I will move the contents of previous release from ongoing to completed category and update the release number in which those needs are addressed. Later move the prioritized list of needs in the ongoing release from open category to ongoing category.

Categorizing requirements backlog

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.

Deadly mistakes to avoid in prioritizing requirements

Scorecard technique had mostly helped me to eliminate all possible mistakes committed during prioritizing requirements, however not everyone does follow scorecard technique. So I thought it would be appropriate to list down all possible blunders that could be committed by the Product Manager while prioritizing requirements.

  • Prioritizing product requirements purely based on revenue potential

It is always nice to focus on requirements that have higher revenue generating potential as revenue is possibly one of the most important reasons for existence of the product. Ironically, Product Managers are also evaluated primarily on the revenue generated rather than on the strategic activities that can possibly have positive implications on the long term. Guess it is a different topic for discussions. Now coming back to our original topic, Product Manager should not get too much obsessed with revenues losing sight of the long term objectives. Without revenues, management would cut down the resources and Product Manager would be left with no resources to evolve the product. The ideal scenario for a Product Manager is to adeptly balance both short term and long term priorities while ensuring steady flow of revenue.

  • Prioritizing product requirements of customer with loud voice

Customer with loud voice often have their way through escalation or making noises at right place to right people. It is always easy for Product Manager to succumb to the pressures, but it might not end with just one request and the trend might continue. If the product requirements of such customer are reasonable then there is no trouble, but prioritizing a requirement just because someone is exerting pressure is not an ideal scenario. It is better to nip such requests in the bud without yielding to the pressure outlining the implications of acknowledging such requirements to the management. In a latter blog post, I will outlined some actionable points on how to say ‘NO’ to customers hijacking the product roadmap in a convincing manner without antagonizing them.

  • Prioritizing product requirements concurring with engineering team

Product Manager can have two possible types of engineering team (i) Sluggish and (ii) Motivated. Either way it would be trouble managing them.

Sluggish team

They always look for reason to turn down high effort requirements and probably enjoy basking themselves committing to low effort requirements. They are mostly risk averse. Product Manager should primarily be ruthless while dealing with sluggish team.

Motivated team

They are enamored by the technology and mostly look forward to do stuff that is cool. They enjoy being challenged by complex problems. Their aspiration is around technology and not around customers. Product Managers should always stay on top of them to guide and steer their efforts in appropriate direction that adds lot of value to customers.

You cease to exist as a Product Manager if you let engineer take a decision on prioritizing the requirement for simple reasons that you are either lazy or could not grasp technical nuances to understand what value is rendered by the requirement to customer business environment and how the requirement is aligned with overall product purpose. Product Manager is a gatekeeper of the product and (s)he should be aware of every change made to the product.

  • Prioritizing product requirements because you (Product Manager) felt that those requirements add value to the customer

Being a hands-on Product Manager is a nice quality and I do insist on Product Managers getting their hands dirty with the product, so Product Manager can independently evaluate the product gaps when trying to understand the customer needs without troubling development team. Such hands-on quality will also allow Product Manager to independently identify product gaps, however the requirements has to be judiciously prioritized after gaining a thorough understanding of what kind of value could be rendered by those requirements to customers.

Product Manager should step aside for a while and move to other side of the fence to evaluate whether the requirement would be valued by customers and try to estimate the amount of value rendered to the customer. There should not be any bias towards the requirement identified by the Product Manager while prioritizing the entire gamut of product requirements for each release.

  • Prioritizing product requirements of the user instead of the buyer

User and buyer are two different entities in case of B2B product. In most cases, Product Manager would talk to both buyer and user. While buyer can throw light about his/her potential business challenges, user can throw light about his/her experiences using the product and how the product could be further improved. I am not advocating that Product Manager should only prioritize buyer needs over user needs, even though buyer needs gain relatively higher priority as those needs directly impact the customer business. I would rather insist that Product Manager should appropriately recognize the role of the entity communicating the need and prioritize the need at the face value of it by determining whether the need is merely enhancing the usability of the product or addressing any critical business challenges.

  • Prioritizing requirements without a common theme

Theme is a unifying factor for majority of the product requirements prioritized in each release. Why do we need a theme or unifying factor for each release? Each person might have their own views on the need for themes, some outline that themes help in better prioritization. At least, I opine that themes help in better marketing of the product release. If the product requirements are cluttered across multiple areas such as usability, performance, stability etc., it would be tough to construct a unified message to indicate the value delivered by each release. I have earlier talked about identifying product objectives and attributes, later measure how each requirement is performing against those attributes. Using such methodology will ensure that majority of the features can be grouped under one or two product attributes and those attributes can provide some unifying theme for the entire release. I basically derive the theme from the list of prioritized features.

Certain experts do recommend to list down themes and start prioritizing requirements based on themes. Alternately list down all the prioritized requirements and categorize them into themes, later deliver requirements of 1 or 2 themes in each release. Honestly there is no right or wrong approach. Even the scorecard methodology that I had outlined in the previous section will let the Product Manager indirectly prioritize requirements based on themes through assigning more weights to specific product attributes.

  • Prioritizing requirements yielding to the pressures of sales team

Sales Manager is one of the stake holders that can communicate product requirements because they interface with customers regularly and keep tab of their expansion plans. While communicating product requirements, Sales Manager attach revenue figures to aid Product Manager better prioritize the requirements. In most cases, the revenue figure would be most optimistic and it might not often reflect the real potential. Least in some cases, the revenue would not realize even after delivering the requirements. Yet Product Manager has to gamble especially if the revenues are drying, however (s)he can go for calculated gamble instead of purely relying on the data provided by the sales manager.

  1. Does customer has compelling reasons to buy our product?
  2. Is customer evaluating any competition?
  3. What is the past history of the customer? Do they consistently buy our product or just get their job done under the veil of promising revenue opportunities?

In a different scenario, Sales Manager will close certain deals promising few requirements on roadmap even though roadmap is a plan and not a commitment. In such cases, Product Manager would add exceptions to provide a commitment to customers. Product Manager should not allow Sales managers to make the promise. Instead Product Manager should analyze all the customer requirements and after careful evaluation of already planned activities should make the promise to the customer. Basically Product Manager should be confident enough to make the commitment.

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.

Collaborative discovery of customer needs – Who can participate?

As a Product Manager, one of the constant fears that I have is: Competition identifying a need before I or my peers do – Honestly, I don’t feel bad about it. Such situation 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. Product Managers are always outnumbered in an organization by Engineering, Sales, Account Manager, BDMs etc. One best piece of advice that I received from my manager 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 stake holders to perform his/ her activities.

Impact: Collaborate effectively with all the stake holders to discover needs

[PS: Please read my earlier blog post on the need to discover customer needs]

Product Manager is not a lone entity while (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 fact is Product Manager does not have authority to demand that every stake holder has to discover need and Product Manager cannot set goals for discovery of needs. What I have mostly seen is that when Product Manager walks that extra mile to facilitate Sales Manager close the deal, help Account Manager maintain better relations with their customers, and aid Development team to build products faster, the entire stakeholder too walk that extra mile in assisting the Product Manager.

To better know how each stakeholder can help Product Manager in discovering needs and what kinds of needs can they discover, I have provided some illustrations and it would provide some idea on the kind of needs that each stakeholder can discover

Needs from support team

  • Product/ Non-product enhancements (Usability/ Features/ Documentation etc)

YouTube changed the VIEWS variable to 64 bit to accommodate more than 2 billion views as ‘Gangnam Style‘ video by PSY was viewed more than 2 billion times (source: https://plus.google.com/u/0/wm/4/+youtube/posts/BUXfdWqu86Q). Every product is initially created 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. Customer 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.

Support team is also equipped to analyze the support cases and understand the trends to figure out the most common issues faced by the customers, such analysis can help Product Manager understand the list of needs that is not optimally solved by the product. Any improvements can lead to better customer satisfaction 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 to ponder upon the following

  1. 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
  2. The feature is not intuitive – The feature might be working properly but customers are increasingly finding it difficult to operate. Either the feature is not intuitive (usability constraints) or documentation is not clear. From the perspective of HW product, documentation often plays a key role
  3. The feature is incomplete – The customer needs are not fully met, wakeup call for Product Manager as the customer needs are not properly analyzed. Product Manager needs to take quick remedial action to bridge the gap between customer needs and product capabilities ASAP.
  • 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 either new use cases independently through innovative changes in configuration or 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 complete functionalities of the product to resolve the challenges faced by them. Such customers constantly pose technical challenges and help Product Managers build better products which eventually puts us ahead of the competition. Personally it is good to have such customers and my opinion is that they are worth more than a million dollar customer.

Support engineers when consciously look out for such unique use-cases or solutions through the aid of support cases can help Product Manager 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 for 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 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 vents their ire on lack of any features that should have been available in the product by default. In B2C, customers do not think twice to raise their concerns through social media. If your support system does not have the facility to track the digital foot print for such messages, comfortably fall back on ‘Google Alerts’ to track.

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 engineering teams are kept informed of the problem spaces, they can evaluate how advances in technology (probably new components in case of HW products, new algorithms) can address the customer pain points in a much better way. For instance in case of VoIP products, engineering/ folks can suggest alternate mechanisms to increase voice/video quality, reduce latency and BW required etc. For same reasons, it is always better to let engineering team provide outside view of the world. Engineering team has to be updated with details about competition, customers, wins & loses, what differentiates our product from the rest.

To further illustrate the importance of working with 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 adaption rate of new technology. I saw performance as one of the primary roadblock for customers from adopting virtualized product. Engineering team did throw lots of ideas on how to improve performance and in fact they did introduce me to docker technology. Docker technology is gaining ground and engineering team did keep me informed on how it work and the potential advantages over virtualization. I could leverage the technical details provided by the engineering team to understand how docker can help provide better value to customers. End of the day, underlying technology does not make much difference to customer as much as the value rendered by each of those technologies does.

Most would advise Product Manager to hang out with customers, sales, and account teams. I would rather insist to hang out with engineering team as well provided if you are in same location as them to build better products. When Product Manager is close to engineering team, it is better to leverage the opportunity to facilitate more frequent exchange of thoughts, ideas, problems etc. I could only say that MAGIC would be created out of such interactions and if there is distributed Product Management team, I would prefer to hand over the responsibility of building the product to the Product Manager closer to the engineering team. Such interaction might not often enable Engineering team to communicate new needs, but they can deliver solutions that can amaze customers and create a WOW feeling.

Needs from sales

No one interfaces closely with customer as much as Sales Manager does. Sales Manager can provide specific details on how each customer is using the product and they also help discover needs of individual customer. Sometimes Sales Manager can also help understand the gaps with competitor 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?
  • Why is customer whining?
  • What deals did the product lose? Is there any trend?
  • Is the product losing to any other product in the adjacency space?

Another big source is RFP that most often neglected by Product Manager to identify product needs. In case of 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 the customer. Analyzing multiple RFPs provides the direction in which customer businesses are evolving, look out for patterns of new needs and record them.

Ideally spot star Sales Manager to better know about customer needs. Star Sales Manager 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 the deeper understanding of the customer and the product combined with ability to position the product effectively at the intersection of problem and solution. Working with such Sales Manager is really a boon to understand more customer needs, further such Sales Manager 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 on 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 on the importance of pondering on the following topics:

  • 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 has 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 the variations of the product could be built 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)

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 put the product on growth trajectory will gain better knowledge about the market, trends etc. While interactions with Sales Manager(s) boil down to specific customer needs, interactions with BDMs will mostly be centered on discovering market needs.

BDMs role might not be just restricted to help discovering strategic needs, they can also play a greater role while the market is on 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 improvement in performance of new technology or identification of wide spread 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/latent need is impacting the 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 it. In certain cases, the stakeholders can merely provide some hints on the 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. The stakeholders should neither be discouraged to share any kind of information about the customer needs, pain points etc. nor be penalized or reprimanded 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 thoroughly communicating the yard sticks used for prioritization to the entire team of need discoverers for allaying any fears of unbiasedness in prioritizing the 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 case of emerging technologies such as IoT, Virtualization, Big Data etc. where the problem space is not clearly defined as technology is evolving and the applications of the technology is also evolving; culmination of engineering, domain experts, Product Managers is essential to synthesize divergent thoughts into a concrete need. Unlike in the earlier scenarios, I am focusing on structured methodology (like brainstorming) because each entity has lots of thoughts and they are worthless individually. The focus of the 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 table all the divergent thoughts including their assumptions, later participants would built upon other thoughts to provide a shape to a new product need. The scenario is akin to each one 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 has 2 challenges

  • Identify the right set of participants
  • Facilitate effective participation from all the 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 other person to ponder, to reason out their findings. Primarily ‘WHY’ should also let the other person break their assumptions. Every person has 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 will never buy clothes without touching. Execs at Nokia and BB thought mobile users will always be comfortable with QWERTY. ‘WHY’ is critical when Product Manager has to think beyond the existing needs of customers and anticipate how new technology could impact them. ‘WHY’ would dug 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 change in customer behavior. The examples that I had highlighted is related to disruptor technology as ‘WHY’ makes much larger impact, nevertheless ‘WHY’ is essential for critical understanding of tactical and strategic requirements as well.

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 facilitate an environment for free flow of needs and also information related to product (drawbacks, needs, limitations etc) from every stake holder to Product Manager. Even if any of the need sounds dumb, Product Manager should not duck 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

  • Are you approachable?
  • Are you enthusiastic about listening to ideas that resolves customer problems?
  • Are you eager to know about the new business challenges of customers?
  • Are you interested to keep yourself abreast with latest technology advancement surrounding your product? Also eager to know about the kind of implications that new technology can have on the product?
  • Do you have list of blogs or analyst data on your reading list as everyday task?
  • Do you feel spending time with engineering is your primary responsibility?
  • Do you feel bad about bad 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.

Inflection point – Seizing the opportunity through product roadmap

This blog is the 7th part in the series of blog posts related to ‘Pragmatic Guide for Preparation of GREAT Product Roadmap’

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

2nd part – Why product roadmap?

3rd part – Pragmatic purpose of product roadmap

4th part – Discovery of needs

5th part – Categorizing requirements – Tactical, strategic and disruptor

6th part – Ratio of tactical, strategic and disruptor requirements

In this part, i am elaborating about the inflection point. Inflection point is indispensable part of any product and the focus of the blog is to outline how inflection point could be tackled using product roadmap through efficient handling of technology transition.

Inflection point – Seizing the opportunity through product roadmap

Every product has an Inflection point as defined by Andy Grove in his book “Only Paranoids Can Survive”. One simple case of inflection point is technological change. Inflection point is both an opportunity (to displace incumbents) and a risk (to be displaced by new entrants or existing competitors), so it is really critical to be wary of the inflection point.

Inflection Point

Perils of inflection point

Most of the companies in its glory of existing product success 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 were dominating the market[1]. Nintendo was the leading game player in 32 bit games while Sega became 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 bit games. So clearly each of the above mentioned companies had a tight vigil on the inflection points and entered the market with a new technology. However the same set of companies missed to observe the subsequent inflection points and lost their market dominance when there is a technological change. The only error committed by those companies is to bask in the glory of existing products success; undeniably most of the companies commit such mistakes.

[1] Source: http://www.nasdaq.com/article/qualcomm-leads-mobile-baseband-chipset-market-analyst-blog-cm367305

Having talked about inflection point now let me revert back to the actual topic of how to tackle inflection point in roadmap. Please note that the inflection point can be caused by both technological and non-technological changes. Since I hail from high tech industry and I am obsessed with technology, let me focus my discussion on inflection point within the scope of technological change. Accordingly there are 2 situations for tackling inflection point.

  1. Opportunity – To displace incumbents
  2. Risk – To avoid being displaced by new entrants or existing competitors

In either case, it is really critical to identify the new technology that when introduced will change the dynamics of the market. However the only difference is that in former scenario, when there is lot of aggression to displace the incumbent, there would be conscious effort to identify and validate new technology to understand how new technology can change the dynamics of the market when embraced into the product offering. In later scenario, incumbents will be busy serving their customers and they might possibly duck the new technology trend as fad. Clayton M. Christensen threw lot of light on this topic in ‘The Innovator’s Dilemma’.

Assuming both incumbents and non-incumbents spot the new technology and realize the importance of embracing new technology in product offering, our discussion is primarily on how the product roadmap will address the introduction of new technology to face strategic inflection point

Opportunity – To displace incumbents

New technological introduction will either help displace incumbents (Sega displaced Nintendo with 64 bit games) or create a new segment (Nintendo WII target casual gamers). Either way, once the new technology is identified and validated, it can be directly added to the roadmap and start prioritizing addition of new technology to the product offering. In this scenario, there is less of product roadmap dilemma and more of technology dilemma (how customers would adopt new technology and what would be adoption rate). Startups or non-incumbents will leverage this opportunity to gain foothold and for them they have more to gain than lose in chasing new technology or new market segments.

Risk – To avoid being displaced

In this scenario, there is more of product roadmap dilemma and less of new technology dilemma. Adoption of any technology takes time and the adoption rate would only increase gradually. Further investing in new technology would not provide immediate gains, so trying to prioritize new technology introduction over other product features that could fetch revenue in the immediate future is a big challenge. For those reasons, it is fair to treat new technology introduction separately and not allow it to compete with existing product features. Remember the % split of roadmap across the following categories – tactical, strategic and disruptor. Even before we talk about technology adoption, first and foremost problem is to eliminate the uncertainties related to new technology and figure out how new technology can be imbibed to deliver significant value to customers.

Adoption of HouseholdsNow coming back to the discussion of technology adoption, let us take the example of IoT. The success of IoT lays in more proliferation of connected and smarter devices, so manufacturers have to enable the smartness in the devices they manufacture. But do all customers embrace IoT immediately? Definitely not, the technology adoption cycle familiarized by Geoffrey A. Moore obviously suggests that customer adopt technology at varying intervals. So companies should most probably employ a two-legged approach (investing on both old and new technology at varying degrees) to ensure seamless transition of their customers from old technology to new technology. I honestly don’t see any other alternative to two-legged approach in addition to deriving a well-crafted strategy to increase the adoption rate. Once the uncertainties surrounding the technology are cleared and applications of technology are determined, the technology transition is not a technical problem as much as it is a business problem (how to increase adoption rate) and roadmap problem (how to balance between old and new technology). I am not undermining the efforts required to validate the new technology, what I am stressing is that in the case of embracing new technology to avoid the risk of being displaced, seamless transitioning from old to new technology and accelerating the adoption rate are major challenges for a Product Manager.

Business problem

The good news is that at least in B2C segment the adoption rate of new technology is lot more quicker. May be, one primary reason for quicker adoption rate is affordability along with increase in per-capita income of the consumers. In B2B segment as well, maturity and affordability of new technology will be one of the primary drivers to increase the adoption rate of new technology along with the necessity to clearly articulate the value of product offering that imbibes new technology.

Adoption of Mobiles

Roadmap problem:

[PS: Product that incorporates new technology is being referred as new product offering]

Revenue potential of new product offering will always be too little, so allowing the new product offering to compete with traditional product for resources will spell death knell for new product offering. The primary focus for Product Manager is to resolve the resource split between old and new technology through ruthless prioritization of features of both new product and old product.

Take small and substantial steps

In case of new product offering, it is advisable to take baby steps. Start with building the most essential parts (basic functionality) of new product offering that would facilitate to enter the market and validate the product. Product Manager need not strive to build a perfect product with focus on usability, performance etc., instead build a new product with sufficient functionality that can render appropriate value to customers. The basic idea is to validate the product, solicit the feedback from customer, and iterate the product incrementally in a cyclic manner while successfully convincing the customer to transition to new product offering.

Don’t adopt herd mentality

Everyone is testing waters with new technology and none might be sure about what market needs, so just don’t blindly follow the competition. Herd mentality is riskier. Ideal mechanism is to validate the product with selected set of customers and understanding their needs to further evolve the product using the principles: Insight, Observation and Empathy as outlined by Tim Brown in his book “Change by Design”. Any technology (for instance IoT, BigData) will be rendered useless unless Product Manager wove a solution offering surrounding the technology and successfully build a product that resolves a need. Technology sans solution is no good for anyone.

Pick a customer(s) – THE Lighthouse Customer

In any technology transition phase, the bad news for incumbents is that they need to meticulously balance both old and new technology during the entire period of transition of their customers to new technology as technology traverses through various phases of the adoption cycle. But the good news is that incumbents have a customer base and they do not have to hunt for customers. It should be possible to pick the early adopters from the existing customer base for validation of the new product offering.

Measure the adoption rate of new technology

Any further changes to the new product offering will be dependent on the feedback solicited from the customer. Meanwhile Product Manager has to look out for certain signs to measure the adoption rate of the new technology. Accordingly he can plan to increase investment in evolving new product offering

  • Is technology becoming cheaper?
  • Is the performance curve of technology increasing?
  • Are there any standards evolving for new technology?
  • Are more customers interested to trial new technology?
  • Are there any viable business models to sell new product offering?
  • Has the company started making real money on new product offering? Or is there a clear potential to make real money?

Response to the above queries can help Product Manager ascertain whether the new technology will be adopted and at what rate. In case of substantial signs of new technology being adopted, it implies that early adopters have gained confidence on the new product offering and it should be possible to convince them to start investing on new product offering. Product Manager has to now look out for success stories of new product offering, create press releases and communicate the actual value delivered by new product offering to early majority and provide them sufficient reasons to trigger the migration

Trigger transition from old to new technology or product offering

It is during this phase that Product Manager has to aggressively evolve both product offering (in terms of functionality, usability, performance etc) and non-product offering (documentation, support, marketing, press release, case studies) of new technology while cutting down the investment on old product. It might not be wise to continue investing on both old and new product while letting customers take their own sweet time to transition. Basically the overlap period between old and new products has to be cut short. Product Managers has to develop a strategy to reduce the transition time by offering incentives to migrate through trade-ins, migration offers, early discounts etc. or by offering more value adds on new product offering in comparison with old product.

Managing product/technology transitions in roadmap

The entire purpose of this exercise is to ensure preparedness for the future while not leaving sight of the short term opportunities and to effectively manage the transition of customers from old product to new product. Please note that the old product is still the revenue generator (probably cash cow) and we could not risk the revenues of old product at the cost of embracing new technology. Product Manager has to strike a perfect balance. Since we are building the new product offering at the cost of existing product, Product Manager has to follow some ruthless prioritization of features on existing product as to deliver only the most critical product requirement and allow some space to introduce new technology.

Prioritization tips for existing product during technology transition:

During early phases of introducing and validating new technology

  • Deliver features that are critical and categorized as ‘MUST HAVE’
  • Deliver only core features or extensions to core features
    • Most products are known to be packed with tons of features. Prioritize only those features that extend core functionality of the product.
  • Deliver requirement that are applicable to wider range of customers
  • Don’t focus on custom requirement – Even if they are requested by high revenue generating customers
    • Use appropriate negotiation skills to either drop the requirement or trade the requirement for any other generic requirement

During customer transition period from old to new technology – As the technology adoption increase

  • This phase indicates sunset mode for the product, so the focus in less on investment and more on squeezing all possible revenues.
  • Even among ‘MUST HAVE’ requirements, focus only on those requirements that delivers immediate value to customers
    • For instance, Product Manager does not prioritize requirements such as support for 100K simultaneous users where customer anticipates the increase of simultaneous users to 100K after an year
  • Focus on features that can aid in migration
  • Focus on stabilizing the product
    • Smaller segment of customers might always stick to old product for little longer duration. So stabilizing the support to reduce support cost will be ideal
  • There should be reversal trend of prioritizing more requirements related to new technology and less requirements related to old technology
    • Entice customers to migrate by delivering more value on new technology

Final Thoughts

During the transition phase, Product Manager should not lose sight of the product revenues. The ultimate goal for the Product Manager during transition phase is to ensure that the revenues of new product offering will offset the decline in revenues of older product.

Ratio of tactical, strategic and disruptor requirements

This blog is the 6th part in the series of blog posts related to ‘Pragmatic Guide for Preparation of GREAT Product Roadmap’

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

2nd part – Why product roadmap?

3rd part – Pragmatic purpose of product roadmap

4th part – Discovery of needs

5th part – Categorizing requirements – Tactical, strategic and disruptor

Ratio of tactical, strategic and disruptor requirements

I initially tried to categorize the roadmap into (i) tactical, (ii) strategic and (iii) disruptor adapting the 3 horizon framework described by McKinsey. I attempted to adapt the framework for products.

 3 Horizons - McKinseyMcKinsey 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 of revenues in short term.

 

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 has 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 life time of the product and thereby causing product to decline prematurely. Investment on strategic requirements is imperative to secure 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 (new customers or new market segment or new geo territories or new technology or new solution?) to additional growth. Please refer to the earlier related blog posts (Attacking White Space – Identifying Growth Opportunities). Accordingly Product Manager could figure out that ratio. For instance, if existing customers contribute to more revenues and the market is really saturated than customer product requirements should occupy higher ratio. In case of targeting new market segments, product requirements specific to those segments would occupy higher ratio. Honestly, there is no scientific way to derive the 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 am ‘TERRIBLY SORRY’. I don’t think I can draft a scientific methodology because roadmapping 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.

  • Leap-frog strategy – If the product is not a market leader and the intention is to leap frog the competition, don’t act as fast follower and never attempt to accomplish everything that market leader has done. If the gap between your product and incumbent product is too wide, trying to ape incumbent and following them will never let the product to peak. 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 leap-frog 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 – This strategy is adapted by companies that 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 air on the uncertainty about new technology or innovation.

In either case, there is precedent of what works and what do not work. So Product Manager while focusing on closing the parity has to leverage the experiences of incumbent to focus on requirements that are 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 don’t think any customer have directed both Microsoft and Intel to evolve their products. What Intel and Windows did was to create a demand. I don’t think they ever targeted to satisfy a demand.
  • Customer focus strategy – In case of mature or saturated market, existing customers constitute a majority contributor of revenues. In such scenario deriving a product roadmap constituting predominantly customer focused features with some room for market features yields better results. 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 would be given a long arm, 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 leap-frog 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 that perfectly helps me to keep inflow of revenues intact while focusing on strategic requirement. As long as 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 incremental requirements, there is hardly no choice. But explicit focus to identify potential disruptors is purely by choice even though all the firms have to continuously innovate 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 have to cautiously validate them. Further any new technology with exception of some take longer time to mature. So it is the prerogative of the organization depending on their overall strategy whether to exclusively invest their resources to anticipate new normal and invest on either 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. Gartner Technology Hype CycleTechnology Hype Cycle

Source: Gartner

Investing on disruption technologies is not a norm as much as there is necessity to focus on both strategic and tactical. Technology adaption takes time and 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 customer. To put in other words, the focus would be mostly on demand generation.

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 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 take Bluetooth, Virtualization to enter into the mainstream? We are now talking about driverless cars, but what is the right time to start investing on driverless cars so that 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?

Gartner Maturity CurveAdoption Curve and Maturity Curve

Source: Gartner

Once the organization decides to make a move and start investing on disruptor technology, my 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. The point at which old technology dissolves and new technology emerges is called inflection point. Inflection point causes a shift in revenues, technology, customer preferences etc. So 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 blog.