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.

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.

Pragmatic purposes of product roadmap

This article is a 3rd part in the series of blog post on ‘A practical guide to product roadmapping’. In this blog, i am focusing on the pragmatic purposes of product roadmap

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

2nd part – Why product roadmap?

Pragmatic purposes of product roadmap

The product roadmap apart from providing a blue print of where the product is heading and how the product is evolving over the next few years, they also serve specific purpose to each of the stakeholders and I have highlighted those purposes explicitly in this section. Each of those purposes further emphasize the importance of product roadmap.

Product Manager – Product roadmap preparation as a regular activity pushes the Product Manager to outline the product growth strategy to accomplish product objectives, translate the findings into product requirements/new products/new platforms/new solutions and finally add them to the product roadmap. Therefore it is appropriate to indicate that product roadmap reflects the product growth strategy and preparation of product roadmap will consciously let Product Manager to ponder upon the product growth strategy. Product Roadmap is also an important document that can aid Product Manager to reason out or justify the budget requirements for product development.

Customers – First and foremost, product roadmap provides confidence that the product is evolving. Secondly, it indicates the direction in which product is heading. The information is critical for customers to understand whether the evolution of the product is aligned with their business objectives. Thirdly, it provides timelines on when specific requirements would be delivered. Fourthly, customers can plan their business (expansion, launch of new services etc) accordingly. Finally, roadmap when shared with customer regularly eliminates conflicts or ambiguity between features expected by customers and planned features.

For the 4th point, many of you might question if product roadmap is just a plan, how customers could plan their business in accordance with the product roadmap. When I talk about roadmap, I am talking about a timeframe of 18-24 months and I generally split the roadmap into 4 pieces of 6 months each, assuming there is major SW release once in six months (discarding minor bug fix releases). The probability that contents of the product roadmap will change is relatively higher as we inch closer to the end of 2nd year. But the initial contents (0-6 months and 6-12 months) do not change much and customer can use that data for half-yearly or yearly planning.

Engineering team – Even though roadmap would be derived in consultation with engineering team, it provides direction to engineering team on how to align their resources to deliver the requirements added to the product roadmap. In case of new technology introduction or new product development, engineering team can also fathom about the need for new competencies accordingly can either plan to build or acquire those competencies.

Sales – Sales executive can use roadmap to close deals, to retain customers and to attract new customers, because roadmap provides the following inherent advantages:

  • Roadmap provides competitive edge
  • Roadmap can commit product requirements of either current or prospective customers. Roadmap is mostly a plan but in certain cases, few deals beget a need to commit addition of new features or products. In such specific scenarios, product roadmap acts as a commitment to deliver requested features or product within promised time frame.
  • Roadmap is a sign that the product is evolving to meet future business challenges of both existing and prospective customer

Business development manager – Can look forward to expand the business into new territories or new market segments if new product requirements are being explicitly developed to foray into new geographical regions or new market segments. Even otherwise, BDM can estimate the revenue potential in his territory not only based on the current product capabilities but also based on how the product will be evolved.

A practical guide to product roadmapping – Part I

I am now back to starting a  series of blog post related to Product Roadmap, I am basically attempting to provide some practical tips to product roadmapping based on my experiences of developing product strategy and creating product roadmap. In the 1st series i will be starting with the introduction of ‘What is Product Roadmap’ followed by series of blog posts related to ‘Product Roadmap’. Upon completion of the series, i will formulate an ebook and upload it to slideshare.

What is Product Roadmap?

Product roadmap is a collection of product requirements, solutions or new products planned to be released over a period of time. The product roadmap could be broadly classified into 2 categories:

  1. New product roadmap

As name suggests, this roadmap will outline the new products or platforms to be rolled out into the market. New product roadmap will be really long term (around 3 years, assuming new product introduction takes 12-18 months)

  1. Feature roadmap

Feature roadmap would contain product requirements addition to existing product line. The product requirements could be segregated based on themes (usability, performance, technology, new solutions, etc) or market segments. The duration of feature roadmap will be 18-24 months in general. In case of new product just launched into the market, it might be tough to prepare a long term roadmap especially if the product is addressing a new market and the customer needs are not lucid. The duration of the roadmap is dependent on the maturity of the market in addition to other factors.

Note: Please note that I am outlining my thoughts from my experiences of being a HW Product Manager for B2B product where the development cycles are longer than SW products, so the timelines that I had outlined might be too long for SW products (especially in agile development methodology). Also in B2B products, product roadmaps are generally shared with customers and it is not the norm in case of B2C products.

Internal vs External Roadmap

In most cases, there could be an internal and external roadmap. Product Manager does not directly add a feature to the external roadmap and share it with the customer. Most likely scenario is that after the Product Manager identifies a customer need, he will convert the need into a product requirement and discuss with engineering team to give a proper shape to the requirement. What I precisely meant by giving proper shape to the requirement is that while Product Manager will explain ‘What’ and ‘Why’ of the requirement, engineering can figure out ‘How’ part of the requirement to conduct high level feasibility analysis and estimate the time frame required to deliver the requirement. Internal roadmap could be termed as a work-in-progress item trying to finalize the contents of the roadmap collaborating with internal stake holders and later pushing it to the external roadmap after getting a buy-in internally. There are other notable differences between an internal and external roadmap.

  • The primary difference is that internal roadmap is engineering focused and it will be too technical, external roadmap is customer focused and therefore the use-cases/solutions that provide tangible benefits to the customer will be part of the external roadmap. For instance, if there is a feature that changes certain algorithms to improve the efficiency or make the product scalable, internal roadmap list the exact technical changes done to the product while external roadmap will abstract the customer from technical nitty-gritties and reveal only the possible benefits. So Product Manager while adding the exact technical requirements to the internal roadmap will add only the tangible benefits to the external roadmap.
  • External roadmap is a subset of internal roadmap. Product requirements, new technology or new platforms that are under evaluation might not find space in external roadmap. External roadmap can also be viewed as selling tool, so any additions to the external roadmap that does not directly contribute to the purpose of selling might not be added. For instance, changes to the product to make it more stable or efforts reduce the defects found is purely internal item and it will never be added to external roadmap
  • In case of external product roadmap, Product Manager has to ascertain (i) what to share, (ii) how much to share and (iii) when to share. I have earlier talked about (i) what to share and (ii) how much to share. Regarding (iii) when to share, there are no hard and fast rules. In case of new product arrival, even though the news might excite the customers sometimes the details could not be shared with them if there is a possibility of taking hit on the sales of existing products. So simple thumb rule that I follow is to ascertain the risks vs benefits of sharing the news over a time interval (probably 4 quarters) and identify at which specific interval does the benefits exceeds the risks. If Product Manager plots a simple graph of risks vs benefits on Y-axis and time interval on X-axis, the risks and benefits will be mostly linear with each of them following an inverse pattern.
  • Engineering team is the audience for internal roadmap while Customers, Sales Managers, Account Managers, and BDMs are the audience for external roadmap.