Is MVP a trap or are we abusing it too much?

Any development methodology has its own fallacies unless we appropriately use them. With MVP too, we have to be cautious not to fall into a trap of probably relying on it too much (or rather should I say abusing it). MVP (Minimum Viable Product) formulated by Eric Ries is an excellent way to build a product through an incremental process of build, measure and learn. Nevertheless, it does not entitle Product Managers to learn and validate every aspect of product requirements through MVP alone. When it gets difficult for a Product Manager to discover and comprehend customer requirements, the easy way is to put emphasis on MVP. If we start validating every requirement of a 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 every incremental version of the new product thoroughly. While building complex products for enterprise customers, it is always crucial for Product Managers to do extensive customer research for obtaining deeper customer insights and balance those findings with MVP without completely hiding under the veil of MVP and Agile.


Trap 1 (MVP is not one-size-fits-all): The efficacy of any development methodology (Agile or MVP) lay in realizing the true purpose of those development methodologies. Not knowing when to use those methodologies and how to use those methodologies will lead to utter chaos and inefficiency. Eric Reis devised MVP as a methodology because of uncertainty in markets, customer behaviors and their expectations leading to product failures. Because of uncertainty, Product Managers fail to build new products for right needs and for right customers. For eliminating uncertainties through validated learning, Product Manager could leverage MVP for incrementally building the new product in a cycle of build, measure and learn with a primary motivation to validate whether the new product is addressing the right needs, for right customers and as desired by those right customers. However, not every new product caters to uncertain markets. Certain products are conceived for predictable markets with predictable needs incorporating already a proven technology.

In a scenario where competitors are crawling everywhere and there are analysts to provide any information about the need addressed by the new product or about the market targeted by the new product, Product Manager should leverage those details to build better insights about customers and market. What makes certain insights more meaningful is the ability of Product Manager for always reading between the lines to understand what had worked and what had not worked. Product Manager would later augment those insights to define the necessity for MVP and identify what unknowns will be resolved through MVP. MVP cannot be an excuse for lack of insights about customers and markets, MVP should only complement already existing information to obtain better insights. Now, this leads to the second trap, how much to validate and learn?


Trap 2 (Validating too much for too long)
Validating too many hypotheses will unnecessarily delay the development cycles risking the possibility of any competitor with better knowledge of customers and market go past the new product. For every hypothesis, Product Manager should ponder whether it is essential to validate the hypothesis directly with customers or is it possible to validate it based on customer insights. Product Manager by virtue of interfacing with customers, being part of the industry for a longer period should have developed some insights about customers, markets, and technology. Such insights should be useful for conceiving the product. I am in favor of lean practices but not in favor validating every element of the new product with customers. The right balance is required to validate the most critical elements of the new product while maximizing validated learning and minimizing efforts. However, Product Managers often do the contrary.


Trap 3 (Maximum efforts, minimal learning): After optimizing the number of hypotheses to validate, Product Manager has to identify the most optimal ways to validate them. Building a minimal version of the new product might not always be the best answers for validating learning. Dropbox founders validated their idea by building a video because building a minimal product consumes time and any change in the expected behavior of customers requires Dropbox team to alter the product architecture making it costlier and time-consuming. Ideally, Product Manager should follow lean practices even for picking the number of hypotheses to validate, how to validate those hypotheses and how long to validate those hypotheses. Time should be a major consideration while adapting MVP methodology. In the words of Eric Reis

A minimum viable product is that version of a new product which allows a team to collect the maximum amount of validated learning about customers with the least effort.

True to those words, MVP is about achieving maximum learning with most optimal efforts.


Trap 4 (Delivering with little value): Another trap is the risk of alienating customers especially when the new product addresses a need already addressed by competing products. In such scenarios, minimal version of the product that delivers the same value as existing products already in the market might not excite customers and Product Manager risks alienating customers even though there are explicit disclaimers that the product is a minimal version. MVP sometimes should provide a hint of what is in store for customers and it should excite customers just as a movie trailer captures the attention of its audience providing a sneak preview of the entire movie.

If the new product is another LinkedIn, Gmail or Salesforce, what could be the MVP version of the new product that might excite prospective customers? New Product, which might be a replica of an existing product, should deliver new value or deliver same value as the existing product in a unique way. Otherwise, the commercial success of the new product is questionable. Therefore, as part of MVP, Product Manager should validate the unique value delivered by the new product to verify whether it is a real differentiator. Doing so, MVP will provide a preview of the product differentiators that could excite early adapters. MVP while helping Product Manager validate the efficacy of the product in addressing a need uniquely should also excite prospective early adopters to buy the product.


Trap 5 (Not choosing right customers): Another crucial element for MVP is to choose the right set of customers. Always target customers who would be could be potential early adopters. In addition, the chosen set of customers should share the same passion for the new product as the Product Manager does. Few section of customers get excited about breakthrough products embracing new technology, few other customers want to be delighted with minimal intervention. The later set of customers hate when new the product uses their business environment as a trial ground.

MVP is a double-edged sword. While customers help Product Manager perform validated learning to pivot or preserve product development, customers will also throw feedback for further evolving the product. Product Manager is obliged to honor such requests after validating the fit with the overall strategy of the product. Therefore, it augurs well to focus on a specific target segment that are potential adopters of the new product ensuring that their needs are addressed and the product is out on the market as quickly as possible. Doing so, Product Manager can also avoid the problem of diverse feedback from MVP customers. In a B2B segment, I always prefer picking customers who can generate revenue in first two quarters of releasing the product. A certain section of customers do not generate immediate revenue but provides sufficient infrastructure to validate the product (early innovators).

Not every customer is very vocal about sharing feedback. The right way to perform validating learning is to observe customers using the new product. Never really rely on what customers actually say, what they often say is not what they actually intend. For true validated learning, rely on customer behaviors, body language, and usage patterns. There is a cultural aspect to feedback sharing, not every culture embrace the quality of calling spade a spade. Therefore, I loathe feedback forms, user group interviews etc.


We often follow a herd mentality and blindly adopt the widely used development methodologies. Instead, we should understand the true purpose of any methodologies and adapt it for the value they deliver and not for its popularity or for its wider acceptance among the fraternity. I appreciate your thoughts or rather contrary views on MVP traps specifically for enterprise products.

The focus of this blog is to specifically highlight the MVP challenges for enterprise products. In my previous blog post – Moving target of customers’ needs – A unendorsed challenge of building enterprise products, I have explicitly highlighted the challenges of MVP in building enterprise products. 


Building enterprise products for unknown tomorrow

The only certainty about future is uncertainty. The change was always constant occurring ever since the evolution of mankind. But what differentiates this era from foregone is the velocity at which change is happening. In my earlier blog post, I have shared my thoughts on customers’ needs and outcomes are increasingly becoming moving targets – an unendorsed challenge of building enterprise products. A product that is built today is at a huge risk of becoming obsolete or irrelevant tomorrow. Product Manager cannot succeed building products for static needs, there is a necessity to think ahead, think future and think audacious. Your product cannot be a lottery, there should be something definitive about future.

Unfortunately, Product Manager is not Nostradamus to predict future. Nevertheless, Product Manager can anticipate needs and customers of tomorrow by developing a thorough understanding of how markets evolve, how technologies evolve and how customers’ behaviors or their challenges evolve. Accordingly, ensure that the new product can scale and adapt for needs of tomorrow, markets of tomorrow and outcomes of tomorrow.

Please read my earlier post on moving targets before proceeding further, it asserts the necessity for building customer insights and building a scalable product architecture to tackle the challenges of moving target of customer’s needs and outcomes.

What defines THE FUTURE?

The technology was always a catalyst determining how future evolved and will continue to be so. While mid-90’s was defined by the Internet, the mid-2000s was defined by the Mobile and future ahead starting mid-2010s could be defined by the Artificial Intelligence. Technology advancements always had and will continue to have far-reaching implications on how markets evolve, how customer needs and their behaviors evolve. Faster technology advancements are putting products at the risk of becoming irrelevant sooner. Since technology is continuously at the epicenter of causing a new normal in markets and customer behaviors, it is only appropriate for Product Managers to forecast or anticipate what technologies could define the next decade. A plethora of technologies emerge every day and hardly few enter the mainstream market. But, why do certain technologies alone succeed, what factors could contribute to their success?

The enigma of technology emergence

There is always an enigma behind why few technologies successfully emerge while many others eventually fade away. Even among technologies that successfully emerge, some take longer than the others to enter the mainstream market.

  • The first digital camera was invented in 1975. Why did it gain acceptance only in later 1990’s and early 2000’s? What caused the technology to replace the older film cameras 25 years after its invention?
  • Why was smartphone one of the fastest adopted technology?
  • Why did Google Glass, Segway, and Amazon Fire Power fail?
  • The 1st AI program was created in the 1950s. However, it is adopted and successfully applied to address several problems only recently. What caused the slow rate of adoption and what would cause the creation of an AI system that would completely replicate a human brain?

