Rehash of minimum delightful product: http://www.startupblender.com/minimum-viable-product-vs-minimum-delightful-product/
My two cents:
When the goal of an MVP is only speed, then they fail. When the goal of an MVP is to learn if a market exists, if a problem exists, or if a novel solution to an existing problem is validated, then MVPs can be really successful and powerful.
In my experience, people think of MVP as the default. As in, we're building a new feature, therefore, it will be an MVP. But that just doesn't make sense sometimes. MVPs have a specific function.
The reason startups focus on MVPs is because they generally take money from someone else (i.e., venture capital) to see if their idea can be a business. If it can't, you would want to learn that as soon as possible. Other people's money is on the line. If it does work, then you need to turn that MVP into a business, which means what happens after an MVP is really important.
Regarding this quote:
All too often, after shipping that first round, the inevitable happens. The product is adopted by individuals, feature requests pour in, people using the product expect more, features are added on top of features for the sake of adding, the startup of 5 is working on multiple tasks each, and everyone becomes all-too-busy to go back and “fix” the design.
This is really common. But it's not a problem of an MVP; it's a symptom of a poor product team. It's a scattered, unfocused product team that doesn't know how to prioritize. This can happen if a product team creates a Minimum Lovable Product or any kind of product.
Ok, last thing. The bit about "fixing the design". Just because customers are requesting features, it doesn't mean that the product is "broken" or that you should listen to them. Remember, at this point, your MVP should start turning into a business. Somethings that customers want doesn't align with what that business is, for example, you have to say no. Coincidentally, this is how "features are added on top of features for the sake of adding."
MVP is probably the most misunderstood and misinterpreted term of this decade. If only they had originally named it something like 'Minimum Hypotheses Test'. Less sexy but also less confusion :-)
Isn't that an MVP?
Right. If no one likes/is delighted by/loves your product, is it really viable?
People need to work on their interpretation skills. Viable means you can make money off it. That includes "lovability" (really? no, I mean... really!?)
Our field already has a reputation for being a bunch of floaty meeps. We're not going to get rid of the stigma by introducing the minimum lovable freakin' product.
I agree with you mostly, but the problem is that most people in this scene think "viable" just means the product functions—nothing more.
Viable should also mean it has a decent experience that has been thought through, and not just Bootstrap + workable code, with experience relegated to the back of the project roadmap.
Doesn't seem to be saying anything new or particularly insightful. Whatever one chooses to call it, the goal of the first thing you ship is to find product-market fit. How one achieves that of course depends on the product. There are lots of factors that determine a product's success, and "delight" or "lovability" may or may not be one of them. Having exquisitely crafted typefaces and creative, beautiful animation may be of the utmost importance to the success of one product (say, a consumer application meant to do one novel thing really, really well), and be a complete waste of time on another (say, a hospital patient management system, where other design factors, like IA, might weigh more heavily).
Absolutely wrong argument. It's not about lovable, it's about to prove a solutions.
MVP can be a bit of a contradiction. Don't blame anyone for being confused. Minimum implies building the absolute minimum to prove your assumptions. Viable means building enough that the product actually works well enough that people like it enough to use it.
Which isn't really any different from building a product. I see just one key difference - you focus on building the things that will help you validate your assumptions.
We followed lean methodology (we've built an email client called Hiri) and made our fair share of mistakes. We tried to build the minimum possible to test our assumption but instead ended up with a lot of technical debt. Building it quick and dirty cost us time in the end. Because the architecture was sub-par we couldn't add or modify features quickly enough, so ended up just building the whole thing. Luckily, we raised enough cash to get past it.
Lesson learned: it really depends on what you're building. Email is mission critical. All the usual features need to be there before you can do anything innovative. And boy, they better work or people simply won't use it. Minimum can be a very high bar.
Contrast this with a social news site. If it's down for an hour, I'll simply come back in an hour. No big deal. In this case, minimum can be minimal.
Also Rehash of minimum viable product were proud of