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

Any development methodology has its fallacies unless we appropriately use them. With MVP too, we have to be cautious not to fall into the trap or abuse it too much. 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 emphasize 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 customers’ 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 more profound customer insights and balance those findings with MVP without completely hiding under the veil of MVP and Agile. The remaining blog post focuses on various traps of MVP or rather how we abuse it.


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 the right needs and the 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. Specific 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 interfacing with customers, being part of the industry for a more extended 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 of 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 significant 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 the 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 the 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 to uniquely addressing a need 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 sections 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 the first two quarters of releasing the product. A particular section of customers do not contribute 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 say, what they often say is not what they 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 a spade a spade. Therefore, I loathe feedback forms, user group interviews, etc.


Final Thoughts

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. 



  1. Hi Murali,

    Thanks for putting together a really good PM website. I am unable to download a copy of your ebook Building Enterprise Products. There is no link the download it from SlideShare. Could you please share a link to download the book.

  2. @Sourabh, Unfortunately Slideshare is now not allowing the option to upload the latest document. I am working on providing a download link in the blog. Meanwhile, please share your email, i will directly send the file.

Appreciate your thoughts or opinions

This site uses Akismet to reduce spam. Learn how your comment data is processed.