There is a necessity to comprehend factors that could catapult certain technologies into the mainstream market, identify if there is a pattern that can help us predict or forecast the potential technologies that will emerge defining THE FUTURE. The first digital camera even though invented in 1975 gained acceptance only in later 1990’s and early 2000’s, what caused the technology to replace the older film cameras 25 years after its invention. Probably improvements in image quality of digital cameras, the proliferation of PCs to store and process images etc., it is always essential to comprehend factors that could accelerate adoption of an emerging technology. Imagine someone building a film-camera in late 1990’s. Even if built with awesome features, it would have been sure recipe for disaster. History can be helpful to provoke our thoughts. Product Managers of film camera products could have used the data to anticipate threat and take corrective action. Product Managers of digital camera should have used the data to identify factors that could have accelerated the adoption of digital photography. We are always on the cusp of major technological changes, a structured analysis is required to differentiate fad from reality for analyzing which major technologies are poised to become a reality and how. Later evaluate the impact to the new product both from a perspective of threat and opportunity.Product Manager has to build customer insights through experiments and observing customers in their natural habitat, immersing in their business, assimilating their business process, problems, and challenges and not just listen to what they say but to read between the lines to understand what they did not say. Customers might not be able to articulate what business challenges they might face in future. Based on trends affecting the product and general understanding of customers’ business environment, Product Manager should anticipate customers’ requirements and ensure that the new product will optimally address the requirements of tomorrow. Product Manager can do so by looking outside the boundaries of existing customers and trying to establish a generalized view of how the market evolves because of changes in external factors influencing technologies and customer behaviors. One plausibility to understand future is to comprehend what has caused the present to diverge from past and use that as a reference to anticipate what will cause future to diverge from the present.

Let me pick a contemporary example – AI (Artificial Intelligence). AI is a vast domain with several tiers of intelligence according to the use-cases that it intends to address. Following three categories outline broader classification of AI products.

  • Artificial Narrow Intelligence (ANI) – Specializes in a specific task
  • Artificial General Intelligence (AGI) – Matches the capabilities of a human brain
  • Artificial Super Intelligence (ASI) – Exceeds the capabilities of a human brain. It is getting tough to fathom the exact potential of ASI

Scientists and architects working on AI have embarked on an audacious attempt to build intelligent systems (AGI) that can learn and adapt on its own just like humans do or even exceed the capabilities of humans replicating neural systems of the human brain. What is the realistic possibility of building such an AGI system and when it could happen? To build AGI systems that behave like humans, we have to make huge strides in AI algorithms which is interdependent on two other factors.

  1. Huge processing power at an affordable cost
  2. Availability of huge data and corresponding big data systems to retrieve, store, model, process, and act upon that data in a fraction of microseconds.

The industry is making huge progress on both (1) and (2). However, whether they are sufficient or not purely depends on the computing requirements of AGI systems that we are building. We have to analyze the kind of progress (1) and (2) are making and what factors could further accelerate or decelerate the progress that could eventually determine whether AGI systems are hype or reality. Such analysis can also throw light on the possible duration for AGI systems to become a reality. Accordingly, we can either determine the threats that AGI system could pose to ANI systems if we are discarding it as a hype or determine when it is possible to build a new product that behaves like humans do.

Figure – The growth rate of computing systems

There is a clear indication that the computing systems that can mimic human brain at an affordable cost will probably evolve around 2030. If we are looking at building AGI systems, then we know when it is feasible to successfully build those systems. Simultaneously, we can also anticipate that there is no possible threat at least until 2030 from AGI systems to ANI systems. However, after 2030 there could be intelligent systems that could do much beyond than just playing chess and driving cars probably replacing white-collar jobs. Simultaneously it is essential to undergo similar analysis to understand when big data systems required for AGI systems will actually evolve. Will it happen before 2030 or later? We should always perform such analysis for comprehending which emerging technologies could actually enter the mainstream market. Accordingly, identify both threats and opportunities confronting the new product.

Comprehending THE FUTURE – Unraveling the enigma of technology emergence

Technology is undeniably the protagonist of our discussions, but technology alone does not define THE FUTURE, it is not a one-way street. There is a strong symbiotic relationship between how the evolution of technology, market, and customers coalesce together defining THE FUTURE. Understanding future is tantamount to diligently anticipating the following albeit not independently but in relation to each other.

  • How do customers’ needs evolve?
  • How do technologies evolve?
  • How do markets evolve?
  • Who are customers of tomorrow?
  • What are customer needs of tomorrow?

I have earlier predicted that it might not be possible to build an AGI system that can mimic human brain before 2030. Nevertheless, 10 years is too long for making any predictions and blindly sticking to it. We need to keep a close watch on whether computing systems are growing as expected. Identifying a wide range of ANI use-cases, and successful adoption and proliferation of related products such as Tesla, Alexa, and Nest etc. will accelerate the demand for more advanced AI use-cases. The initial euphoria of AI products gaining customer acceptance lure investors to make huge bets on AI companies, thereby increasing investments, fueling further innovations in computing systems and other related AI infrastructure making it feasible to harness additional use-cases that were eluding humanity earlier. It is a cyclic reaction, initial adoption of ANI systems by B2B and B2C customers will fuel more investments, leading to better technology advancements and in turn, creating better AI products through improvement in computing systems and other related HW/SW entities. Initial success begets more investments, with additional investments comes additional success, the cycle rotates until the success rate decelerates or investments slow down. For better prediction, we (Product Managers) should be able to predict what could break, accelerate or decelerate the cycle. Certain possibilities are, technology improvements do not happen as predicted, the economic slowdown might hamper in-flow of money, enterprise customers stop investing in AI devices etc. On the contrary, check what could accelerate the cycle, killer AI use-cases for B2B and B2C making AI products indispensable. Killer use-cases will ensure that AI products will be the last category to take a hit while either B2B or B2C customers decided to cut down their spending. Meanwhile, keep collecting any data that can provide an indication of how the AI adoption cycle performs. Below are few snippets of relevant data i) Phenomenal increase in AI funding over the last 5 years, and ii) Increase in share value of NVIDIA.












We can continue looking at other relevant data i) Adoption of AI products (both B2B and B2C), ii) Increasing rate of AI startups, iii) Technology improvements, and iv) Acquisitions etc. Any data cannot be viewed independently, we need to evaluate the data in correlation with others and connect the dots to predict the progress of AI.

Customer needs, technologies, and markets do not evolve overnight and they do evolve at a linear pace. However, there are certain forces at play that culminate together to suddenly push the evolution of customer needs, technologies and markets on trajectory path reflecting a hockey stick. Especially for high-tech products, Clayton R Christensen has clearly outlined that when the performance of new technology outpaces older technology, it gains adoption. Similar to performance, Product Manager had to identify several such factors that would result in the evolution of new markets, new needs and thereby bringing in new normal completely replacing older way of doing things.

While trying to understand the impact of technology either from a perspective of threat or from a perspective of opportunity over a definitive timeline, it is essential to do some structured analysis as shown above. Such analysis is possible only if we could understand the dependencies that underpin the evolution of various technologies. I have exclusively focused only on technology. Nevertheless, Product Manager should focus on regulatory, customer behaviors, the purchasing power of customers, economy etc. while anticipating how future unfolds and determining how all those factors will influence the evolution and acceptance of a technology. Many companies such as Kodak has gone into oblivion because they could not anticipate the threat that digital photography can have on their products. Such analysis could have provided Kodak clear hindsight of when digital photography is ready for mainstream market and what factors can aid its adoption. Accordingly, Kodak could have switched gears to embrace digital photography. We now knew that self-driving cars would eventually become a reality. What about a decade ago while self-driving car initiative was still very nascent. Was it possible to identify factors that could make self-driving car a reality and anticipate approximate duration for such possibility? I presume traditional companies making cars might have done such analysis to evaluate the threat matrix. Sometimes it helps to look back at history to derive some meaningful insights that can help us connect with the past in order to comprehend future.

The quantum of changes that will occur in future is much higher than what we have seen in the past. Rightly, the changes that have transpired in the last decade is much higher than the changes occurred in the last five decades. Yet, looking into the past will definitely help Product Manager to connect the dots to anticipate how smaller changes can combine and what factors could bring those smaller changes to take a bigger form. In today’s world, technology is one of the biggest drivers of changes. It has caused many changes in customer behaviors, markets etc. No industry or product is immune to technology advancements. One way of identifying future is to anticipate changes in technology landscape and understand how it could impact existing markets or create new markets, change customer behaviors or create new needs etc. Ideally identifying factors related to technology would be a perfect start to understanding future.

Understanding causal-effect

Any transformation in customer behaviors, market or technology would cause a paradigm shift. Understanding causal-effect is estimating the quantum of such shift by thoroughly anticipating all causal factors and analyzing how those factors could cause the paradigm shift and when. No change is independent. There is always a correlation of smaller changes to coalesce into something bigger – X –> Y –> Z –> BIG CHANGE i.e. paradigm shift. There are always some elements acting as a catalyst to combine smaller changes (‘X’, ‘Y’ and ‘Z’) into a bigger change. The smaller changes need not essentially combine linearly or sequentially, it can sometimes be a complex tree structure. For simplification, I choose a simple linear model of combining smaller changes. Along with identifying the smaller changes, Product Manager also had to identify the catalyst that can combine those smaller changes to spur a bigger change. Evolution of technology, market and customer needs will have so many connected pieces that Product Manager has to identify those pieces and identify what connects those pieces together to anticipate bigger changes.

There are two ways to do it

