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
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
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.
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.
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.
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.
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.
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.
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.
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.
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.
Product Manager can have two possible types of engineering team (i) Sluggish and (ii) Motivated. Either way it would be trouble managing them.
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.
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.
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.
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.
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.
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.
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.
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.
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:
A little deeper look will reveal that product vision has 2 broad categories
|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.
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.
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
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.
Product manager identifies similar attributes for product objectives as well.
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.
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
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:
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.
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.
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
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)’.
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.
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
2nd part – Why 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:
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.
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.
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:
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)
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.
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.