In my recent work with several early-stage companies, I’ve seen the dangers of Minimum Viable Product thinking and the focus on just “getting something out there”. Often before what would appear to be core features are even built. What always seems to be missing is the foundational business thinking, the mission-critical brand positioning work.
Instead of MVP , I offer up MRE or “Minimum Required Experience”. Anyone can get a product up and running, throw up a site with promises and features to come. But are you delivering a differentiated experience that sets you apart in the market? One that will get you traction? Will the minimum experience give users the experience your brand is promising? Will it drive demand, incent retention and set the foundation to achieve scale? The MVP mindset has taken focus away from a user-centric and business-centric process. Minimum Required Experience. It gets us back to focusing on the user and the market, on the business of building a business.
Lysle, the real - and one and only - user-centric and business-centric approach is the one of 'Jobs to be Done' (cf. http://www.180360720.no/?p=4985, http://www.180360720.no/?p=5126 and e-book http://www.whencoffeeandkalecompete.com/). So, I hear 'Minimum Viable Job to be Done'.
Think this is a very interesting idea, but who does it really apply to or, rather, decides to apply it? The startup team? The advisors? The Investors? It certainly would seem that the broader experience (not to mention lack of actual experience) undermines many young companies. An analysis from Quartz, which, unfortunately, I no longer have the link to, shows that the number one reason most startups fail is because their "business model was not viable." "No market need" ranked in the same place as technical/product issues. Sizing the market and arriving at a coherent business model should sure take place before an MVP launch--or, sensibly, before any investor steps up. Unless you're a skunk works or innovation lab is just folly. It's also likely why 90 precent of digital businesses fail. So short answer: If more people applied foundational business thinking to startups--or at the very least helped startups flesh these issues out--we'd see far more successful businesses.
Dave, You ask a great question, but I've seen it too many times. Startups go to market with what they think is a MVP only to learn that other parts of the build were required to fulfill the brand promise/experience. Shocks me too. It just seems too many get caught up in getting something build without the strategic and brand foundational thinking that is critical to determining what constitutes viable. If we focus on experience instead of product, we get back to a customer and market centric analysis of viability.
I'm confused. Since when is it a viable product before the core features are built? The things you mention are all key contributors to the MVP. Driving demand, retention, and achieving scale are all pieces of viability. If you can't deliver the experience, it's not even a product.
The advantage of a real MVP focus, which is not just putting some piece of technology up for sale, are that you have to achieve all of the broader things required to support a market and build sales. Depending on the market, this includes inventory management, distribution channels and all the other unglamorous things real companies need. It comes down to: did you do everything you required to generate the cash a company needs to exist? You may not know beforehand whether you achieved this goal, but it's pretty clear whether failed or succeeded soon after product launch.
So, I see your MRE and raise you a suitably broad understanding of MVP.
Oh goody - yet another "I've seen a lot of people try and Minimum Viable Product and fail, therefore MVP is a bad idea".
In this case, the people who failed didn't produce a viable product. It's unclear why that's the fault of the MVP approach.
The core idea of MVP is that you produce the simplest thing that you think is a viable product AND then you test with users whether it actually is. If users tell you that it is a viable product, great, you go on to do other things. However, if it fails with users, you modify what you produced and try again.
The second part, "if it fails with users, you modify ... try again", is what was missing.
In other words, whether or not something is a "viable product" is determined by users, not by the company.
I agree that promises aren't product. However, promises also fail the users test and when they do, that's a win for the MVP approach.
MVP isn't the only road to success. That said, it simplifies things.
I trust that we all agree that a viable product, while necessary, isn't the only thing needed to have a viable business.
The idea behind MVP is that you start by figuring out what the viable product actually is. When you have that, and not before, you do other things to build the business. That's right - you don't "go to market" with just an MVP.
The problem with building the other things before verifying with users that you have a viable product is that it's harder to figure out what's wrong and what to do about it. Is the product wrong or is it something else? If the only thing you have is product, the answer is obvious.
Why start with product? Because that's testable on its own. For example, you can't test customer support without product (unless customer support is the product). You certainly can't test retention before product.
Why go for minimum viable? Because you want to get to viability as quickly as possible so you can start doing other things.
Valid arguments against MVP are:
 You can't test product viability in isolation.
 MVP will accept viable products that you can't build a viable business around.
I can imagine cases where  and/or  are true. (For example, you can't build a viable business around giving gold bars away, even though free gold bars are a fantastic product.)
That said, most of the time when people think that  or  applies is when those people are either afraid to test their product or want to work on the other things before testing their product. ("afraid to test" includes "I know that it works".)
Of course, one core assumption of MVP is that the folks building the product and company aren't omniscient - they don't know exactly what works and what doesn't so they have to test and modify based on their testing. If you're omniscient, MVP is a waste of time.
I really like the change. Even though I do not think it is a material change, I think it will help technological startups, with no strong business or client understanding, focus on what is important to deliver
Thomas Sutrina, I understand your comment but you are redefining the word 'minimum'. If I go for a Champagne picnic and there's no Champagne the service is below the minimum. You are confusing 'minimum' with 'basic'.
As you suggest, the minimum is in the eyes of the customer, not the designer. For example, if I produce a webtool which I think does a great job, but where the UX is difficult to use, it is probably below the minimum.
I like your 'generic enough to have a reasonable size customer base' - the secret is understanding market segment. But there is always a cost of adding features, and eventually the cost might be the start-up's viability, not the products.
The MVP is or should be based exactly on the experience the customer is looking for and getting something in place for them as soon as possible. It's also the fastest way to have a viable business that can further serve the customer as you enhance you product or service.
If you are looking from brand strategy perspective then you are right. However you got it all wrong from Lean Startup & Customer discovery methodology perspective.
You only create the MVP after you have discovered the pain points of the customer. Then you create the minimum to solve thAt problem. You don't test the minimum viable product in the beginning. You only test after you have identified the problem then you test your MVP. If the test of your MVP failed most probably what you discovered earlier of the customer's problem was not right. Then you discover again what's the customer pain point. Once your MVP tests passed the customer them that's Problem Solution Fit. That's from Lean Startup methodology perspective.