Bottom up

  • Identify smaller changes and later anticipate what connects those smaller changes to coalesce into something bigger
  • Product Manager has to be all ears and eyes to spot signs signifying smaller changes and use scenario analysis to anticipate how those smaller changes could culminate into something bigger

Top down

  • Anticipate a potential bigger change and work backward to identify what smaller changes could combine to cause those bigger changes
  • Analysts provide quality data on trends that might dominate the future. Their data can be a probable source of truth.

Nowadays analysts do a fantastic job of predicting how customer needs, technologies, and markets evolve in future. Product Manager can rely on analyst information, but instead of overly relying on the analyst data Product Manager should try to rationalize their predictions by identifying what elements or factors could cause their prediction to come true. I did attempt to rationalize what would cause virtual reality to enter the mainstream market by 2020.

Virtual reality is supposed to be a huge market by 2020. Firstly, let us understand why virtual reality has not entered the mass market today.

  • Is the technology not affordable? Is the technology not mature?
  • Is there not a relevant and appropriate use of virtual reality technology?
  • Has the virtual reality ecosystem not evolved completely?

Understanding what stops virtual reality from entering the mass market today will help Product Manager identify the gaps that could be bridged propelling virtual reality to attain mainstream market by 2020.

  • How can someone ensure affordability of virtual reality technology?
  • How can the technology mature? Can affordability and maturity of the technology be good enough factors for adoption of the technology in B2C space?
  • What would be the appropriate use of virtual reality that can attract a mass market?
  • In which segments, would there be demand for VR devices? Existences of what business drivers would cause the demand for virtual reality products in those market segments (particularly B2B)

While I was building the new product (HW appliance, back in 2013), NFV (Network Function Virtualization) was an emerging technology that was holding lots of promise (especially in Service Provider market). NFV was predicted to be a billion dollar market over a period of 3 – 5 years. Naturally, we want to have a pie of that growing market through building a virtual appliance. However, I attempted to a make a rational analysis to understand the real possibility of NFV gaining tremendous adoption in service provider networks. We analyzed what stops customers from adopting virtualization in service provider networks. We drew following observations that prevent the adoption of virtualization in service provider networks. Below observations, reflect scenario as in 2013 and not as of today.

  1. Lack of killer use-cases
  2. The inability of virtualized products to meet desired performance levels required for delivering right RoI
  3. Lack of products to orchestrate, manage and load balance the traffic to virtualized instances and
  4. Lack of clear and tangible advantage over HW appliances

We later analyzed the presence of what factors would allow bridging of above gaps to increase adoption of virtualization in service provider networks. We did analyze that (3) cannot hold ground. When there are even remote signs of customers adopting virtualized products, companies building products to perform (3) will automatically burgeon. The primary aspect that was blocking adoption was performance. Without improvements in performance, which will eventually lead to doing more processing on a single core CPU, it is tough to accelerate the adoption of virtualization. The performance improvement was on increasing trajectory and it was merely a matter of time before it reaches desired levels. Meanwhile, we decided to leverage that time focusing on conceptualizing use-cases to determining the product-market fit. Conceptualizing use-cases require a discovery process along with customers to understand their business environments and challenges that virtualization can tackle uniquely. To do so, there is a need for a tangible product. Without anything tangible, a mere whiteboard discussion will not yield results. Therefore, we attempted to create an MVP version of the virtualized product (i.e. a software appliance running within a virtualized environment). The existence of a real product can help articulate value while allowing customers to experiment with the product to derive real use-cases leading to a better product-market fit.

Even though analyst will outline when technologies such as Big Data, IoT, Self-Driving Cars, Virtual Reality etc. would reach mainstream marketing, Product Manager should independently assess how those technologies will attain mainstream and in which market segments will they achieve mainstream. The idea is to assess what factors would make the technology affordable and usable, which segments would contribute to demand of those technologies. Accordingly, Product Managers can evolve their products to capture a majority of the predicted growth. Product Manager should always be inquisitive and curious constantly asking ‘WHY?’ with insatiable quest to unravel the enigmatic future of markets, technologies, and customers.

Why look into future?

Focusing on future needs and identifying those needs can help Product Manager anticipate customers of tomorrow and needs of tomorrow. Accordingly, Product Manager can conceptualize a product architecture that is scalable for future needs. What I had noticed is that the fundamental need does not undergo many changes, what changes are the scale and the outcome. While regulation and economic factors contribute to either accelerate or decelerate the demand for a need e.g. France to ban all petrol and diesel vehicles by 2040.

  1. Scale – Support for more users and functionality generate demand for more processing power, storage etc.
  2. Outcome – Technology evolution facilitates delivering differential outcome e.g. AI/Machine Learning is drastically changing how certain needs (autonomous driving vehicles, fraud detection) are addressed efficiently and effectively. New age companies like Uber/Airbnb while addressing a classic need creates a new normal through delivering differential outcome embracing technology. While building a new product, what new outcomes are possible with the emergence of new technologies and what possible threats or opportunities confront the new product. Accordingly, Product Manager has to ensure that the new product is capable to embrace potential opportunities or thwart potential threats.

Focusing on future needs and identifying those needs can help Product Manager anticipate customers of tomorrow and needs of tomorrow. Accordingly, Product Manager can conceptualize a product architecture that is scalable for future needs. Every product has certain scale parameters and every scale parameter has an expiry date. Product architecture plays a crucial role in determining whether those parameters can scale beyond their initial limits. Some of the parameters have a soft limit i.e. the parameters can scale beyond their initial range without requiring too much rework. Consider SaaS products, demand for a SaaS product can rise from 1000 customers to 1 million customers very quickly immediately after determining the product-market fit. With cloud providers like AWS, Azure scaling of SaaS products is never difficult. SaaS companies can deploy and distribute multiple instances of their products globally. Cloud providers have efficient load balancers to manage those instances. Therefore, it is sufficient to build a SaaS product for few thousand customers and scale them as the demand arises. However, scale parameters of few other products (mostly HW products) have a hard limit. Increasing them requires a lot of rework, requires Product Manager, architects, and developers to hit the drawing boards. What we should essentially consider is the cost of revisiting the drawing boards. There could also be a counter-argument that what if customers would never require the scale that the product delivers. True, we are then not adapting lean development methodologies. We are wasting resource attempting something that customers never require. It is for Product Manager to make those trade-offs. Ideally, I would recommend to first determine product-market fit before making any decision on scaling. The thumb rule would be to nail the product before scaling it.

Building new product involves lots of decision-making. Certain decisions are irreversible or reversing them will cost a lot. Other categories of decisions are always reversible. Decisions involving scale parameters with hard limits are irreversible decisions and the decisions involving scale parameters with soft limits are reversible decisions. Product Manager has to make both kinds of decisions during the course of building the new product. However, certain irreversible decisions are dependent on anticipation of how customer requirements evolve in future. Irreversible decisions cannot be made irrationally. The decisions are taken thoughtfully after analyzing all possible risks. However, for a well-informed decision-making, Product Manager should develop deeper insights about customers to understand how their future requirements might evolve. Developing customer insights is like unearthing those deep truths about customers that customers themselves might not have acknowledged directly.

Considering the lifetime of an HW product or a complex SW product could at least be for five years with a possible extension of support for a couple of years, anticipating how future might affect the new product is crucial for ensuring that the new product is scalable for precise future needs of target customers. Furthermore, longer the relevance of the product in the market, better the ROI, as the incremental cost of building additional HW product is minimal. For SW products, the incremental cost of building additional software is almost zero. So building scalable products that can sell more for a longer duration is required for better revenues with higher margins while adhering to lean practices without wasting any resources unnecessarily through developing better customer insights.

The ultimate goal is to create a mental map of all possibilities of future and then identify the factors that determine the likely occurrence of each of those possibilities. The biggest responsibility of Product Manager is the ability to narrow down the possibilities to just one future that is most likely to occur based on the identification of corresponding causal factors that is highly likely to occur. The fundamental idea is that we should not leave anything to chance while building enterprise product that is future proof.

Please drop your thoughts or experiences on how you managed to build enterprise products for unknown future.

[1] Source:

Should Product Manager prioritize defects?

I have seen many debates on Quora and other related forums regarding how Product Managers should prioritize defects against product requirements. Now my belief is that both are different and I am a firm believer in ‘Engineering owns quality’. Even though quality precedes everything, Product Manager does not pitch defects against product requirements. No product is defect free and every requirement added to the product begets more defects. Product Manager would collaborate with engineering team to determine the tolerance level for the overall open defects or defects open rate. Accordingly, allocate a window in each release for resolving defects avoiding any conflict with product requirements. Ultimately, it is the responsibility of engineering team to prioritize and resolve defects within that window. Engineering team should have complete authority over prioritization of defects and resolve them within the guidelines of quality SLAs (Service Level Agreements) even it is a severity defect affecting customers’ business. Product Manager will be encroaching into their space, if (s)he starts prioritizing defects.

I would definitely loathe if my engineering team is busy fixing defects at the cost of evolving the product. As I had said earlier, both engineering team and Product Manager should agree on the tolerance level for defects, if occasionally the defect rate goes higher because of certain unforeseen reasons, I would urge Product Manager to make more room for resolving defects probably at the expense of not addressing few requirements. However, if it happens too often, then the problem is addressed by identifying the actual root cause. What is causing more defects and what is causing the decline in quality should be ascertained to improve quality in a long run instead of continuing fixing defects at the expense of evolving the product. It is as important to continuously evolve the product as it is to maintain the quality of the product. There cannot be any trade-off between them.

