Cross pollination of agile and waterfall

Withstanding all the hype surrounding agile, we did follow waterfall model while we built the new product. Agile does not work for all kinds of products even though waterfall model had its own flaws of not allowing the possibility to modify the requirements after entering development phase. So in order to introduce agility within waterfall model, we integrated both agile and waterfall. This blog talks about our experiences of experimenting with a new methodology combining both agility and waterfall. The below excerpts are from my eBook – ‘Building New Product – Experiences of a Product Manager

Our traditional approach to product development has always been the waterfall model. Nevertheless, while we embarked on our journey to build the new product we built the product upon the foundation of waterfall methodology while introducing agility within it. The ability or willingness to experiment with processes or methodologies should be fundamental for any new product development. The experimentation of processes or methodologies can occur when we know why we are doing what we are doing. There should always be a fit between the product and its development methodology, alike product-market fit. If we follow herd mentality and religiously follow a methodology without realizing why we are doing what we are doing, there will be hardly any scope for candid introspection of whether the product and its development methodology have the right fit.

Agile - WaterfallWe never consciously discussed altering waterfall and introducing agility within it. Program Manager naturally adapted the waterfall model to accommodate agility while we had several assumptions to validate, unknowns to eliminate and risks to mitigate. During the course of product development phase. There were never any serious discussions to brainstorm how to integrate both agile and waterfall development methodologies. The objectives and constraints of product development phase naturally triggered our Program Manager to combine them. Real kudos to our Program Manager to introduce agility within waterfall model. It is easy to follow stage gate process to ensure that we complete one stage and move to other. However, while we can only partially complete a stage and move to next stage. Later reverting to earlier stages based on the outcome of a current stage, it is extremely difficult to track dependencies across stages. Let me brief what we did.

For an enterprise product, the architecture of the new product is crucial. I can split the product into two blocks. Architecture block and product functionality block. Redesigning the architecture of the product is always costly and it is as good as developing a new product. Further, the choice of an HW is heavily dependent on the architecture and choice of product architecture is dependent on the HW. Both are mutually dependent. There is a necessity to ensure that HW and architecture can allow the software (i.e. functionality block) to scale as needs of customers evolve with little or no change to both the elements. Why are we putting so much emphasis on product architecture? I once came across a tweet that states every scale has an expiry date. True to those words, software has to scale in future as customer needs evolve and product architecture should support such scale requirements in future with little or no changes to product architecture. Certain elements of product architecture are rigid and it is not possible to modify it as new needs arise. Therefore, it becomes crucial to building a product architecture with a hindsight of how customer needs evolve in future. I did vehemently establish the fact several times in this eBook that the new product should cater to needs of tomorrow and not just for needs of today. Building MVP is not viable to identify needs of tomorrow while it is a viable option for identifying needs of today. Developing customer insights along with identification of factors that can influence the evolution of technology, the evolution of the market, the evolution of customer needs are crucial for anticipating probable needs of tomorrow. Clearly, for enterprise products where architecture can play a big role in determining the success of the new product and where the design and development of architecture happen upfront, agile is counterproductive. Incrementally building product architecture is a grave mistake. However, Program Manager introduced agility in building functionality blocks that address actual customer needs.

During requirements phase, we did outline all assumptions, unknowns, and dependencies across requirements of both product architecture and product functionality. The first priority was to eliminate all unknowns and validate all assumptions surrounding the design of product architecture. The design was mere theoretical until we start building it. Therefore, there will be many assumptions primarily around the ability of product architecture to meet scale requirements. To validate all those assumptions and eliminate unknowns, we constructed hypotheses. On those lines, we also constructed hypotheses surrounding product functional requirements. The product development happens in an interval of 6-8 weeks called DTHOs. Our 1st priority was to eliminate unknowns and validate all assumptions related to product architecture in earlier DTHOs. Dependent products requirements were refined based on the outcomes of those DTHOs.


Hypotheses of Product Architecture
Hypotheses Associated Requirements Dependent Requirements
H1 R1 R11
H2 R2 R12
H3 R3 R13
H4 R4 NA
H5 R5 NA


Hypotheses of Product Functionality
Hypotheses Associated Requirements Dependent Requirements
H6 R6 R14
H7 R7 NA
H8 R8 R15
H9 R9 R16
H10 R10 NA

