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

Collaborative discovery of customer needs – Who can participate?

As a Product Manager, one of the constant fears that I have is: Competition identifying a need before I or my peers do – Honestly, I don’t feel bad about it. Such situation can only testify that the discovery process is not rock solid and there are gaps. It gives one more reason for Product Managers to believe that they should think beyond themselves to expand their sources that can help them discover needs. Product Managers are always outnumbered in an organization by Engineering, Sales, Account Manager, BDMs etc. One best piece of advice that I received from my manager is that stacking more Product Managers is not feasible and it is not the right solution too. Instead Product Manager has to scale with existing stake holders to perform his/ her activities.

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

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

Product Manager is not a lone entity while (s)he is exclusively responsible for discovering needs, corroborating needs and sometimes synthesizing inputs from various disparate sources to formulate a need. It might sound cliché, the fact is Product Manager does not have authority to demand that every stake holder has to discover need and Product Manager cannot set goals for discovery of needs. What I have mostly seen is that when Product Manager walks that extra mile to facilitate Sales Manager close the deal, help Account Manager maintain better relations with their customers, and aid Development team to build products faster, the entire stakeholder too walk that extra mile in assisting the Product Manager.

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

Needs from support team

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

YouTube changed the VIEWS variable to 64 bit to accommodate more than 2 billion views as ‘Gangnam Style‘ video by PSY was viewed more than 2 billion times (source: Every product is initially created with certain scale parameters assuming it would suffice, however as time progresses and customer business grows, product might soon start hitting the limitations on certain critical scale parameters. Customer would raise a panic button immediately after hitting the limitation but support team can pro-actively raise an alarm through monitoring the critical parameters of the product. Support team will use support cases or other methodologies available to monitor and track the critical parameters of the product. When the critical scale parameters reach a threshold level, support team should immediately alert Product Manager to increase the value of the affected scale parameters.

Support team is also equipped to analyze the support cases and understand the trends to figure out the most common issues faced by the customers, such analysis can help Product Manager understand the list of needs that is not optimally solved by the product. Any improvements can lead to better customer satisfaction thereby triggering higher retention rate leading to more up-sell or cross-sell opportunities. Increasing trend of support cases on a specific feature could also throw lot more possibilities to ponder upon the following

  1. The feature might be buggy – Wakeup call for engineering team to immediately address those issues, while Product Manager can plan for interim release to avoid further customer dissatisfaction
  2. The feature is not intuitive – The feature might be working properly but customers are increasingly finding it difficult to operate. Either the feature is not intuitive (usability constraints) or documentation is not clear. From the perspective of HW product, documentation often plays a key role
  3. The feature is incomplete – The customer needs are not fully met, wakeup call for Product Manager as the customer needs are not properly analyzed. Product Manager needs to take quick remedial action to bridge the gap between customer needs and product capabilities ASAP.
  • New use-cases/ solutions

There are classic examples of customers using the product quite distinct from its intended use. Every product has few innovative customers who are always step ahead of the product team in implementing either new use cases independently through innovative changes in configuration or new solutions through successfully aligning the product with other products. Those innovative customers whom I would comfortably refer to as Innovators or Visionaries as explained by Geoffrey Moore in his book “Crossing the Chasm” do dare to exploit the complete functionalities of the product to resolve the challenges faced by them. Such customers constantly pose technical challenges and help Product Managers build better products which eventually puts us ahead of the competition. Personally it is good to have such customers and my opinion is that they are worth more than a million dollar customer.

Support engineers when consciously look out for such unique use-cases or solutions through the aid of support cases can help Product Manager identify innovative customers and capture their innovations. Product Manager can later use the data to enhance the product that can supplement those innovations or draw plans for new product offering for new ways of positioning the product (aka demand generation)

  • New product requirements

Customers ask about non-existing features through support probably because of lack of understanding of the entire functionality of the product. Product Manager could use those inputs to understand new product requirements; this set of requirements will predominantly be incremental extensions of existing product capabilities.

Sometimes support system is the single window for customers to vents their ire on lack of any features that should have been available in the product by default. In B2C, customers do not think twice to raise their concerns through social media. If your support system does not have the facility to track the digital foot print for such messages, comfortably fall back on ‘Google Alerts’ to track.

Needs from engineering team

Engineering teams are masters of technology while product managers are presumably masters of problem space. Closer ties between the two entities triggering frequent discussion (not necessarily structured, probably unstructured discussions over coffee, lunch or in corridors) can create wonders. When engineering teams are kept informed of the problem spaces, they can evaluate how advances in technology (probably new components in case of HW products, new algorithms) can address the customer pain points in a much better way. For instance in case of VoIP products, engineering/ folks can suggest alternate mechanisms to increase voice/video quality, reduce latency and BW required etc. For same reasons, it is always better to let engineering team provide outside view of the world. Engineering team has to be updated with details about competition, customers, wins & loses, what differentiates our product from the rest.

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

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

Needs from sales

No one interfaces closely with customer as much as Sales Manager does. Sales Manager can provide specific details on how each customer is using the product and they also help discover needs of individual customer. Sometimes Sales Manager can also help understand the gaps with competitor that is haunting the product in closing deals. In addition, Product Manager can also seek Sales Manager input on the below items to get better knowledge about the product

  • Why is customer happy with our product?
  • Why is customer whining?
  • What deals did the product lose? Is there any trend?
  • Is the product losing to any other product in the adjacency space?

Another big source is RFP that most often neglected by Product Manager to identify product needs. In case of B2B segment, RFPs mostly precede sales and the RFP would contain more details about customer needs. RFP would also validate the ability of the product to handle future needs of the customer. Analyzing multiple RFPs provides the direction in which customer businesses are evolving, look out for patterns of new needs and record them.

Ideally spot star Sales Manager to better know about customer needs. Star Sales Manager sell more not because the product is in demand or the product is great or that (s)he is lucky. They sell more because of the deeper understanding of the customer and the product combined with ability to position the product effectively at the intersection of problem and solution. Working with such Sales Manager is really a boon to understand more customer needs, further such Sales Manager are always on lookout for opportunities to generate the demand for the product. They equally look up to the Product Manager to share or contemplate new use-cases providing additional compelling reasons for customers to invest on the product.

Needs from BDMs

BDMs can mostly help discover strategic needs that can push the growth of the product. While talking about discovering needs, I stressed on the importance of pondering on the following topics:

  • Attacking growth – If it is a growing market, there should be conscious effort to identify who is contributing to the growth and lay plans to capture it?
  • Capitalizing white space (aka demand generation) – Probably same product but new use-case and new target segment, Product Manager has to look out for such possibility. Otherwise Product Manager has to spot customers trying to use the product differently from its intended use and check if the variations of the product could be built to generate additional demand for the product.
  • Is there any product in the adjoining segment that has the potential to make the current product irrelevant (what Mobiles did to Pager, what Smartphones did to Camera and Navigation Devices)

BDMs do definitely play a greater role in helping Product Manager ponder over the above topics. BDMs by the virtue of their responsibility to identify new markets for the product and put the product on growth trajectory will gain better knowledge about the market, trends etc. While interactions with Sales Manager(s) boil down to specific customer needs, interactions with BDMs will mostly be centered on discovering market needs.

BDMs role might not be just restricted to help discovering strategic needs, they can also play a greater role while the market is on cusp of technology change. During discussions around inflection point, I did mention that Product Manager should also focus on accelerating the technology shift triggering the migration of customers from old to new technology. BDMs can help identify factors which when accomplished can trigger the acceleration of technology shift. The factors could be improvement in performance of new technology or identification of wide spread applications of new technology.

Basic tenets of collaborative discovery

In all the above cases, Product Manager do not blindly accept the needs and record them rather he opens a dialogue with the respective stakeholders to understand more about the need (WHAT part of the need) and develop a complete awareness of how unmet/underserved/latent need is impacting the customers (WHY part of the need). Without the complete grasp of what and why of the need, it might be extremely difficult for Product Manager to convert the need into requirements and appropriately prioritize it. In certain cases, the stakeholders can merely provide some hints on the needs and they might not be equipped to provide complete details. Incomplete information is still fine and Product Manager might have to build upon those hints. The stakeholders should neither be discouraged to share any kind of information about the customer needs, pain points etc. nor be penalized or reprimanded for sharing incomplete needs. The basic premise is that any information on customer need is worthy unless thoroughly corroborated. Product Manager should also follow inclusive approach while prioritizing requirements thoroughly communicating the yard sticks used for prioritization to the entire team of need discoverers for allaying any fears of unbiasedness in prioritizing the requirements.

Needs from confluence of multiple minds

Needs are not always discovered by a single entity, certain needs emerge at the confluence of multiple minds. Especially in case of emerging technologies such as IoT, Virtualization, Big Data etc. where the problem space is not clearly defined as technology is evolving and the applications of the technology is also evolving; culmination of engineering, domain experts, Product Managers is essential to synthesize divergent thoughts into a concrete need. Unlike in the earlier scenarios, I am focusing on structured methodology (like brainstorming) because each entity has lots of thoughts and they are worthless individually. The focus of the brainstorming session is not to pick the best idea, instead Product Manager has to effectively moderate to facilitate a freewheeling conversation among all the participants to put on table all the divergent thoughts including their assumptions, later participants would built upon other thoughts to provide a shape to a new product need. The scenario is akin to each one holding a partial solution to a riddle. Product Manager has to identify and bring together all the entities holding the partial solution to solve the riddle. To ensure success of this entire exercise, Product has 2 challenges

  • Identify the right set of participants
  • Facilitate effective participation from all the participants

Importance of ‘WHY’

‘WHY’ does not essentially mean that Product Manager fires a barge of questions either during brainstorming or while collating needs from various stakeholders, ‘WHY’ should not sound like an interrogation. The power of ‘WHY’ lay in enabling other person to ponder, to reason out their findings. Primarily ‘WHY’ should also let the other person break their assumptions. Every person has certain set of assumptions and it guides their thinking process. Higher the assumption, more the limitations exists in expanding the thought process of an individual. Because of the limitation or inability to question the status quo, retailers thought people will never buy clothes without touching. Execs at Nokia and BB thought mobile users will always be comfortable with QWERTY. ‘WHY’ is critical when Product Manager has to think beyond the existing needs of customers and anticipate how new technology could impact them. ‘WHY’ would dug out all the assumptions related to customer behavior and ‘WHAT IF’ hypothetical analysis could be used to understand what changes in technology or product would trigger change in customer behavior. The examples that I had highlighted is related to disruptor technology as ‘WHY’ makes much larger impact, nevertheless ‘WHY’ is essential for critical understanding of tactical and strategic requirements as well.

Ability of Product Manager to facilitate collaboration

Honestly, there will never be a dearth of stakeholders discovering or contemplating needs based on their role and experience. Product Manager has to facilitate an environment for free flow of needs and also information related to product (drawbacks, needs, limitations etc) from every stake holder to Product Manager. Even if any of the need sounds dumb, Product Manager should not duck it away, (s)he should explain the reasons for discarding and elaborate the yardsticks used to measure the value of a need.

To check whether Product Manager could create a collaborative atmosphere, Product Manager(s) should try answering the following questions with YES/NO

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

If the answer to all the above questions is emphatic YES, then Product Manager is desperate to fill his/her head with information. Such Product Manager would never forego any opportunity to learn and (s)he would naturally facilitate an atmosphere to collaborate.

Categorizing requirements – Tactical, strategic and disruptors

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

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

2nd part – Why product roadmap?

3rd part – Pragmatic purpose of product roadmap

4th part – Discovery of needs

Categorizing requirements – Tactical, strategic and disruptors

Explicit focus on customer and market is to discover all possible needs without leaving any needs behind. Unless Product Manager discover all needs, (s)he will not be able to make right prioritization decisions and it will hamper the evolution of the product. Once all needs are discovered, trying to categorize and prioritize them based on market or customer hardly makes any sense. Discovery of customer needs provides a foundation to build a generic representation of the broader segment of customers and to embark on the journey of discovering market focus needs. So somewhere deep down needs discovered through customer focus will ultimately be a subset of the market focus unless the business models rests on customization.

I have already provided hints of possible categories while talking about ‘Discovering of market focused needs’. Yes, you got it right. I am trying to categorize the requirement into tactical and strategic. In addition, I have added new category called disruptor.

Tactical, Strategic and Disruptor


These are short term (mostly 1-2 years). There is no uncertainty on any of the requirements listed in this category. The requirements are lucid and therefore there is hardly any risk in implementing those requirements. Further the requirements when incorporated into the product would be readily embraced by the customers ensuring steady flow of revenues. The requirements under this category address the short term business challenges of the customer providing an attractive proposition for customers to invest in the product. The requirements under this category are mostly evolutionary in nature. Tactical requirements are essential to ensure the steady flow of revenues to meet the revenue targets of the product.


These are near long term (typically around 2-3 years). There is some amount of uncertainty on how customer would react to the proposed changes to the product and therefore risk of implementing them is moderately higher. So the priority is to build minimalistic prototype, validate, and solicit feedback in an iterative manner until the uncertainty is completely eliminated and the requirement is moved to tactical category. The requirements under this category bring-in absolutely new value to the customer but more often customers do not explicitly request them and customers can still live without them unless the requirement becomes parity. Online fashion store adding the capability of augmented reality to facilitate virtual dressing room can be categorized under strategic category.


Disruptor is a game changer. They uproot the entire market, create new market and install new normal. Disruptors make old way of doing things irrelevant and they create new product line, new consumption models, and new ecosystem that does not existing before. Disruptors mostly do not evolve the product but they will extend the product line introducing new products embracing disruptive technology or innovations. Strategic requirements when chosen properly can extend the product life cycle without pre-maturely declining the product. However they could not stop the product declining from disruptive innovations or technology. Focus on disruption is to embark on the journey of finding new technologies that has the potential to disrupt the entire market and create a new normal. Disruptors create viable options and alternatives for growth in long term. In case of strategic requirements as well, we focus on imbibing innovation and new technology into the product to create a better value but those innovations or new technology are sustaining in nature and does not create new markets. While disruptor technology or innovation creates new market uprooting the older ones, ideal way to tackle the disruptor technology is to embrace it and not to fight it. Organizations therefore have to start investing on new technologies that has the potential to disrupt the market and introduce new normal.

Product offering vs market matrix

In order to better explain tactical, strategic and disruptor, I derived product offering vs market matrix. I believe the diagram below is self-explanatory. Incremental enhancements to existing product offering to better position the product in existing market belongs to tactical category. Evolutionary changes to existing product offering to position in new market or creating new product offering for positioning in existing market belong to strategic category. Revolutionary changes to create new markets through new product offerings belong to disruptor category.


Product offering vs market matrix

Discovering needs

This blog is an edited version of my earlier blog post ‘Customer focus vs market focus‘. Explicit focus on market and customer is primarily from the purpose of discovering all possible needs. So i left it appropriate to change the title and made some additions to make the article relevant to discovering of needs.

Since the blog posts belong to a series of articles on ‘A pragmatic guide for product roadmapping’, i am providing links to previous blogs on the series:

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

2nd part – Why product roadmap?

3rd part – Pragmatic purpose of product roadmap

Discovering needs

Roadmap is not just a discreet collection of product requirements; it is indeed an entire gamut of unmet/untold/underserved needs translated into product requirements. The foundation for evolving product that would be embraced by the target market and does not decline prematurely rests on effectively formulating product roadmap with right set of requirements prioritized at right time intervals. Well-orchestrated discovery of all possible needs through understanding and anticipating customer business challenges, pain points and outcomes, later converting those needs into product requirements is the ideal starting point for a well-crafted product roadmap.

Discover of customer focused needs

Product Manager should be all ears while talking with customers to grasp their business challenges and pain points. ‘Listen to your customers’ is age old adage that is followed by every business and I am not advocating doing anything differently. I am just trying to emphasis that Product Manager should both listen and understand customer needs, but (s)he do not let customers decide the contents of their product roadmap. In the sense, Product Manager do not let customer dictate what features to develop, instead Product Manager will let customers focus on their business challenges (needs) and the Product Manager (in collaboration with development team) should derive the optimal solution that would address business challenges of customers. Otherwise customers do not think twice to dump the product that contains exactly what they asked for the product that optimally addresses their business challenges (needs). Even in case of customer outlining the expected outcome, Product Manager has to thoroughly analyze the outcome and propose other viable alternatives on need basis.

On the related context, I want to quote the words of Henry Ford “If I had asked people what they wanted, they would have said faster horses.” Ford while listening to his customers understood their innate needs of travelling quickly from A à B. Please read the related earlier blog post (Requirements has to be understood, not queried). So understanding customer untold/unmet needs along with explicit needs is critical to evolve the product roadmap. Yet does listening and understanding customer needs alone would suffice? Before I go any further let me clarify my definition of customer focus, “CUSTOMER FOCUS embodies everything that product attempts to understand and address unmet/untold/underserved needs of existing customers of the product”.

Discovery of market focused needs

I believe I talked about it umpteen times in my earlier blog posts that most of the customer business challenges are short term and could only trigger incremental changes to the product. The pitfalls of listening and understanding the customer is that someone might suddenly pop-up disrupting the entire market with new technology or new offering and customers might not think twice to switch sides. While it is required to keep focused on existing customers, it is also essential listening to the market to dodge strategic inflection point by understanding the factors that might cause product decline. Market is no different from customers and indeed market is a generic representation of broader segment of customers. So when I insist on market focus, I was looking forward to construct generic representation of the entire customer segment and start assessing how their needs will evolves with changes in dependent macro factor.

At tactical level, it always augur well to look at every individual customer needs to ensure steady flow of revenue but at strategic level while Product Manager has to envision how the product will evolve, (s)he has to create a mental map of how the generic needs of the broader segment of customer evolves and how they will probably respond to new technology innovations or any products in adjacency space that can address the needs of customers. Sometimes the idea is to go beyond the boundaries of the existing product, and customer to identify or grasp what is changing outside and build a mental map of how those changes might alter the customer behavior. To be more precise, in case of market focus, I was rather thinking more strategically to ponder over the long term evolution of the market needs or long term relevance of the product due to changes in market/technology or customer behaviors through explicitly pondering over the following

  • Attacking growth – If it is a growing market, there should be conscious effort to identify who is contributing to the growth and lay plans to capture it?
  • Capitalizing white space (aka demand generation) – Probably same product but new use-case and new target segment, Product Manager has to look out for such possibility. Otherwise Product Manager has to spot customers trying to use the product differently from its intended use and check if the variation of the product could be built to generate additional demand for the product.
  • Is there any product in the adjoining segment that has the potential to make the current product irrelevant (what Mobiles did to Pager, what Smartphones did to Camera and Navigation Devices)
  • Who are the customers of tomorrow – ISPs were long perceived to be the customers of networking devices not until Amazon, Google, Facebook, and Microsoft started buying more networking hardware than anyone else. Not many vendors looked at the later as potential customers. In case of consumer products, the buying patterns or behaviors of Millennials that might constitute significant portion of the target market had to be ascertained and acted accordingly. Their choices might not be the same as existing customers.
  • What are the customer needs of tomorrow – Can we anticipate those needs.
  • Is there any new technology or trends that when not accommodated might cause the product to be irrelevant For instance, impact of virtualization (NFV/SDN) on physical appliance in networking industry or Impact of IoT on industrial products

Anticipate emerging needs

In case of market focus, Product Manager do not merely understand customer needs, (s)he should also anticipate how customer needs will evolve or what new needs will emerge with possible changes to dependent macro factors. Once Product Managers understands the dependent macro factors (such as economy, regulation, internet, technology etc) that can directly or indirectly impact the products, there are 2 kinds of possibilities.

  1. Needs of tomorrow
    • With increased adoption of multiple devices (smartphones, tablets etc) by each user or family, will users start demanding new plans from ISPs?
    • With increased adoption of mobile devices in rural segment and with possibility of decrease in internet connectivity costs, what new needs could emerge (mobile banking? sharing latest farming know-how techniques? sell directly to consumers – eliminate middle?).
    • With the advent of IoT and wide spread adoption of IoT technologies to create smarter homes, what will be the impact to ISPs that provide pipes to carry data (specifically M2M)? How ISPs could monetize the data?
  1. Customers of tomorrow
    • With potential increase in disposable income of millennials, they can be possible target customers for real estate, luxury cars etc. Product Manager has to ascertain whether their needs will be the same as existing customers?

What I have stressed so far is that certain needs will emerge and new customers will also get added to the target segment in future with changes in economy, technology, regulation etc and it is the responsibility of the Product Manager to anticipate both emerging needs and emerging customers.

How far to look into the future

First and foremost, why should Product Manager anticipate, why not address the needs or target new customers after they emerge. Whether to anticipate or just wait until the need emerges primarily rests upon one factor – What is the time frame taken to address the need. If it is really long, then Product Manager has the responsibility to anticipate the needs to get the 1st mover advantage and excite the customers before the competition does. In case of automobile sector where the development cycles are really BIG, Product Manager cannot wait to understand the needs and aspirations of millennials until they start buying cars. It would really tough to answer how far should Product Manager look into the future, I would only insist on the starting point. The starting point is the sum of the time taken to research, develop and validate the product. Since it would be really tough to predict the future, Product Manager could better anticipate possible outcomes of the future through scenario analysis and use lean technique of product development to validate and ascertain which outcome is most likely to occur.

Final thoughts

Guess I have dropped sufficient hints on what I am trying to conclude, the contents of Product Roadmap should be a combination of both market and customer focused needs translated into product requirements. If I had to rephrase my earlier definition of roadmap – “Product Roadmap is indeed a collection of customer and market business challenges, pain points and outcomes translated into product requirements addressed through incremental product enhancements, or incorporating new technology, or building new platform or new product lines”. Ideally product roadmap should focus on both short and long term evolution of the product.

If any of my readers feel that my definition of ‘Market’ and ‘Customer’ is not appropriate, they are utmost welcome to drop me some suggestion at I am definitely in favor of much better alternate terms.