Moving target of customers’ needs – A unendorsed challenge of building enterprise products

The primary emphasis on building a great product is to discover a right problem and getting married to it. However, customers’ needs and problems are increasingly becoming moving targets. The needs and problems evolve, so do the solutions to address them (i.e. the outcome too evolves) triggering an uncertainty of which needs or problems to address and what outcomes to deliver. It is a challenge that has primarily gone unendorsed or not consciously realized until now. The biggest mistake that Product Managers commit while building new product is to freeze needs and problems at a specific point in time and start building products for those static needs. Nevertheless, Enterprise products address hard problems and building such products consume around 12 – 24 months. With technology evolving much faster than ever, market dynamics changing too fast, and human race undergoing more changes than before, new needs or problems emerge, prevalent needs or problems extinct, and solutions embracing technology advancements to address needs or problems come in various shapes and forms. Primarily, Product Manager cannot taste success building a product for static needs. Product Manager should learn to hit a moving target anticipating how needs or problems change as a function of time in future. Agile methodologies and MVP (Minimum Viable Product) address those fallacies by reducing development cycles and incrementally validating whether the product is addressing right needs or right problems and delivering right outcomes. However, MVP seldom works for enterprise products.


Why MVP and agile methodologies could not address those problems of dynamic needs?

Enterprise products affect real businesses of customers, they might either help customers increase revenues, manage costs or streamline operations. The fundamental truth is enterprise products affect business in some form and hence they should be robust and resilient with zero-tolerance for failures while addressing a real business problem that is at the top of customers’ priority list. Therefore, delivering something quick, validating it and incrementally evolving the product does not augur well for enterprise products. Enterprise customers seek a complete solution. There is also a necessity for shrouding development efforts of certain enterprise products in secrecy to introduce an element of surprise and euphoria during launch. Then, how do Product Managers validate enterprise products causing minimal interruption to its targeted customers? Through maintaining a subtle balance between using MVP and relying on customer insights and experiments. Product Manager shall use MVP at the initial stages of product development to validate whether there is a real problem, whether the new product is addressing the real problem, and whether the new product is targeting the right customer segment. The problem with that approach is MVP does not consider time as one of its parameters. While constructing a hypothesis and validating assumptions using MVP, Product Manager has to validate assumptions across time space ensuring whether needs or problems persist across the duration of the product lifecycle and identify how they evolve. The appropriate approach is to understand the causal effect between needs, problems and corresponding factors that cause them. MVP framework for such analysis is:


The fundamental premise is to understand what is causing the need while validating the existence of a real problem or need and bundle the findings with customer insights to understand how the need or problem manifests in future. Understanding causal-effect of the need and its corresponding triggers along with customer insights should provide required clarity about the relevance of the need or how the need evolves in future. Customer insights are essential to comprehend what has caused the present to diverge from the past and use that as a reference to anticipate what will cause future to diverge from the present. Building customer insights are one of the key foundational pieces for building great products that enterprise customers want. Product Manager has to build customer insights through experiments and observing customers in their natural habitat, immersing in their business, assimilating their business process, problems and challenges and not just listen to what they say but to read between the lines to understand what they did not say. There is a dire need for restoring the lost art of gathering customer insights. MVP bundled with customer insights and experiments are required for validating any assumptions related to the new product and building a visual map of how customers’ needs or problems evolve and what new outcomes they might desire. Product Manager should learn to hit a moving target anticipating how needs or problems change as a function of time in future. How do you hit a moving target with an arrow, we notice the rate at which the target is moving, how long does it take for an arrow to hit the target and accordingly predict the possible position of the target when the arrow is released. Product Manager should do something similar not just to understand needs and problems of today but also to predict the needs and problems while the new product hits the market. Doing so, the new product will hit the bull’s eye when it hits the market.

Why does moving targets of needs and problems affect enterprise segment alone?

A unique challenge that Product Managers encounter with enterprise products alone and it is not applicable for consumer products is that enterprise customers’ are resistant to frequent product upgrades because of CAPEX (Capital Expense) and OPEX (Operating Expense), they tend to use a product for a longer period of 3-5 years (especially on premise products). On the contrary, business models of most consumer products rely on frequent product upgrades. There is no benefit in stacking all the value in a single product and making customers stick to a consumer product for 3-5 years. The duration for moving target of needs or problems of enterprise customers just shifts from product launch to eclipse the entire duration of product life cycle.


Product Manager should anticipate customers’ needs or problems as a function of time across the entire duration of product life cycle. Customer insights combined with extensive knowledge of how markets evolve, how technologies evolve, and how customers’ behaviors change should provide an estimation of how customers’ needs or problems change as a function of time and what new outcomes are possible. For certain enterprise products, addressing customers’ needs or problems as they evolve is not entirely possible without building a product architecture or a platform that can scale. I was once managing an HW product used by ISPs (Internet Service Providers) for defining policies of their internet users. During the launch of the product, internet speeds offered to each user was low. However, the internet speeds offered to each user raised exponentially far exceeding our predictions and the product could not meet the new requirement resulting in the early retirement of the product (or rather the product has to retire prematurely). In the enterprise segment, we tend to face a similar problem with complex SW products as well and refactoring the architecture can help but it will be costlier. Even so, refactoring the entire HW or product architecture takes time and there is a risk of not being able to address evolving needs or problems in a timely manner. When the only thing that is certain about future is uncertainty, a question that stares at every Product Manager is how to anticipate what needs will prevail and what new needs will emerge. In most cases, needs will be static, but the scale required varies. Another question that stares at every Product Manager is how much to scale and when?


Please keep watching this space as I revert back to further to continue the conversation on this topic. Meanwhile, I would like to understand whether you agree with above challenges. If so, please share your thoughts in the comments section below or drop me a note at If we are not reaching an agreement on this topic than any further conversations will be futile, looking forward to hearing your thoughts or opinions.

Creating a chatbot using – Layman’s guide

When you start learning ML and become fascinated by it, you will never stop with learning certain models. You will try to understand how it applies to some real world problems or outcomes. One such outcome is chatbot, I have been wondering about the possibility of creating a chatbot using NLP (with actual algorithms) and not using any tools. However, my learning is not progressing briskly to start implementing the algorithm for the real-world problem. Therefore, I contemplated using already existing tools/APIs to make some progress. Did some basic research and with some gut feeling choose and it turned out that my choice was actually great. did a great job in creating a chatbot with few easy steps.

This blog outlines the steps that I followed to create my first bot and everyone can follow it to create something fundamental. May be, those attempts can drag you into the worlds of ML, Statistic etc. All I can say is that it is a fascinating world to reside currently. allow sign-in only through Google account, they cite security reasons for not providing additional options, but I believe it might be to have Google hegemony. Why would not they, after all, Google acquired After signing in, you get a console as show below or if you are redirected to home page of, click on GO TO CONSOLE to start your journey for creating a chatbot.

Step 1 – Creating Agent.

Create a new agent (option is available on the upper left)

Provide an agent name, your bot will be referred by this name. Add a description that aptly describes your bot. Unless you are importing any existing agents, leave ‘ADD SAMPLE DATA’ blank. Change the time zone to reflect time zone of your location. Unless you already have any Google Cloud Project and wish to use it for chatbot agent, you can allow to create a new Google Cloud Project for your agent.

Finally, click on SAVE to create an agent.

Now a page, as shown above, should appear and it would provide options to create INTENTS, ENTITIES, and CONTEXTS. Before I delve into those details, there is setup icon next to agent name on the top left side. Click on it to make any changes to the agent.

Step 2 – Agent Settings

Settings page offers 4 tabs i) General, ii) ML Setting, iii) Export and Import and iv) Share

I only explored i) General and ii) ML Settings.

In i) General, clicking on Project_ID will redirect you to Google Cloud Platform. It is required if you are planning to leverage APIs. Otherwise, do nothing on the (i) General tab.

On (ii) ML Settings tab, try experimenting with ML threshold value. I tried modifying it to 0.50 while the default value is 0.30 (the acceptable value is in the range of 0 to 1). 1 indicates the best match if there is no best match INTENT, the response of FALLBACK INTENT will be displayed. For a higher value of threshold value, there is a high possibility of not matching any INTENT unless you provide too many options while defining INTENT for to train itself.

After any changes, do not forget to click on SAVE button.

Step 3 – Creating Intent

By default, there are 2 Intents already created for chatbot i) Default Welcome Intent and ii) Default Fallback Intent

Default welcome intent will be activated for the WELCOME event or if a user says ‘Hi’, ‘Hello’, or ‘Welcome’ depending on the list of user expressions in ‘User Says’.

Default fallback intent will be activated if user query does not match any Intent. You can add your default response in the default fallback intent. If there are more than text response in any Intent, what I had noticed is that the response will be used in round robin fashion whenever the Intent matches

Click on ‘+’ sign alongside Intent on the left side to create an additional Intent. The basic element for creating Intents is to identify all possible unique responses that you intend to provide to your users and what will be the user expression (or query) for each of those unique responses.

Since I was creating a chatbot for my product. I could think of user expression to know what is the product, why it is used, what is the cost etc. Accordingly, I created an intent for each response and identified the list of user expression for each unique response.