The list of hypotheses surrounding both product architecture and product functionality has provided an indication to Development Manager and Program Manager on two aspects. First, the set of functionalities or requirements (R1…R10) that engineering team should implement during the initial DTHOs for validating hypotheses. Second, the set of functionalities or requirements (R11…R16) that engineering team should delay until validation of hypotheses (H1…H10). Delayed functionalities or requirement are later implemented depending upon pivot or preserve scenario in accordance with the outcome of validating each hypothesis.  PRD has clearly articulated the list of incomplete requirements. As initial DTHOs validated hypotheses (H1…H10) through implementing requirements (R1…R10), I refined all dependent requirements (R11…R16) implemented in subsequent DTHOs. The dependent requirements are mostly functional requirements that are refined after validation of hypotheses related to both the requirements of product functionality and product architecture.

One example of a hypothesis is – Ability of the product to meet throughput scale requirements (Hypotheses – H1). The PRD had a clear requirement for the product to deliver 60 Gbps at an average packet size of 512 bytes while maintaining low latency. The conventional wisdom is to measure and report maximum throughput at an average packet size of 512 bytes. Engineering team did validate the hypothesis by building the entire product but performing sizing through simulation. We identified during hypothesis validation that 60 Gbps is achievable albeit with a higher packet size. As I had indicated earlier, marketing team later did lots of analysis, found out the average packet sizes in customer networks is much higher, and we could conveniently defy the conventional wisdom. We never froze entire requirements. Depending on the hypotheses validation, dependent requirements were refined during the course of the new product development introducing agility within waterfall model.

The biggest criticism of waterfall model is that it always heads in one direction. However, we did introduce agility to shift our thinking back and forth between development, design, and requirements. Requirements (R11…R16) were kept open and refined after corresponding hypotheses are validated. We clearly introduced a loop containing product requirements, product design, and product development until we validated all the hypotheses. However, following a strict waterfall model, we had to build a foundation for product architecture upfront unlike in agile before going in a loop containing requirements, design, and development of product functionality. Such model is required for enterprise software products until we find out a methodology for modularly building product architectures for complex systems. Modular architecture should eliminate rigidness facilitating incremental additions to product architecture without the need for redesigning the entire system.

I really feel bad that some of the Product Managers hide their inefficiencies under the veil of methodologies such as Agile, MVP etc. Those are excellent methodologies drafted with good intentions. Nevertheless, those methodologies are more abused than used. MVP formulated by Eric Ries is an excellent way to incrementally build the product through an incremental process of build, measure and learn. Does it mean that a Product Manager should learn every aspect of product requirements through MVP? When it gets difficult for a Product Manager to comprehend customer requirements, the easy way is to put emphasis on MVP. If we start validating every requirement of the product, it will unnecessarily delay product development. There is always a necessity to strike a balance which I find missing. Further, in the case of enterprise products that have a direct effect on customer’s business, the customers will not be ready to validate it thoroughly. While building complex products for enterprise customers, it is always crucial to do extensive customer research and draft those details in PRD to get the bigger picture of the overall product. User stories do not communicate bigger picture. I can definitely bet if I ask for a PRD, some might even perceive me as a person from the dinosaur age. I am not showing my indignation on everyone. Probably, just a handful of them. My request is to embrace methodologies and process, comprehend them thoroughly and adapt them to suit your new product development. Always find the right fit between the product and its corresponding methodology.

Every incumbent product has vulnerabilities

What does success stories of Tesla and Waze teach every Product Manager?  Every incumbent product is vulnerable and there is an opportunity to beat even awesome products.

Tesla Sales

How many of us would have believed that there is a possibility for a new player to emerge (leave alone succeeding) in the luxury car market, beating the likes of Audi, BWM, Mercedes, Lexus, etc? Yet, Tesla zoomed to the top beating the engineering, luxury, speed, performance, and safety of luxury cars built by Audi, BMW, Mercedes, etc. While sales of every other luxury carmaker were declining, Tesla managed 50% YoY. The phenomenal growth of Tesla when the growth of the entire market was actually declining.

Tesla clearly shows that they have defied every conventional wisdom of building products. Elon Musk has shattered existing benchmarks for building the new product. The first element that an investor would look for while building a new product is whether the target market is a growing market. Similar logic applies to Waze as well. Investors would be interested to know whether the new product is addressing a tangible gap and whether there is a place for an alternate product. How many of us would have had the brilliance to spot the white space in navigation products and boldness to overcome Google. Waze did it, Waze managed to build the amazing navigation product preferred by lots of users over Google maps. I could not imagine someone building a better navigation product than Google considering navigation product require lots of work and even Apple failed in its attempt to build an awesome navigation product.

