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: https://plus.google.com/u/0/wm/4/+youtube/posts/BUXfdWqu86Q). Every product is initially created with certain scale parameters assuming it would suffice, however as time progresses and customer business grows, product might soon start hitting the limitations on certain critical scale parameters. Customer would raise a panic button immediately after hitting the limitation but support team can pro-actively raise an alarm through monitoring the critical parameters of the product. Support team will use support cases or other methodologies available to monitor and track the critical parameters of the product. When the critical scale parameters reach a threshold level, support team should immediately alert Product Manager to increase the value of the affected scale parameters.

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

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

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

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

  • New product requirements

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

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

Needs from engineering team

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

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

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

Needs from sales

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

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

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

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

Needs from BDMs

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

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

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

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

Basic tenets of collaborative discovery

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

Needs from confluence of multiple minds

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

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

Importance of ‘WHY’

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

Ability of Product Manager to facilitate collaboration

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

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

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

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

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 murali.erraguntala@gmail.com. I am definitely in favor of much better alternate terms.

Requirement vs Need

I have been constantly using both the terms ‘requirement’ and ‘need’ interchangeably in all my blog pots. Since i am in the process of publishing series of blog posts related to product roadmap and requirements play a vital role in it, I thought of making myself clear on my definition of a need and requirement

  • Need – Any customer business challenge or pain point or an outcome is called a need. The need could be either untold (understood by the Product Manager without explicitly mentioned by the customer) or unmet (no product has addressed it) or underserved (existing product is only addressing it partially). Need is primarily defined from the perspective of a customer. Typically MRD captures a need.

PS: I am not a big fan of MRDs and I have never prepared one

Business challenge or pain point could be used interchangeably. Existence of challenge or pain point would be the single most compelling reason for customers to buy a product that solves the pain point in most optimal and economical way while delivering best possible experience. Identifying and anticipating business challenges or pain point is critical for evolving the product. Outcome can be termed as a business solution derived to address the business challenge or pain point.

  • Requirement – The need when translated into a form understandable by the engineering team is called a requirement. The PRD would never contain a need. It would only contain requirements.

Context of requirements

Every need when translated into requirement has 3 facets

  • What is the requirement? – Focusing on outcome
  • Why customer need those changes – Focusing on customer pain points
  • How to address those changes? – Focusing on solution

While translating need into requirement and recording them in the PRD, Product Manager has to focus on the first two aspects leaving the last one to engineering team. However in addition to those 3 facets, there is another additional facet that is relevant today called context to formulate the right solution. Context highlights the exact environment in which the customer operates. Accordingly engineering team can build a solution that exactly fits customer environment. Product Manager can also use the context to pro-actively figure out any constraints. Constraints highlight the limitations of the customer environment that might hamper the solution to work properly.

For sake of illustration, let me take an example of connected car wherein the car updates the vital statistics over internet for diagnostic purpose. The purpose of pro-active diagnostics through connected car is to anticipate the failure based on set of critical parameters going off the threshold marks and also to inform probable causes of the failure. The data could be possibly used to auto rectify the defect. Otherwise send a team to address the failure without any delay.

I have drafted the requirement but what about context? User personas and user stories are probably one way of communicating the context but if personas or user stories are used, they had to be exhaustive to cover all possible scenarios. The context is a car participating in a rally traveling at an average of 100 miles/hour in remote terrain. Accordingly Product Manager can figure out the list of parameters to diagnose. Does the data is sufficient to formulate the solution, obviously NOT. So where does the problem rests, being aware of the constraints. The success of the solution hangs on reliable connectivity to continuously connect the car with base station while traveling at an average of 100 miles/hour and to relay the diagnostic data in real time. Product Manager has to anticipate whether there is sufficient infrastructure to ensure success of the solution, otherwise Product Manager need to defer the solution until either the infra is ready or alternate measures for reliable connectivity is introduced.

Contents of product roadmap – market focus vs customer focus

This article is a 4th part in the series of blog post on ‘A practical guide to product roadmapping’. In this blog, i am focusing on the contents of 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

Contents of Product Roadmap

Roadmap is not just a discreet collection of product requirements; it is indeed a collection of customer business challenges and unmet/untold/underserved needs translated into product requirements. Product Manager should be all ears while talking with customers to grasp their business challenges and problems. ‘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).

Customer focused product

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”.

Market focused product

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 set of customers. So when I insist on 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 technology/market or customer behaviors. To be more precise, in case of market focus, I am advocating to ponder over the following

  • 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)
  • 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
  • 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.
  • 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.
  • 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?
  • What are the customer needs of tomorrow – Can we anticipate those needs.

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?
  2. 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. Now, 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 clearly rests upon one primary 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.

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. If I had to rephrase my earlier definition of roadmap – “Product Roadmap is indeed a collection of customer and market business challenges, needs and problems translated into product needs addressed through incremental product enhancements, 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 murali.erraguntala@gmail.com. I am definitely in favor of much better alternate terms.

Need for solution thinking to stimulate innovation