I have a created an Intent to respond to user expressions regarding what does the product do. Therefore, I created an intent outlining user expressions as shown in the picture below:

I did not explore Contexts and Parameters much. I will reserve that for a follow-up. However, I will explain what I did Entities. Now if you look at one on my user expression – ‘what product does AVC support?’ Apart from variations in user expression, users can also multiple words to refer something. In the above user expression, my customers generally refer AVC with NBAR or NBAR2 or NBARv2

If you took a close at the above picture again. On the right side, I have tested the agent with a user expression – ‘What platforms does NBAR2 support?’ Technically it is similar to ‘What products does AVC support’ but I have used platform instead of product and NBAR2 instead of AVC. To seek a better response from BOT what I did is to create Entities for defining synonyms as shown below:

I created similar entities for product keyword as well mapping it with product-line or platform.

Later, I went back to Intent and mapped those 2 words i) product and ii) AVC to corresponding Entities as shown below:

Chatbot now intercepts AVC, NBAR2, NBARv2, and NBAR as AVC. Instead of creating multiple user expression for each combination, creating Entities makes it easier now and I am also able to solicit a better response from chatbot.

The user expression has now matched parameter ‘AVC’ and ‘Product’. Please go ahead and create a chatbot with simple Intent and it is a lot easier now.

For integration with Cisco spark, please head to Click on MY APPS on top right side and later click on + sign to create a new app. Now click on ‘Create a BOT’ to get an access token and supply the same while selecting Spark as an option under one-click integration.

My chat transcript my with my BOT

As a next step, I am planning to explore Contexts and integrate with Webhooks as well. If someone has already done it, please do reach me. I might need some help 🙂

Addition of new Product Manager – Can it be an opportunity to add a new perspective to the product?

We all heard a lot about dos and don’ts for a Product Manager during first 30 days to make herself familiar with i) People or Stakeholders, ii) Product and iii) Market.

Why don’t we flip the coin and identify dos and don’ts for a hiring manager or a mentor during first 30 days of a new Product Manager? The arrival of a new Product Manager is an opportunity to bring in a breath of fresh air, contest the status-quo and to add a new perspective to the product. The role of a mentor during those 30 days could make a lot of difference in realizing that opportunity.

Perspective of an outsider

As we start doing things repeatedly (building products, pricing, marketing, strategy), we slowly but steadily fall into a trap of doing things in a certain way, sometimes it becomes the only way which is familiarly called as status quo. Things get terribly worse when status quo remains uncontested for a long time. Especially during those times, a view of an outsider can help unmask the trap that has consumed us.

A new Product Manager can bring-in a perspective of an outsider unearthing details that did not catch the attention of the team earlier.
• Is the product easy to spot and order?
• Are customers getting all possible information about the product?
• How easy is the product to use?
• Are we adopting the right business model?
• Is the execution aligned with product strategy?
• Is the product missing out on certain target segments that could increase the revenues?

Focusing on bigger scheme of things, there is often possibilities to miss little details and we take them for granted. New Product Manager can possibly spot them. Ideally what a mentor can do in those 30 days is to allow new Product Manager explore on her own, take her own path, pick her own directions, decide her own course of journey to finally let the world know what she has discovered. Mentor could just step aside and watch the progress while providing occasional guidance without influencing the thought process of a new Product Manager.

Never say what to do

Product Management is more of an art than science and there is never one way of doing things, so creating boundaries around what a new Product Manager should do and how he should do curbs the creativity and potentiality of new Product Manager.

New Product Manager was hired because she might have shown some promise during the interview process, then why force her to execute a pre-drafted plan rather than allowing her enough space to exhibit her talent.

The best part of a hiring process is not just in hiring a great talent but also in creating an environment for the great talent to unleash her potential.

“It doesn’t make sense to hire smart people and then tell them what to do; we hire smart people so they can tell us what to do.”
– Steve Jobs

Even if the house is on fire, the best way forward is to provide an opportunity for a new Product Manager to take a pause, grasp everything on her own and plan how to douse the fire effectively.

I strongly believe in diversity in the team – diversity in thoughts, diversity in education, diversity in experiences, and diversity in beliefs. If you have a Product Manager with an engineering background, ensure that another Product Manager is hired with sales, design or any other product with exception of engineering. Heterogeneity in team spurs innovation through holistic thinking.

Inquisitiveness and ability to network

Does this model work? Depends on the ability of new Product Manager to self-start, network, and remain curious.

Product Manager should be inquisitive and should have the ability to network to build a relationship with all stakeholders to get s@*t done. The journey of a new Product Manager discovering the product, people, market etc. would essentially put to test those skills. The curiosity of a Product Manager would thrust her to explore more by constantly asking why and in the process new Product Manager could also attempt to shackle the status quo bringing a new perspective and creating new insights.

If someone has followed this model, let me know how effective it was. Was new Product Manager successful in discovering insights not construed by existing team? Appreciate your feedback in the comments section or drop me your thoughts at

5 ingredients to building a great product

Building great product requires a mindset with multi-disciplinary skills. Every Product Manager would learn those skills only through hard way of building products, validating those products with customers and reinforcing the feedback back into building better products.

Based on my experience, I have listed 5 key essential ingredients to building great products.

  1. Audacious problem– Pick an audacious problem to address that no one has addressed it earlier or neither addressed in a way that you are addressing it. Doing so, the product will exceed every expectation to the astonishment of your target customers. All along ensure that customer really care for the problem to be addressed and they definitely pay a premium for addressing it. For doing so, you need to have extensive knowledge about customers and their needs.
  2. Think bold, think future– While picking a problem, think how it manifests in future. Do not just provide a solution for today’s problem. Even though it is critical to address today’s needs, your focus should be on extending the solution to address tomorrow’s needs. While addressing the problem or need, do not constraint yourself with existing technologies or existing benchmarks (What Elon Musk did to electric cars). Probably, your idea or solution to address the need or problem should pave for new technology evolution or change in customer behaviors. When Steve Jobs thought about the problem of stacking 1,000 songs in a device, he would not be constrained by whether any existing technology can store so many songs in a small form factor. Instead, his idea would have driven the evolution of such technology.
  3. Simplicity– This is one principle that is essential for every product. No matter how complex problem you are addressing, there should be simplicity written all over it on how customer will use the product to address their problem or needs
  4. Do one thing right – Be focused on doing just one thing. Do not be everything to everyone. Even if your product has to do multiple things, just focus on delivering awesomeness on specific elements of the product that will drive customers preference towards the products, instead of doing everything right.
  5. Impeccable execution – Nothing beats impeccable execution of the new product. Even a mediocre idea with perfect execution will win over an awesome idea with poor execution. As Ben Horowitz rightly said, focus on the little things and big things will take care of themselves. The statement is true more so during product development, Product Manager should start focussing on all little things even as simple as color and package of the new product.

Are the above five, the exhaustive list? Definitely not, there might be other things as well, but this is what I have learned from my experiences. It is not essential that all great products adhere to the above. For instance, some great products can address a simple problem, but the experiences that they deliver to customers will be a real differentiation.

Beyond those 5 attributes, the most primary aspect is to Start defining the WHY – Strong product vision that outlines the purpose and belief behind the new product

Finally, Product Manager should believe in the product, should believe in her abilities and in the abilities of her team to build an awesome product.

I captured some of those details in my eBook (free copy): Building New Product