Those examples are testimonials to the fact that it is highly unlikely to build awesome products adhering to existing benchmarks. Conventional wisdom always believes in building a new product in growing markets and in markets where there is a palpable gap of unaddressed needs. The Conventional wisdom of building products is accrued naturally through precedents set by earlier successful products. Astronomical valuation of Facebook during its initial days based on its active users instead of its actual revenues has set a precedent for every other internet company to focus on user acquisition and not on generating actual revenues. Someone should set the precedent first before it becomes a conventional wisdom. The Majority of great products have set the precedent and not followed any existing precedent set by other successful products. Tesla and Waze have also set a new precedent going against conventional wisdom. They have proven that every incumbent product is vulnerable and there is always an opportunity. However, it is not an opportunity that is visible in plain sight. All it requires is a keen eye to identify white space, bold thinking, appetite for risk, impeccable execution to beat incumbent products.

The above contents are part of eBook – ‘Building New Product – My Experiences’


Building New Product – Experiences of a Product Manager (free eBook)

I am glad to end 2016 with  completion of 3rd edition of my eBook – ‘Building New Product – Experiences of a Product Manager’. I released 1st edition of the eBook towards end of 2014. Ever since, I did a critical review of my work to check whether i had provided enough information in my eBook, accordingly evolved it into 3rd edition. I did so, by holistically reflecting on my experiences of building the new product not just by introspecting what i did better but also being critical about where did i go wrong and what i could have done better. I leveraged those insights to provide more actionable information on how to build great product that is:

  • Built on a foundation of strong product vision that ultimately defines the purpose and objective (WHY?) behind the new product.
  • Built in alignment with real needs of real customers and as desired by those real customers.
  • Built not just for needs of today but for needs of tomorrow.
  • Built with all essential attributes that drive customer preferences towards the new product.
  • Built with focus on doing one thing (that drives customer preference) awesomely right instead of doing everything right.
  • Built with basic premise of think bold, think future unconstrained by any limitations.

I really appreciate if you could take a look and drop your thoughts or comments.

What is the right product management culture

One important tenet, that I believe as a Product Manager is that

Product Manager should stand for what (s)he believes is right for the product and do what (s)he believes is right for the product. I a firm believer in that tenet.

Why the above tenet is so important? Product Manager is a glue that connects every entity (Engineering, Design, Sales, Account Team, Marketing etc.) and thereby has a responsibility to ensure that everyone is walking the same direction towards the same goal. Hence it is vital for Product Manager to stand for what he believes is right for the product and do what is right for the product. I am not talking about shifting power, I am talking about facilitating to do what is right. However, it does not evade the responsibility of others to stand for what they believe is right. To do so, everyone need to have same shared vision and work collaboratively for the common good without letting people with higher power to forcefully enforce ideas irrationally.

But, how do Product Managers can uphold such a tenet and practice it in an Organization. Only through a right culture. So, why is culture so important and how it is related to upholding and practicing a tenant.

Importance of Culture

Culture in short is a way of doing things in an Organization. Culture is not a rule book but a set of guidelines that outlines how an Organization would behave. Having a culture that is strongly and consistently imbibed into each employee of an Organization will evoke a similar response for any given situation. Without a culture, Organization is failing to set those guidelines for every employee to share a common belief. Every Organization embrace diversity in hiring people without any discrimination on the basis on age, sex, creed, race, religion, color etc. However, every employee should share a common belief that characterizes purpose and belief of an Organization. If Organization believes in innovation and if it believes in customer excellence, it should be reflected in Organization culture. Without a strong culture, it is not possible for employees to share a common belief and therefore nothing will be deterministic when things go wrong. Organization is only sowing seeds for a failure. Without a strong culture, Organization is not what it says it is.

For better reference on Organization culture, there is nothing better than slides on Netflix culture on slideshare:

Organization culture should directly or indirectly promote a strong product management culture too. The aspects of what culture should be cultivated in an Organization is determined by its goals and beliefs. Similarly, the goal for a right product management culture is to facilitate Product Managers to stand for what they believe is right for the product and empower them to do what they believe is right for the product. Right product management culture is required not just to influence Product Manager but every entity in an Organization to build and evolve great products that are

  • Built on a foundation of strong product vision that defines the purpose and objective behind the new product.
  • Built in alignment with real needs of real customers and as desired by those real customers.
  • Built not just for needs of today but for needs of tomorrow in alignment with evolution of technology trends, market trends, changing customer needs and their behaviors.
  • Built with all essential attributes that drive customer preferences towards the new product.

