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