Disclaimer: Even though I have built products, I fell short of building great products. I definitely learned how to build awesome product through the hard way of building and failing:-(.


Why every Product Manager should know Machine Learning

Machine Learning (ML) is becoming ubiquitous and every single product out there is attempting to use some flavor of Machine Learning to better address customer problems and delight them. Even though ML is still evolving, it is no more a fad and it is not restricted to those familiar use-cases of image recognition, page ranking, spam detection, autonomous cars etc. Appropriate use of ML algorithms is essential to differentiate every product and delivering a better value proposition to its customers.

Machine learning is evolving faster than any other technology and it has the potential to break new grounds creating more opportunities through providing solutions to problems that were evading us for a longer time. Even products that are not entirely ML dependent, where it already addresses a certain problem, harnessing ML can help the product better address the same problem. ML is soon becoming the de facto technology for every product and its Product Manager, ML offers only two choices (1) Embrace ML effectively or (2) Fad into oblivion. Ideally speaking, there is only one option to pick.

In this entire conundrum of how to embrace ML, can ML offer an effective solution and what are the other alternatives, how ML is better than those alternatives, how to validate the efficacy of ML, and what is the real value delivered to customers? What do you think will be the role of PMs? Please be aware that the context of this blog is to products that are not entirely ML dependent unlike autonomous cars, speech recognition etc.

Great PMs should be tremendously good at discovering, identifying and later defining the problem – What is the problem that the product has to address. Great PMs spend time identifying a problem that is worth addressing. Focus on technology and solution is always secondary. Technology always evolves and so does solution. Identifying the right problem provides the right start to identifying the right technology to delivering the right solution. PMs should focus on identifying the problem and it is entirely the responsibility of engineering to identify right flavors of ML based on the problem statement provided by PM.

Then… Why am I bragging about PMs being aware of Machine Learning? I foresee three reasons for it.


Speak the language of engineering

Even though, PMs should focus more on the problem and less on the solution and PMs need not play a role in drafting HOW to address the problem using ML, PMs should definitely have the technology acumen to understand the HOW.  Understanding of HOW will position PMs to unbiasedly evaluate how exactly ML is better at addressing the customer problem, does it really add significant value. Incorporating ML does not automatically bring results. There is no magic behind ML. ML has to be harnessed in a right way with a right set of data and models to contribute the right value. Rightly so, It is the not the destination that is always important, the journey is also equally important to ensure that PMs took a notice of the efforts by the engineering team and not just the outcome. I always believe in rewarding efforts and not just outcomes. During the journey, PM should speak the language of engineering to comprehend their efforts and to assist them as well. Let me imagine a fictional conversation between my engineer and me after I asked for his assistance to help me predict product revenue based on earlier collected data.

Engineer: Hey Murali, I have used multiple models for classification problem. However, the bias is too high with all those models and we have a problem of underfitting. Guess we need more features.

Me: What are features?

Engineer: Any additional information that can augment existing customers data.

Me: Oh, I have customers age and country.

Engineer: Is there a strong correlation between country and the revenue generated

Me: Hmm … Correlation? I doubt

Engineer: No, the data is not useful we need something else. Unless you provide additional data, I cannot build a good prediction model

Me: Completely lost in the jargons, not sure what data to collect. Notwithstanding, I do not know a dime about ML, I will start doubting the capabilities of my engineer. I gave data of 1000’s of customers. Yet he is asking for more data, what the heck?

PMs interface with many entities (Engineer, C-Level Execs, Sales, Marketing, and Account Teams etc.) and speaking their respective languages gain mutual respect and trust. When I insist PMs should learn ML, I am not focussing on the ability to build a new model but to understand existing models and at least to the extent of mapping the problem on hand to one of the right flavors – Prediction, classification, ranking, clustering, or anomaly detection etc. PMs should understand the overall landscape of ML to differentiate reality from fad and for absolute clarity on what is possible to solve using ML.


What lies beneath the surface?

Customers (mostly B2B) are not merely interested in what happens above the surface, they are keen to understand what happens beneath the surface as well. It is essential for Product Managers to explain how the product works in addition to articulating what the product could do for them. Without understanding the specific flavor of ML used in the product and how it is improving the overall efficiency of the solution, it would be tough for Product Manager to succinctly articulate the details.

There is a $ at stake and B2B products are evaluated rationally than emotionally, so the person implementing the product will be curious to know what data is used to validate models and what is the accuracy rate of the outcome. Customer will be interested in knowing the precision score, recall score, and F1 score. In simple terms, customers might be interested to know the rate of false positives and false negatives to consolidate his confidence in the outcome delivered by the product.


ML will soon be as fundamental as Excel to PMs

After I scratched the surface of learning ML through online courses at Coursera and with hands-on of Python courses. I primarily understood two things that ML can soon become de-facto technology for data visualization and analysis alike Excel.

  1. Presenting the data is a fundamental skill that every PM should possess. Companies are sitting on top of a goldmine of data related to products gathered internally and externally. With an increase in collection of data, there should be efficient ways to process and visualize data to get newer insights through adapting newer scalable techniques. The technologies used for presenting the data should evolve and PMs can no more restrict their expertise to basic some graphs in XLS.

Matplotlib, Seaborn and various other libraries are having tons of pre-built plots to visualize data in a meaningful way. Using those libraries are not rocket science. Anyone with basic knowledge of programming should be able to use them. Considering that majority of PMs are either developers or designers, using those visualization libraries should be a piece of cake. What matters is that the options those libraries provide to visualize data is tremendous. PMs do have huge chunks of marketing, sales data on their hand. It might not be always feasible taking assistance from engineering to choose right plots for visualizing the data. Visualizing data can provide more insights than plain numbers on a sheet of paper. There are options for bar plots, scatter plots, correlation through heat maps, country/world map etc.

PS: Some of those libraries are already available with excel, but I feel Python provides more flexibility. Using Python reminisces those lots days of programming. Guess, once a developer always a developer :-).


  1. It is not just visualization, analysis of data is also important. At a very fundamental level, every Product Manager should forecast revenues or assess the probability of a deal to succeed or not, cluster customers into segments based on certain common demographic elements. Again, I am speaking mostly from the context of B2B segment. For data analysis, PMs can understand the nature of the problem – prediction, classification or clustering and pick one of the already available algorithms to analyze the data. Ability to interpret errors such as mean squared error, f1 error etc. on both training set and validation set can help Product Manager identify alternate solutions to address bias/variance tradeoffs. The Internet has tons of pre-determined solutions for addressing bias/variance tradeoffs for various combinations of bias/variance problems. ML is definitely a valuable tool for analyzing data and constructing meaningful interpretations of marketing data to define pricing, design market campaigns, define strategies to acquire and retain customers etc.


How did I got started

Ever since I started learning ML, I love every bit of it. Probably, it was because of my passion for mathematics and I have a background in statistics. If you detest numbers, then I bet ML will definitely be boring for you.

My journey started with a course in Coursera by Andrew NG. It provided me a basic understanding of Machine Learning fundamentals.

  • What is supervised and unsupervised learning?
  • What are various models under each of those categories? How to identify the right model depending on the use-case?
  • How to measure and interpret error for various algorithms?
  • When to use regularization?
  • What are bias and variance? What are techniques for bias/variance tradeoffs?
  • When to add more features to existing data and when to augment more data to existing data?

Awareness of above details is sufficient to speak the language of ML with engineering, to understand, appreciate and complement their efforts,  and comprehend what is truly possible with ML.

Andrew NG course also requires some amount of programming. It is not too difficult as they do too much of handholding. If you have been a programmer earlier, try to avoid the normal use of loops and instead use vectors to solve problems. Vector methods are faster and pretty much the entire algorithm is programmed in almost one single line. Utmost 90% of the problems, I solved using vectors. Before you get started, gain some basic understanding of vector operations. For me, it took some time to realize that [A] * [B] is not equivalent to [B] * [A] and also to realize that vector multiplication of 2 elements are possible only if the number of columns of the 1st vector is equivalent to the number of rows of the 2nd vector. Ideally, brush your fundamentals in mathematics, if you are more interested to know how algorithms are derived for various models then you should familiarize in algebra and calculus.

After Andrew NG course, I explored for few courses in Udemy for hands-on experience exploring ML algorithms and I picked the following course: Python for Data Science and Machine Learning Bootcamp (it is cheaper :-)). I completed 50% of the course and the focus is exclusively on using existing Python libraries for solving ML problems. However, the course does not provide any theoretical foundation on the background of various ML algorithms. I am loving every bit of my journey so far. I hope that I will sooner start solving some basic problems in Kaggle. However, for PMs, I would suggest to start and end with Andrew NG course, unless you intend to dive deeper.

MIT also offers a course on Machine Learning. If you are looking for a dataset, Kaggle offers many datasets to play around with ML algorithms. Another good resource is MNIST. In addition, IBM Watson also offers certain tools for validating problems related to data science. However, I am yet to explore it.

Please share your thoughts and opinions on learning ML. I wish good luck in your journey of learning ML.

The WHY behind the Product, have you defined it?

What is ‘THE WHY’ behind the product? Why it is essential for every Product Manager to identify it?

Why - PurposeAll of us intend to build and evolve better products. However, we lose the plot blindly chasing competition and trying to appeal every customer that comes our way. Eventually, the product loses its purpose without any direction. How many of us can unambiguously articulate the THE WHY behind the product that defines its purpose in a single tweet?

I am sharing my thoughts on why it is essential to define THE WHY behind the product even while conceptualizing it and how THE WHY can transform the way we build our products and how it will convert our relationship with our customers from a transactional into a relational engagement.

THE WHY behind the product can unambiguously articulate why the product is built both from the perspective of Organization and customers. Further, the Organization beliefs lay the foundation for the purpose, together they define how the product is built and evolved, and they provide a framework for decision-making governing the product. Whatever a Product Manager does in relation to the product – strategy, vision, roadmapping, marketing, pricing etc. is eventually tied to one single element called ‘THE Purpose’.

What does your Organization believe in – Is the product built upon that foundation of belief? New product built without any belief sans purpose. What the new product could do and how it could do does not define the purpose. Those are transactional items purpose is much bigger. Purpose underlined by a strong belief puts every stakeholder involved with building the new product in a state of self-actualization where they are inspired and motivated to do what they do. Purpose can also define the marketing message that will make customers believe in the product believe in what it does. The difference between good and great product lay in its ability to define why.

The difference between good and great product lay in its ability to define why

Organization beliefs

Conceptualization of the new product should happen upon a fundamental foundation that characterizes the belief of the Organization. The belief that eventually dictates what the product should stand for, why does it exist and how it is intended to achieve the desired functionality. Food for thought, what does great companies like Apple, Google, Facebook, Amazon, Netflix (or even older companies like  Toyota) etc. believe in, are n’t their products direct reflection of what they believe. Therefore, every new product built should embody the beliefs and the new product vision should be a reflection of those beliefs.

What does Apple believe in – Shall I state ‘Innovation, Simplicity and Building Great Products’.

In the words of Tim Cook, following are the values that define Apple.

We believe that we’re on the face of the Earth to make great products.”

 We believe in the simple, not the complex.”

 We believe in saying no to thousands of products, so that we can really focus on the few that are truly important and meaningful to us.”