Celebrate failure

Mediocrity hampers us from building great products. Employees think mediocre, not because of lack of competence, not because of inability to think bold, but because of lack of intention to set high standards. Employees hesitate to set high standards because of fear of being crucified when failed. Probably another reason for such attitude are those mundane goals characterized as SMART – S ‘Smart’, M ‘Measurable’, A ‘Agreeable’, R ‘Realistic’, T ‘Time Bound’. Great products are built upon a foundation of great idea that seem unrealistic when conceptualized.  So if Organization is following traditional ways of measuring employee performance, it is only paving way for mediocrity. Realistic goals can be set for predictive outcomes, but along the path of setting high standard to build great products, the outcomes can seldom be predictive.

 “I’d rather attempt to do something great and fail than to attempt to do nothing and succeed”

– Robert H. Schuller

Only when employees start thinking bold and make an honest attempt to achieve it, they really know their capabilities, they could really gauge the possibilities. When we are thinking bold, thinking future, nothing is a straight line. All of us have to navigate through lots of uncertainties and unknowns to pivot quickly. Unless Organization celebrate failures and unless it cherishes the ability to fail quickly, it is closing the path to greatness.

On the note of celebrating failure, please take a look at the amazing video of Astro Teller (CEO of X) for this thoughts on celebrating failure.

Reward effort, not just outcome

Traditional ways of evaluating employees’ performance are always based on outcomes. Unfortunately, outcomes do not always directly correlate with capabilities and efforts of employees. Outcomes are more important, but as I had just indicated outcomes do not always depict the real capabilities of the team or its individuals delivering those outcomes. During my days as development engineer, every time I resolve a critical issue for a customer, I will get a flurry of emails applauding my efforts from customers, account team etc. All those emails will finally be followed by a ‘Thank You’ email from my manager. It is only during those occasions that I get an applauding email from my Manager. Luckily, I had wonderful managers, there were hardly couple of exceptions in my entire career.

I often wonder, why does even my manager who can have a close watch on what I am doing have to appreciate me only based on an outcome. There are lots of good outcome with little efforts and not so good outcomes with tremendous efforts. For customers, it is definitely outcomes and the impact it has on business is the only tangible way to appreciate our efforts. Nevertheless, it should not be the only yardstick to measure performance internally within an Organization. I always loathe managers who are outcome based.

Appraisals, performance evaluation of every employee is done in a half-yearly and yearly cycle, but building great products does not happen in such short timeframe. They take time, so just evaluating performance based on outcome is definitely short-sighted. If we had to celebrate failures, we have to start applauding the efforts and not just outcomes. Doing so, Organization provides enough impetus for employees to aim for the sky and yet allows them to fail gracefully without being ridiculed or castigated. Even in case of failure, there is a tremendous realization of various possibilities.

“Failure is simply the opportunity to begin again, this time more intelligently”

– Henry Ford

Data driven

Even though the motivation behind celebrating failure is to inspire employees to set high standards, the other important element is to provide an incentive to fail early and quickly without allowing anyone to hang-on indefinitely until it gets too late.

We always preach fail early and quickly. The primary reason is that we do not want to spend too much efforts and go too far to finally realize we are failing. But then how far is too far. The answer lay in relying on data (both quantitative and qualitative) to analyse how long to persist and when exactly to hit the failure button. For data driven model to be successful, it requires a mindset change, a mindset that does not try too hard to be correct. Data driven model will abstain each of us to remain in a state of prolonged perseverance to hold onto one’s viewpoints without any rationality. There are other inherent advantages of being data driven (i) Every view point or decision has to be backed by data and not just by the highest paid person’s opinion (HiPPO) and (ii) Data will facilitate better ways to measure the efforts, to quantify knowledge gained out of failure and how it can help us to start intelligently again

Embrace criticism

Organization should develop a culture that is not averse to constructive criticism. Why would criticism be seen as bad (i) arrogance or egocentricity – ‘How can my ideas be criticized?’ The problem is due to bad hire who is culturally misfit (ii) insecurity – ‘Oh, my idea is seen as bad, does it reflect bad on my capability’. No idea or thought is perfect at first instance, criticism should have boundaries and it has to be targeted at an idea or a thought and not on an individual. Originators of an idea too should accept possibility of imperfection and embrace criticism to make improvements.