There are various types of innovations such as Product Innovation, Process Innovation and Service Innovation etc. Though I did not indicate explicitly, I was talking about stimulating “Product Innovation” in my earlier blog. One of the key drivers of product innovation is to derive new product ideas based on the deeper understanding of customers needs (both implicit and explicit). The new product idea can be based on application of new technology or any alternate product design that can enhance the usability or experience of the customers. The success of product innovation lies in our capability to understand both implicit and explicit needs of the customer. As I indicated in one of my earlier blog (The need for introspection of target market), the needs can change and it is the responsibility of Product Managers to keep well informed about the changing needs.

But focus of the blog is to facilitate engineers to gain broader understanding of the customer needs (at least explicit needs). Majority of the engineers keep themselves abreast with latest technology, the gap is only in the application of technology to generate new product ideas because of lack of awareness of customer needs. In other words, there is lack of solution thinking. Solution thinking is about the ability of engineers to successfully answer the following queries
Who is using our product?
Why are they using our product?
How are they using our product?

Solution thinking would facilitate engineers to identify product/solution gaps and it indirectly drives innovation to generate new product ideas to fill those gaps. We can make this very simple by having Product Managers communicate customer needs to engineers periodically through a forum or through streamlined process such as MRDs/PRDs. Later engineers can generate new product ideas based on those inputs. However customer needs are not something that is written on a wall, so by including engineers we are only expanding our capability to spot/understand more customer needs. Such inclusive focus will generate larger ownership among engineers and narrow the gap between product capabilities & customer needs.

We need to take a quick look at our history to figure out what is stopping our engineers from inculcating solution thinking. As a low cost deliver center, trtraditionally our focus has been on WHAT to develop and HOW to develop. Honestly our focus was never on WHY, please read my related blog post on the need to focus on WHY. Our emphasis on delivery excellence and engineering excellence etc has led to engineers working in silos with focus on specific modules of the entire product.

On the other hand, solution thinking requires a holistic view of how the product is used by the customers and how various components of the product inter operate to deliver a solution to the customer. By keeping our existing practices intact, I am only advocating for additional process (listed below) to inculcate solution thinking.

  • Product presentation delivered to all the new entrants to the product team. Product presentation would just have 3 steps
    • What is the product
    • Who are the users of the product
    • What are the specific business problems addressed by the product
  • Visual tools to explain how each element of the product interconnects with the rest of the elements
  • PRDs should not only list the features required but also highlight the needs that would be solved by those features.

The above 3 aspects might tell ‘Who is using our product’ and ‘Why are they using our product’. To understand ‘How are they using our product’, engineers have the distinct advantage of knowing it through support. While handling support issues, it is essentially that engineers’ not only focus on resolving the problem but to figure out how customer is using the product. We can do so through standard way of asking for the business implications of the problem for which support is sought. Customers define how the product is used and hence it is critical that we use customer support diligently to know how they are using our product.

 

 

Attacking White Space – Identifying Growth Opportunities

This post is continuation of my previous post ‘Attacking White Spaces’. IMHO, this is the least risky among all the three options as we will be focusing more on growth in existing market. As an initial step, I would definitely suggest taking the help of analyst or research firms such as Gartner, Light Reading etc to predict the market growth of your product. For instance, Standalone DPI market is predicted to reach 2$ billion by 2015. Now the real exercise is identifying the source of demand. Firstly we have to identify whether the additional growth is concentrated in a particular geographical region or it is equally distributed. We have to later evaluate our presence in those parts of the world where there is additional growth. By presence, I am referring to the presence of BDMs, Account team, Sales team. Most importantly sales teams connect in those parts of the world are more important as they do the actual selling.

Secondly we have to indentify which market segment(s) (higher-education, service provider and enterprise) will contribute to the overall growth. We have to later evaluate whether our product(s) is positioned to capture those market segment(s). If not, we have to take a quick decision whether to foray into those segment(s). Simultaneously we also have to evaluate our capabilities and competencies to effectively tackle the challenges posed by the new market segment(s).

Finally, we have to drill down our focus to understand how the DPI requirements would take shape in future. We have to make a possible assessment of what customer might require in 2-3 years from now. Here, the inputs obtained from different organization silos are critical in this phase to precisely understand the customer pain points and how their future needs or demands might take shape. To do so, we have to firstly understand the factors that drive the need for DPI and evaluate how those factors can change. We should also think of new factors that might drive the need for DPI. Evaluating all those factors should provide us an approximation of new features/solutions that customer might require in the future. We have to later evaluate the competencies and capabilities of our engineering team to deliver those new features/solutions. We might also have to align with 3rd party vendors to deliver additional solutions. In such cases we have to evaluate the capability of the organization to derive a long standing partnership with those 3rd party vendors.

In the first two cases, we have to factor all the assumptions that were made to forecast growth and later do some due diligence to validate those assumptions. For instance, analyst would have predicted that much of the growth will be contributed by the additional demand for standalone DPI product by service providers in African region. The primary task is to identify the assumptions behind such prediction and later validate those assumptions for their existence. This can be a parallel task done by a group of people as to be wary of such predictions and not to base our product revenue forecast purely on those predictions. We also have to be aware of all the factors (both external and internal to the target customers) that can positively/negatively influence those assumptions. In Telecom sector, regulation/economic growth of the region can be a probable external factor and cash flow of the target customer can be an internal factor as the industry is subjected to huge OPEX and CAPEX.

In forthcoming weeks, i will focus on the following aspects of ‘Attacking White Spaces’:
• Capabilities to create new market – Demand generation
• Unserved vs Overserved market segments