Against The Minimum Viable Product

I’m sick and tired of the complete lack of understanding of what a Minimum Viable Product (MVP henceforth) is by a lot of startups and enterpreneus. First, I think most of them never really understood what an MVP really is (a quick Google search can prove elucidative). Second, posts like this on “startup blogs” are like cancer: they focus on the technical plan as being what MVP is all about. They convey the idea that if you build it using some fancy technical buzzwords (e.g. Node.js, NoSQL, Heroku, SaaS, etc…) you got it. They couldn’t be more wrong: an MVP is a product strategy not a business one.

Another fundamental mistake is believing that the “holy” MVP will teach you what your users/market want thus shaping your product into inevitable success. To quote someone we would all recognize as Knowing What The Hell He’s Talking About™ 1, “A lot of times, people don’t know what they want until you show it to them.” If what you show them, minimum as it may be, fails to strike an emotional connection, you’ve failed to impress. When you fail to impress, you won’t get valuable feedback and feedback is the critical component of an MVP strategy. Good feedback comes from users who believe in your product, not 1000 beta testers who signed up to feel special about themselves. Valuable feedback can’t be disconnected from care for the product. Building a product based on feedback from users who don’t care is like going to your doctor for an opinion on your car purchase: uninterested, disconnected, potencially worthless. When was the last time you’ve seen Apple put out what many people consider an MVP? Even on their software products, their initial presentation is designed to strike the “I want that!” emotion.

A truly valuable MVP strategy is one who aims to delivers a clear, emotional connection at every release cycle. Sure you learn from your users but if you focus on what they tell you to build a product, you’ll become a amorphous mass of pixels and bytes. The key to a successful MVP strategy involves stripping the function to its core but dazzling in its form. The form includes the design, user experience but also the, often forgotten, communication. An MVP strategy is not about throwing 200 features at your early adopters expecting them to tell you what sticks, what doesn’t and what’s missing. That’s just doing products the lazy (expensive!) way 2. An MVP strategy is more about communication than it is about functionality: communicate your product clearly if you want clear feedback.

I can’t talk about MVP without talking about early adopters. A very common misconception about early adopters it to think they’re likely to embrace change. No human being embraces change until proven useful/better. I would say most early adopters are open minded but are usually driven by finding new ways to do the same things. If you’re product is disruptive, you can’t rely on their opinions for defining your product: you should teach them first. Early adopters are normally not that excited about a new thing past the original infatuation of a “new shiny thing” unless they can see its value over time. As such, their feedback will be determined by their current definition of how to do something. The “early adopter phase” is crucial for your product but not for shaping it: it’s your opportunity to test your communication, delivery and clarity. You’ll want to make sure they “get it” no matter how different you’re trying to do things.

As a conclusion, I’ll quote that Wikipedia article on MVP (emphasis mine):

The MVP differs from the conventional market testing strategy of investing time and money early to implement a product before testing it in the market. The MVP is intended to ensure that the market wants the product before a large time and monetary investment is made. The MVP differs from the open source methodology of release early, release often that listens to users, letting them define the features and future of the product. The MVP starts with a product vision, which is maintained throughout the product life cycle, although is adapted based on the explicit and implicit (indirect measures) feedback from potential future customers of the product.


  1. Steve Jobs, to the Business Week (25 May 1998) 

  2. No wonder so many startups raise millions before even delivering a product in any way, shape or form… They’re usually expecting the users to tell them what to do and thus need the talent to execute. Not sure I’ve ever seen that strategy work… 

Copyright © 2017 Levi Figueira
All Rights Reserved