When organization culture promotes customer empathy and follows an inclusive and collaborative approach, it stops paying heed to the ideas and opinions of only the highest paid. Doing so, there will be democratization of ideas and the best ideas that addresses customer needs will win irrespective of who triggers the idea. Customer empathy will let everyone work for the larger good of the product rather than the self. In such scenarios, constructive criticism will be embraced by each employee to build better products.

Final thoughts

Clearly, the right product management culture that can facilitate Organizations to build great product is to have everyone think bold and aim for the sky, shed their inhibitions to fail, crush their egos, embrace criticism and subject their actions to scrutiny.  Above all, another important element is to hire best talent who has right cultural fit.

Hey Product Manager – Did you ever stood up for what you believe

Product Managers are always termed as a CEO of a Product. Some say, it is mere rhetoric. Others argue, it is a classic lie as Product Managers have hardly any authority to move the needle that can propel the Product in the path of success. Nevertheless, I still believe Product Manager is a CEO of the product, (s)he owns. For me, it is less about authority and more about responsibility of doing what is right for the product and standing up for what we believe is right for the product even at the risk of being alienated.

Question to all my fellow Product Managers – How many times, have your ever stood up for what you believe is right for the product.  Have you not stood up before because your organization does not foster the culture of questioning or are you just clueless on how the proposed changes could impact the product? I am not insisting Product Managers to either revolt or take sides, I am just insisting them to articulate their position or viewpoints with strong backing of either quantitative or qualitative data.

An ideal Product Manager by virtue of owning the product, having a broader understanding of the market in which the product operates and with absolute awareness of which customers use the product, why they use it and how they use it should have ability to connect dots to anticipate the impact of any proposed changes. Anyone one else in the organization might not have such a depth of understanding, thereby making it essential for Product Managers to stand up to make sure their voices are heard.

It does not matter if view of a Product Manager is turned-down, what is more important is that the voice of Product Manager should be heard. However, end of the day we take decisions as a team and we should collectively stand by it. I believe we as a team should own it rather than blaming individuals and see how the risks associated with the decision could be ascertained.

If you are not a Product Manager, have you ever come across a Product Manager in your organization who has stood up for what (s)he believes in. If not, then your organization is either not hiring great Product Managers or it is not fostering a right product management culture that can let Product Managers stand up for what they believe in. In my next blog, let me explicitly focus on what kind of product management culture should we instil in an organization.

How to grab a PM role as self-taught Product Manager

What is the path to breaking into Product Management after self-learning and how easy it is to break into Product Management career?

Let us first understand the criticality of Product Manager role and what are the expectations of a hiring manager. Product Manager roles are very critical to an organization as they own a product, so a bad hire costs them a lot and therefore every potential hiring manager will start looking for a good Product Manager. But how does hiring manager can measure the reputation of any potential candidate as a good product manager? Invariably most of them pick the easy route at least to filter candidates for interviews from heaps of resume they receive for a job. Hiring managers are also risk averse as the risk of hiring a bad Product Manager is really costly, much costlier than hiring a bad engineer. So hiring manager look for easy choices and pick candidates with an MBA degree from a premier institution or with prior PM experience from a reputed organization. Candidates with such profiles already come with a reputation of being a potential good Product Manager.

I don’t blame hiring manager for such policy. The probability of recruiting a bad candidate with such policy is very minimal and it serves the purpose. In the case of self-learned Product Manager, there is a need to establish a reputation as being a potential good Product Manager. Otherwise, there is hardly any chance to even get called for an interview. It is up to self-learning Product Manager to walk the extra mile to create such a reputation. Honestly, there does not exist any single way to increase the reputation of any candidate as being a potential good Product Manager. MBA degree not only increases the reputation of a candidate but also throw lots of opportunities through a vast alumni network. So, another aspect that a self-learned Product Manager has to work is on networking to be aware of opportunities in product management.

Firstly, I would suggest for a self-learned Product Manager to pick an industry/domain that (s)he would target for a product management position. I would suggest picking an industry where (s)he already has experience. Product Management skills are mostly independent of industry/domain, but domain experience is definitely required. During career transition into PM roles, things might get little difficult even if the domain is also new. In a known domain, Product Manager can spend his/her initial day’s refining product management skills that were acquired through self-learning.