– Tim Cook


 Values are rather action words that are born out of beliefs and purposes. Are n’t the above-stated values provide a foundation for how Apple build and evolve its products? Therefore, any new product idea conceived in Apple should adhere to the above beliefs

  1. Can the new product idea transition into a great product?
  2. Does the new product idea epitomize the principle of simplicity?
  3. Can the new product idea be transformational for the Organization? Can this idea be the next big bet?

It is not about building unique products, but building products uniquely that no one else dared to build so. There are limitless possibilities for building products uniquely, If Organization believes in something unique and if it has the commitment and conviction to stand for what it believes in. iPod is not a unique product, it entered the market after the market was flooded with lots of music players. What makes an iPod unique is in its approach to building a simple and elegant music player that had powerfully integrated the device, software (iTunes) and music unlike any other device has done before or done after. Apple did follow similar unique approach for iPhone too and I believe they will do it repeatedly for any product that they will ever conceive in future.

It is not about building unique products, but building products uniquely that no one else dared to build so


Any new product that is ever conceived should pass the belief test, everything else that is associated with the conceptualization of the new product (idea validation, product-market fit, business review, and new product approval) are mere transactional. Product Manager had to take care of those transactional items as well, but passing belief test will hold the key for the new product success as it will transform the entire new product development from a transactional engagement into a relational engagement. How does entering into a relational engagement makes any difference?


Transactional vs relational engagement

Simon Sinek thoughts on ‘Start with WHY’ are very profound that it should find its place in identifying the belief behind the new product. When Product Manager embarks on the journey of building the new product – (s)he should start her journey with a belief that lays the foundation for building the new product, a foundation that succinctly articulates why are we building the new product both from the perspective of Organization and customers. Product Manager should articulate the bigger purpose of building the new product, through creating a vision of the world that does not exist yet. The vision that can unambiguously communicate how the new product will transform lives of customers thereby helping the Organization scale greater height.

Golder circle

Simon Sinek has talked about 3 levels of engagement How? What? and Why? as part of his Golden Circle concept that explains each level of engagement.

When the focus is only on WHAT the new product does? and HOW does it does? The Organization is creating a transactional engagement among all stakeholders both internally and externally sans any purpose.

When the focus is on WHY? The Organization can succinctly articulate its belief and the purpose of its existence. The belief of Organization will lay the foundation for building all new products, a foundation that defines why we are building the new product both from the perspective of Organization and customers and a foundation that can also define how to build and market the new product. The belief imparts the purpose within each stakeholder, so all stakeholders know why they are doing what they are doing. Revenue, growth etc. will not define the belief or purpose. All those elements are by-products of the belief or purpose.

Transactional Engagement vs Relational Engagement

It is not what we make or sell. It is what we believe makes a lot of difference both internally and externally. Belief is contagious and it would spread across to every stakeholder involved with the new product – who sells it, who builds it, who markets it, who supports it, who evangelizes it, who conceptualizes it etc. unifying everyone with a common purpose and vision. There would be now absolute clarity on why we are doing what we are doing. So everyday battles that all of us fight will be around identifying how we can collectively realize the vision of the new product instead of being skeptical about what we are doing. Everyone will be a guardian of the new product vision and struggle to realize it.  There will no more be voices that utter – are we doing the right thing. However, voices will instantaneously raise when there is a deviation from the new product vision, which eventually implies that there is a potential conflict with the belief and purpose as well.

It is not what we make or sell. It is what we believe makes a lot of difference both internally and externally


In a transactional engagement, employees know what they are doing albeit with little clarity on why they are doing what they are doing. There is also little clarity on where they are heading. They come, they work, and they go with lots of ambiguity in direction and purpose. Under such circumstances, each employee is a mere foot soldier acting upon certain instructions and when they had to make certain hard choices, they always falter, because employees did not embrace any purpose or values.

On the contrary, in a relational engagement, the belief and purpose will define a set of values (refer to Apple example provided earlier) and those values when imbibed into the DNA of each employee will give them enough knowledge on how to react in any situation by upholding those values. The decision-making will be flat and it does not always have to traverse from top to bottom. Employees always have best knowledge and wisdom to take a decision. Organizations make better products and survive longer if employees take decisions. However, Organization should aid them with guidelines. Belief and purpose are the only way to provide guiding principle or tenets for the decision-making process.

Organizations make better products and survive longer if employees take decisions


Look at Walt Disney’s purpose – ‘We create happiness’. Irrespective of their business, they believe in creating happiness. When customers start believing in Walt Disney, start believing in their ability to create happiness, they patronize their products irrespective of movie or theme park. Even employees of Walt Disney will use the purpose and belief of creating happiness as the foundation for conceptualizing new products (movies or theme parks) or evolving any of their existing products (probably theme parks).

Transactional vs relational engagement does not affect internal stakeholders alone. It does influence the way customers perceive about the Organization, perceive about products. It even influences the way customers’ interfaces with Organization and makes a buying decision.


So, Did you find your WHY?

When Organization finds its WHY? It is defining the future that the Organization is attempting to create, it is leading the change, and it is envisioning a new world. The new products are merely facilitating the future. When customers understand the WHY (i.e. purpose), they do not see products they see the future. Doing so, Organization is not selling the product it is selling the future. Customers get a palpable sense of the world that does not exist yet. Finally, customers will find something promising. So please do not wait, let us find WHY? to pave way for building a great product.

When organization defines its WHY? It is defining the future that the organization is attempting to create, it is leading the change, and it is envisioning a new world

When customers understand the WHY (i.e. purpose), they do not see products they see the future


In a transactional engagement, the horizon is blurred. None has the bigger picture and overall direction. Thereby interactions happen at a product level, at a feature level. Interactions and discussions always happen relative to what others do. Competitors do it, so we need to do it better. Customers require it, so we need to accomplish it. Multiple conflicting priorities pull everyone in multiple directions without any unifying purpose and direction. Choices of customers, competitors, partners etc. will influence our directions and purpose. Finally, Product Manager will lose sight of what really differentiates the new product.

How often has a Product Manager noticed following comments when interacting with customers – I see something missing in your product that is available in competitor products, the product does not follow standards, I don’t know how it will add value to my business, your product is too pricey – I get competitor products for cheaper price, competitor is offering more etc. What those conversations mean to all of us, more specifically to Product Manager, the engagement with customers is merely transactional. In a transactional engagement, we will always be at the mercy of someone who can yield influence with customers. If the new product should not go through those conversations and if it should not be influenced by external stakeholders, then start with WHY? and articulate to your customers, so they believe in what you believe.

Why do you think people buy Tesla? Do people buy Tesla because they believe in the vision of Tesla to build powerful electric cars? Do they buy Tesla looking at the specifications of Tesla models, convinced about the underlying technology and technically impressed at the built of Tesla? I bet that majority of customers belong to the former category. When customers start believing in what Organization believes in, they trust the ability of the product to redefine future. Details of the product will not dominate any conversations with customers. Customers do take pride in associating with such Organizations and its products. They take pride in being part of the journey that transforms the future.

Defining WHY? is essential but what is more important is the commitment and conviction to deliver.


Commitment and conviction

Organizations should believe in something that is unique and they should have commitment and conviction to deliver. Exploration is the first step in identifying a belief, which is bold. Boldness in belief does not take us anywhere without a stronger determination for execution. Any fundamental change affects three parameters (i) people, (ii) process and (iii) business. All those three parameters should align with the belief and aid in flawless execution. A candid introspection of the current state of the Organization, what events or actions lead to the current state, and where the Organization intends to head from now can help identify what changes are required to the following three parameters (i) people, (ii) process, and (ii) business. Any form of history always fascinates me and it definitely offers some concrete knowledge on how to build our future based on our past actions. On those lines, I want to quote the words of Andy Grove – Author of ‘Only Paranoids Survive’ and Ex-CEO of Intel.

I have seen far too many people who upon recognizing today’s gap try very hard to determine what decision has to be made to close it. But today’s gap represents a failure of planning sometime in the past.”

– Andy Grove


To get the buy-in of everyone internally, Organization has to show the sense of urgency on why we need to transform now. The urgency has to be articulated to employees, shareholders etc. There is also need to articulate – What is in it for everyone – What is in it for employees. It is not always about monetary benefits. Sometimes, there is a need to articulate the bigger purpose. The inclusive approach will make employees feel that they are playing a bigger role in driving change. Shareholders should also understand what is in it for the Organization. They need to understand the results of transformation and why defining a belief would work. People embrace change only upon realizing what is in it for them.

People embrace change only upon realizing what is in it for them


Customers and employees do not instantly believe in what Organization believes in. It takes time. Until then Organization should walk the talk and exemplify its belief through its execution. Otherwise, it would be tough to gain the trust of both employees and customers. Belief is contagious only when more advocates believe in what Organization believes in and who can radiate the belief to others on behalf of the Organization.

Call for Action

If you have not defined ‘THE Why’, do it today. Start by identifying what does your Organization believe in and how it can articulate the purpose of the product. If you agree with my views or if you have different point of view, please drop your thoughts in the comments section below.


Step-by-step guide for ROI computation of new product

