Product teams have been repeating the MVP (Minimum Viable Product) mantra for a decade now, without re-evaluating whether it’s the right way to maximize learning while pleasing the customer.
Well, it’s not the best system. It’s selfish and it hurts customers. We don’t build MVPs at WP Engine.
The motivation behind the MVP is still valid:
MVPs are great for startups and product teams because they maximize validated learning about customers as quickly as possible. But it’s a selfish act.
The problem is that customers hate MVPs. Startups are encouraged by the great Reid Hoffman to “launch early enough that you’re embarrassed by your v1.0 release.” But no customer wants to use an unfinished product that the creators are embarrassed by. Customers want great products they can use now.
MVPs are too M and almost never V. Customers see that, and hate it. It might be great for the product team, but it’s bad for customers. And ultimately, what’s bad for customers is bad for the company.
Fortunately, there’s a better way to build and validate new products. The insight comes by honoring the useful attributes of MVPs, which are listed above, while also giving just as much consideration to the customer’s experience.
In order for the product to be small and delivered quickly, it has to be simple. Customers accept simple products every day. Even if it doesn’t do everything needed, as long as the product never claimed to do more than it does, customers are forgiving. For example, it was okay that early versions Google Docs had only 3% of the features of Microsoft Word, because Docs did a great job at what it was primarily designed for, which is simplicity and real-time collaboration.
Docs was simple, but also complete. This is decidedly different from the classic MVP, which by definition isn’t complete (and in fact is embarrassing). “Simple” is good, “incomplete” is not. The customer should have a genuine desire to use the product, as-is. Not because it’s version 0.1 of something complex, but because it’s version 1.0 of something simple.
It is not contradictory for products to be simple as well as complete. Examples include the first versions of WhatsApp, Snapchat, Stripe, Twilio, Twitter, and Slack. Some of those later expanded to add complexity (Snapchat, Stripe, Slack), whereas some kept it simple as a permanent value (Twitter, WhatsApp). Virgin Air started with just a single route — small, but complete.
The final ingredient is that the product has to be lovable. People have to want to use it. Products that do less but are loved, are more successful than products which have more features, but that people dislike. The original, very-low-feature, very-highly-loved, hyper-successful early versions of all the products listed in the previous paragraph are examples. The Darwinian success loop of a product is a function of love, not of features.
There are many ways to generate love. “Minimum” and “viable” are definitely not two of those ways. The current-in-vogue way is through design: Elegant UX combined with delightful UI. But there are other ways. The attitude and culture of the company itself can generate love, such as Buffer’s blog with its surprising transparency or MeetEdgar’s blog genuinely helping entrepreneurs or HubSpot’s blog which early on was at least as instrumental to their customers’ success as the actual product. Another way is through a deep connection to the psyche and work-style of customers, like Heroku who broke with marketing tradition by filling the homepage with command-line feature examples instead of benefit-statements, thereby connecting instantly with their geeky target customer:
These are the components of the correct alternative to the MVP: Simple, Lovable and Complete (SLC). At WP Engine we pronounce it “Slick.” As in: “What’s the ‘Slick’ version of your idea?”
Besides the above, there’s another benefit to SLC when you consider what happens with the next version of the product.