Domain experience from the perspective of Product Manager is different from that of an engineer. When I indicated domain/industry experience, Product Manager should be able to create a mental map of where does the industry exists, what are its challenges, where is it poised to head, who are the players. But how does a prospective Product Manager showcase domain experience? Probably, writing articles about opportunities that the industry could offer. Those articles should highlight that you are aware of the industry and the potential it could offer. Please be aware that for certain industries (especially high tech), domain experience is much valued than real Product Management experience.

Yet, you still need someone to take you to the doorsteps of Product Management opportunity. So nothing works better than networking. If someone can vouch for your credibility, it increases your reputation of being a good Product Manager. So look for connects who can at least give you the initial push. It might often get tough to get a PM role in an organization that is alien to you without any referral.

As you start knocking PM opportunities, I can bet your initial 1 or 2 interviews might fail badly but then you will learn what is someone expecting from you. I would always ensure that i will never have my 1st or 2nd interview with the company that I would like to work if I am interviewing after a long time I would rather not take any chances with the company that i would like to work. But please be aware without those connects, it is tough to get the initial call for an interview. Another ideal option is to look for transition within your company. Your organization knows you better than anyone else if you have a supportive manager put your intentions loud and clear. Unless you ask something, you will not get it.

Another aspect that is really important during the entire process of career transition is that highlight your strengths and draft a cover letter on how your experiences can help you deliver in your new role. Never be too honest to highlight explicitly that you don’t have PM experience but you will be able to learn on the job. Too much honesty is no good, I did that mistake. Hiring managers think that you are not confident once you drop those words. So your resume and cover letter should provide enough confidence that you are THE Guy for the job.

How to be a self-taught Product Manager

Firstly, I firmly believe anyone could obviously become a self-taught Product Manager. However, the desire should be backed by strong passion, perseverance to learn/imbibe new skills and finally to succeed as a Product Manager. Both my current and previous managers are excellent Product Managers and they are self-taught without any certifications/MBA degree unlike me. But requires lots of effort. An MBA with 1 or 2-year degree gives you the undivided attention space to master yourself on various subject albeit though theoretically. However, things do not remain same while you actually start implementing those models/frameworks learnt during MBA days

I did find this resource really exhaustive: I love Product Management • Attack with Numbers It is a goldmine of information related to Product Management. In addition, recently has consolidated a list of top 50 product management blogs you should be reading.

As you go through those blogs to start grasping the nuances of Product Management, start identifying someone who can mentor you and streamline your efforts to become an effective Product Manager. As you start learning more about Product Management, start wearing the hat and determine what decisions you would have taken and why. Expand your knowledge about your domain/market that you target to focus, get a hindsight of players/products. What those players/product does, which segment they focus. If you are managing a product in that space, start figuring out what would you do differently and why. Most importantly be aware of what kind of technology advancements are happening and how it could impact both the product and its associated companies.

Product Management is an extensive field spread across pricing, roadmaping, strategy, market research, competitive analysis etc. But I feel the primary quality for a Product Manager is to be inquisitive, start asking WHY? for everything that you get to do in your role as an engineer. When you start working on any feature, ask why it is important, how it helps in moving the needle towards the desired business goals, how it helps customers etc. Basically be curious and never shy away from asking WHY?

Product Management is more of an art than science. While it is good to observe practitioners around you and learn from mentors, just don’t blindly ape them. Have your own thought process. Be ready to experiment with new modes of prioritization, new modes of discovering customer needs, new modes of validating products, fail (early and quickly) and learn.

Learning Product Management is just a start, the next big hurdle is to break into Product Management by securing a job. In the next blog, I will focus on how to get into a PM job (based on my experience). The other aspect that I did not focus in this blog is that if art of Product Management could be self-taught, how does an MBA could make a difference to PM career. How similar advantage could be obtained without an MBA for others who are at serious disadvantage at not to pursue a MBA. I want to conclude this blog post with an excellent quote from the Ratatouille movie

“Not everyone can become a great artist, but a great artist can come from anywhere.”

The above quote is true for any profession including Product Management.

Good luck with your journey

Comprehending customer buying process – Necessity for tools