ROI computation of the new product after determining the pricing and the model (SaaS or a perpetual model) is a simple sequence of steps. Product Manager with a flair for mathematics would get rid of this phase with utmost ease as long as (s)he is able to forecast units sold for each quarter for the entire lifetime of the product. Yet, some of us falter as ROI computation is not an everyday activity. So through this blog post, I have tried to provide a step-by-step guide for computation of ROI of the new product. To compute ROI for any new product, we should determine the following.

  1. Revenue estimation
  2. Cost estimation
    1. Operating costs – Cost of engineering, Capital expenses for buying equipment
    2. COGs – For HW products
    3. Royalty payments for IP (If applicable)
    4. License costs – If the new product incorporates SW of other vendors
    5. SG & A –SG & A covers sales, marketing and other administrative expenses associated with the new product. Standard mechanism is to calculate it as fixed % of overall revenues.
  3. Cannibalization impact
  4. Operating Margin
  5. Cash flow
  6. Breakeven or Payback period
  7. NPV (Net Present Value) of all future cash flows
  8. IRR (Internal Rate of Return) of all future cash flows

For better illustration, let us assume the lifetime of the new product as 3 years and it took 1 year to develop the new product. Duration of a year is for conceptualizing the idea, validating the idea, building the product and finally, launching it. Completion of product validation through MVP process also happens within the duration of a year. Even though revenues start flowing from the 1st quarter of a 2nd year, the ROI calculations should happen from the 1st quarter of a 1st year, as costs will be incurred for development of the new product and there will be capital inflow during the period. It is essential to include 1st year to measure negative cash flows and calculate payback period.

Important milestones for illustration

  • The start of product development – Q1 Y1. The 1st year includes all the activities related to product development – Idea validation, business review, product development, product development, MVP validation etc.
  • Product Launch – Q1 Y2. The launched product could be termed a minimum valuable product that customer prefers to buy. The sales of the new product happens from Q1 Y2

Therefore, all calculations that I will do going forward will be done for 4 x 4 (4 quarters for 4 consecutive years)


Revenue estimation

Estimate the revenues for the perceived duration of the lifetime of the product. Ideally, I would suggest Product Manager estimates revenue based on a likely scenario. Later we can determine the worst scenario and the most optimistic scenario as % of a likely scenario. Most financials are computed on a quarterly basis, so let us follow the same standards to estimate the sales on a quarterly basis from the first quarter of enabling sales for the new products. There is a possibility to turn on pre-orders for few products before the actual launch. In such case, Product Manager should consider the date of enabling pre-order for estimating revenues and not use the actual launch date of the new product.

Q1 Y1 Q2 Y1 Q3 Y1 Q4 Y1 Q1 Y2 Q2 Y2 Q4 Y4
List Price / Unit
Discount %
Product Revenue

Table 4 – Units forecast of the new product




Cost estimation

There are two types of costs incurred during the entire lifetime of the product (i) variable costs and (ii) fixed costs.

  • Variable costs vary with a number of products sold to customers. For HW products, variable costs are incurred as soon as they are manufactured. However, for calculating ROI, it is ideal to account for variable costs after selling each unit. The costs of inventory are accounted as sunk costs after killing the product and taking it away from the market.
  • Fixed costs are costs incurred in developing the new products and they are independent of product sales. The product reaches breakeven when the revenues compensate the fixed costs.

Variable costs of the new product are

  1. The cost of SW license added to the new product – The new product can include any SW from OEM vendors. The cost paid to vendors is proportional to the number of products sold
  2. COGs (Cost of Goods Sold) of the product – Applicable for HW products
  3. Royalty payment, cost of an Intellectual Property of an external entity

Each unit of the new product sold incurs the above cost. Always calculate per unit variable cost as the sum of all applicable costs listed above.

Fixed costs of the new product are

  1. Cost of equipment required for the new product development
  2. Engineering cost incurred to build, validate and support the new product.

The above costs can incur either once or at regular intervals. The above costs are independent of the number of products sold and they do not vary with the amount of sales.

Q1 Y1 Q2 Y1 Q3 Y1 Q4 Y1 Q1 Y2 Q2 Y2 Q4 Y4
List Price/ Unit
Discount %
Product Revenue
Variable Costs
Gross Margin
Gross Margin %

Table 5 – Product revenue of the new product


Please be aware that only direct product costs are included in calculating gross margin. Fixed costs that that includes engineering cost and expenditure of capital assets incurred due to buying equipment to aid the new product development are not including for calculating gross margin. In addition to those costs, it is essential to account few other operating expenses while calculating operating margin


Any cannibalization impact?

Consider the product revenue of any existing products that the new product might possibly cannibalize as a cost.  Forecast how many units of existing product, do the new product cannibalize each quarter. Estimate the product revenue as outlined in Table-5. While calculating the net margins of the new product for each quarter, consider the product revenue of the cannibalized product as cost.

Q1 Y1 Q2 Y1 Q3 Y1 Q4 Y1 Q1 Y2 Q2 Y2 Q4 Y4
List Price/ Unit
Discount %
Product Revenue
Variable Costs
Gross Margin

Table 6 – Product revenue of the cannibalized product

Total product revenue is the difference between the product revenue of cannibalized product and product revenue of the new product.


Using the above equations, I further proceed to compute the operating margin after accommodating the cost of cannibalization.

Q1 Y1 Q2 Y1 Q3 Y1 Q4 Y1 Q1 Y2 Q2 Y2 Q4 Y4
Product Revenue
Variable Costs
Gross Margin
Gross Margin %

Table 7 – Net product revenues of the new product


Operating margin

SG & A is the other major costs incurred by the new product. All expensed incurred for sales, marketing and administration of the new product are tagged under SG & A. In general, fixed % of revenue is allocated to SG & A. Please be aware of all the operation costs tracked in your organization. The majority of operating costs are calculated as fixed % of product revenues. For SG & A, let us assume SG & A spend as 10% of overall product revenues. Account fixed costs due to an expenditure of capital assets and engineering cost while calculating operating margin.

Q1 Y1 Q2 Y1 Q3 Y1 Q4 Y1 Q1 Y2 Q2 Y2 Q4 Y4
Product Revenue
Variable Costs
Gross Margin
Capital Assets
Engineering Cost
SG & A
Operating Margin
Operating Margin %



Cash flow

Cash flow indicates the amount of cash inflow after deducting all expenses from the product revenue.

Q1 Y1 Q2 Y1 Q3 Y1 Q4 Y1 Q1 Y2 Q2 Y2 Q4 Y4
Operating Margin
Capital Expenditure
Cash Flow
Cash Flow (after Tax)
Cumulative Cash Flow

Cash flow is mostly same as operating margin unless there is a need to account for any additional capital expenditure that was not accounted earlier. The early investment on the new product proposal was not consciously accounted, as it will be later spent on engineering, buying equipment etc. Those costs are accounted anyways. Otherwise, we will double account the same money.


However, if there is any capital expenditure that we have not accounted until now should be accounted in cash flow calculations, the formula is

Breakeven or payback period is the quarter during which the cumulative cash flow turn positive for the first time.


NPV (Net Present Value)

The entire lifetime of the new product is 3 years. Therefore, organization earns revenue on the new product for 12 consecutive quarters. NPV indicates the current value of the sum of all future cash flows (both positive and negative) after deducting tax.

Use NPV formula in excel to calculate the NPV of both operating margin and capital expenditure.

  • NPV of Operating Margin = NPV (LendingRate/4, Operating Margin of Q1Y1: Q4Y4).
  • NPV of Capital Expenditure = NPV (LendingRate/4, Capital Expenditure of Q1Y1: Q4Y4).
  • NPV of Cash Flow = NPV of Operating Margin – NPV of Capital Expenditure

Use the standard applicable lending rate and calculate the rate for a quarter.


IRR (Internal Rate of Return)

IRR is the rate at which the net present value of all future cash flows both negative and positive is zero. IRR is a measure of attractiveness of investing in the new product. To calculate IRR, use IRR formula in excel.

  • IRR = IRR (Cash Flow of Q1Y1:Q4Y4) * 4

Sometimes, we might have to present 3 scenarios for projecting ROI

  1. Less Optimal – This is a worst case scenario for the new product
  2. Optimal – Optimal situation and which is most likely to happen and
  3. Most Optimal – Best scenario for the new product.

Product Manager can draw a scenario analysis to identify what factors would lead to each of those three scenarios. However, for estimating ROI for three scenarios, I would probably do it for an optimal scenario. For any scenario, estimating units forecast is the beginning. For less optimal and most optimal scenario, we can compute units forecast as % of units forecasted for an optimal scenario. Probably, I can use 80% for less likely and 120% for a highly likely scenario. After estimating units forecast, diligently following the above steps will help Product Manager compute all the required data for measuring ROI of a new product and build a financial summary for all the three scenarios.

Financial Summary
Scenario Less Likely Most Likely Highly Likely
Product Revenue
Variable Costs
Gross Margin
Gross Margin %      
Capital Assets
Engineering Cost
SG & A
Operating Margin
Operating Margin %      
Payback Period      

Table 7 – Financial Summary

The above table summarizes the entire elements related to financials of the new product. CFO or VP Finance will be interested in checking whether NPV is attractive and IRR is above the expectations of Organization. During the business review and later for pricing approval of the new product, Product Manager will use the financial summary to summarize the overall attractiveness of the new product.

The excel sheet to perform the above ROI calculated could be downloadable from New Product – ROI.xlsx.