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.

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.

How support cases can aid Product Manager make better product

Image: Dell’s Official Flickr Page/Flickr

Every organization has a well laid support system to address customer issues promptly in a satisfying manner within the limits of well-defined SLA. The customer support software that manages the entire support infrastructure would have the basic capability to raise tickets, re-submit tickets, provide feedback, assign engineer and close tickets etc. In addition, the customer support software would also have analytics support to provide below highlighted insights that can help measure the efficacy of the support systems

  • How many support cases were raised?
  • How many support cases were resolved by each support engineer?
  • How many support cases were resolved within the guidelines of SLA?
  • What is the lean period and peak period for receiving cases?
  • ….

The discussion of the current topic is to go beyond those traditional insights. I am not trying to open a debate on the nature of the support system and I am only trying to emphasize that the data gathered by support system can be effectively gleaned for more information. The information when analyzed properly can provide lot more insights which when acted upon can effectively strengthen the product.

Now let me try to comprehend what kind of insights could be obtained from support cases

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

YouTube recently 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: 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 Managers to increase the value of the affected scale parameters.

Support team are 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 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 feature might be buggy – Wakeup call for engineering team to immediately address those issues, while Product Manager can plan for interim release to avoid further customer dissatisfaction
  • The feature is not intuitive – The feature might be working properly but customers are increasingly finding it difficult to operate. Either the feature is not intuitive (usability constraints) or documentation is not clear. From the perspective of HW product, documentation often plays a key role
  • 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 our 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)

[PS: Rest of the insights is based on premise that ‘No Product is DEFECT FREE’]

  • 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. For instance, customers ask about features whose existence is generally taken for granted. In case of VoIP product, it can be as simple availability of history of call details that Product Manager would have missed to include in the product.

  • Most used/ least used features

Such list can help Product Managers better prioritize features. Most used features can provide a clear view of what interests most to customer and Product Manager can target to evolve those features to create a stickiness factors. In case of least used features, Product Manager can understand the reason behind prioritizing those features and later revisit the feature prioritization strategy. Also in case of a conscious attempt to eliminate unnecessary features to make a lean product, least used features list will be handy.

  • Active customers

Some customers do not express displeasure about the product openly and their way of showing the displeasure is to switch to a competitor product. In case of product with no recurring revenue, support cases are best alternate mechanism to figure out the active customers. How Product Managers can use the data? They can do some analysis on why the product has lost customers. Later those insights could be used to build competitive analysis and also to improve the product.

 The above insights need not necessarily be exhaustive, I am only trying to emphasize that support cases when gleaned properly can provide more information and thereby I strongly assert that more additional insights could be obtained to further strengthen the product. Guess I am throwing a product idea of incorporating BIG DATA into support software to throw more meaningful insight that might rather surprise Product Managers.