Through series of blogs articles on ‘Comprehending customer buying process’, I have been evangelizing to take a holistic view of the entire buying process and connect the dots to understand what goes beneath the thought process of customers while making a buying decision. Nevertheless, the buying process is really complicated with multiple engagement points at each stage of the buying process spread across offline and online space. It would be extremely tough for Product Manager to grasp what is exactly happening without the aid of tools. Product Manager should have access to tools that could stitch all the activities across the entire buying process together. Without the existence of tools and without the ability of tools to stich the activities across the buying stages, how does Product Manager ever know whether the issues with customer support are hurting cross sell/up sell opportunities? How does Product Manager ever know which marketing campaigns had direct impact on sales? How does Product Manager ever know whether product is being evolved as per the expectations of customers? What I had observed is that the CRM tools fall into three main categories

  • Marketing – Awareness phase
  • Sales – Information phase till Adoption phase
  • Customer support – Loyalty phase

Product Manager might or might not have a say in selection of tools, but if there are multiple tools (s)he has to figure out some ways to stitch them together to understand more on customer behaviors. Presence of tools hardly makes any difference unless the Product Manager is not curious to know –

  • How many customers got to know about the product?
  • How customers got to know about the product?
  • Was awareness about the product was created among all target customers?
  • Have marketing campaigns effectively communicated the value of the product to entire target customers?
  • Did the awareness phase raise enough interest among target customers to know about the product?
  • How many customers have expressed interest to know more about the product?
  • How many initial leads got converted into sales?
    • What customers liked most about the product?
    • What are the top 3 reasons for customers to buy the product?
  • How many leads were lost?
    • Why did customers not choose the product?
    • Are we consistently losing to any competition?
    • What would help product regain the lost ground?
  • Are customers satisfied with the product?
    • Was there any recurring sales from those customers
    • Did quality of product had any impact on up-sell/cross-sell opportunities

The thought of tools triggered to me when I recently had an opportunity to demonstrate my product (B2B) in one of the leading events. The tool used in the event is awesome, it identifies –

  • How many customers are visiting the event?
  • Which booths did they visit and when
  • What sessions (demo, technical, keynotes etc.) did they attend?
  • Short survey to identify, the list of technologies or products that interest customers, what is budget spend of customers for next few quarters

Product Manager can have precise details on the exact number of customers who knew about their product and who those customers are. Product Manager can further identify if there is a dip in the % of attendees knowing about their product due to inappropriate location of booth or any other factors. The tool is exhaustive to provide any details pertaining to the event and customers who attended the event. But what is missing is to understand the influence of the event (awareness phase) in pushing the customers to next phase (information phase). Other element that I missed during the event is to figure out whether customers attending the event are existing customers or not. Accordingly, I could adapt information provided about the product to both existing and prospective customers. Icing on the cake would be to link the details of customers visiting the event with support data to identify the list of issues recently faced in their network, so Product Manager could have leveraged the opportunity to set appropriate expectations, allay any fears about the capabilities of the product to address their needs. Customers also would be happy that they are being heard and their issues are taken seriously.

Ideally, tools do a fantastic job in silos (marketing, sales and customer support), but they should be unified to get some fantastic insights. Can dip in customer support cases of a specific customer be correlated with sales tool to identify whether that customer has possibly migrated to any other product or migrated to competition? Can patterns of critical support cases and sales be linked to check if there is any correlation? The biggest insight that could be obtained is to identify the exact set of reasons (both product and non-product attributes) influencing the buying decision of customer. There should be deliberate introspection to identify whether customers are buying the product for those reasons that Product Manager envisaged. If not, something is fundamentally wrong in our understanding of customers and our approach to build, sell and market the product. Those activities are not aligned in favor of customers thought process applied during the buying stages.

Sometimes, the tools might not be linked for fear of data security breach. Nevertheless, nothing should stop Product Manager to at least manually stitch them. Otherwise, Product Manager could not create a feedback loop or establish causal and effect mechanisms among the four main pillars of product development – (i) creating value, (ii) communicating value, (iii) delivering value (iv) capturing value.

Why TIMING factor is critical in evaluating a new product idea – WHY NOW?

The idea validation is all about verifying the idea on the basis of 3 parameters.

  • Desirability – Do product to be built will be desirable by customers to address their existing needs or problems.
  • Viability – Will customers be willing or can afford to pay to solve the need or the problem? Is there a sizeable market for business viability
  • Feasibility – Can the product to address the need be built in most optimal and economical way?

There is a fourth parameter to idea validation that most of us miss is timing – WHY NOW? WHY NOT EARLIER? Along with validating the idea on the parameters of desirability, viability and feasibility, Product Manager has to validate WHY IT IS NOW THE RIGHT TIME to invest on productizing the idea. Understanding WHY NOW is critical to ensure that the new product is neither too early nor too late to the market.

Timing new product – Why now?

During validation phase of new product idea, the larger discussion that needs wider attention is to figure out the right time to start new product development or the focus is more towards understanding why it is now the right time to develop new product. Timing is one of the most critical factors that can determine success or failure of the product. Product Manager therefore has to answer the most pertinent question – WHY NOW? Why it is now the right time to translate the idea into a full-fledged product, so (s)he can ensure that the product is not too early or late to the market.

Discussion about timing is not very critical if the idea is fulfilling an already existing need addressed partially or fully by competitor products successfully. In such a scenario, the focus will be more on ‘How Differently’ is the idea addressing the need. When Mark Zuckerberg created Facebook, MySpace and other social sites are already in existence. MySpace is pretty famous at that point in time. So the question would have been how differently Facebook should/would be built to succeed against competitors. I am not sure whether Mark Zuckerberg has done any competitor analysis and it is not significant for this discussions. What is important is that timing might not be very pertinent if the idea has already been addressed by competitors.

There are 2 types of needs that essentially require an idea to address them

  1. Dormant Need – These are needs that are in existence since long time (but unaddressed so far) and the recent improvements in technology or increase in economic status of the population or any other factor would have made it either feasible or viable to address the need. These kinds of needs can be either known to customers or not recognized by the customers.
  2. Emergent Need – There are needs that have either emerged or will emerge because of existence of certain drivers.

Therefore for any Product Manager to effectively respond to WHY NOW? I am fundamentally relying on 2 parameters

  • What changes in technology, socio, economic or other related factors makes it either feasible or viable to address the dormant need
  • What are the drivers triggering the emergent need or rather what drivers will germinate a need in future.

Dormant Need

Identify drivers making it feasible or viable to address the need

  • Availability of reliable sensor has paved way for lots of IoT use-cases such as smart parking, intelligent health monitoring etc.
  • When it was not financially viable for banks to establish branches in rural areas, emergence of mobile banking extended the reach of banking services to rural people at an affordable cost.
  • Ecommerce enabled the possibility of selling less of more niche products and still make profits (Remember long tail coined by Chris Anderson). Further Ecommerce facilitated creation of market place to bring buyers and suppliers much closer than ever before. 

A closer look at the above example will clearly indicate that there was always need to bridge the gap between buyers and suppliers, ecommerce has facilitated to shorten the gap. With increase in number of cars, parking was always a hustle in most of the big cities; IoT has facilitated the possibility of smart parking system. Rural population always had banking needs to either receive money from their wards living in faraway cities or lend money for their farming activities. Only mobile banking has made is feasible to extend the banking services to rural population.

Emergent Need

In this scenario, identify jobs or products or services that did not exist 10 years ago. How would someone explain the sudden emergence of new products or services had it not been for existence of any dependent drivers? Emergence of new disruptive technologies always spawns new needs. They create a wave giving raise to new allied products or services.

  • Rise in smartphones has created a need for Apps.
  • Increase in demand for sharing and uploading videos has created a need for better video optimization techniques for better transmission of video over IP networks.
  • Proliferation of more network connected devices has spurred the need for additional addresses, resulting in creation of IPv6.
  • Had it not been for the availability of high speed internet connectivity and proliferation of hand held digital devices to take video, YouTube would not be successful.
  • Increase in population of elderly people by a factor of 2X in US by 2030 will definitely create needs for old age friendly products or services.

Technology need not be the lone factor contributing to emergent needs. Regulation and economic status can also contribute to emerging needs

  • Increase in demand for more power and inability to meet the demands would create the need for alternate energy and energy efficient products.
  • Depletion of portable water would create the need to derive alternate sources for portable water
  • Increase in per capita income increases the spending power of consumers thereby leaving lots of money on table to be grabbed by anyone providing irresistible services or products. Per capita income is critical factor to watch while launching expensive goods of services.

Identifying whether a need is dormant or emergent and identifying whether environment is conducive to build a new product can help Product Manager decide whether it is now the right time to start productizing the idea.  If the timing is not appropriate, then there should be possibility for an organization to preserve the idea instead of discarding it. The idea could later be bought to life when environment is conducive for the idea to prosper.


Building New Product – Experiences of a Product Manager (2nd Edition)

I have rolled out 2nd edition of my eBook – ‘Building New Product – Experiences of a Product Manager’. Much of the focus in the revised edition is around idea validation. Please take a look and share your thoughts.

The downloadable copy is available at