原文地址
对于创业公司来说，MVP（中文是最间化可行性产品）是在特定的市场范围来测试产品的公认的有效方式，经历了这么多年的技术进步，应该是时候用SLC代替MVP测试产品了。最主要的原因是客户基本上都讨厌MVP。没有人愿意使用一个未完成的产品，客户都希望产品是功能齐全的。MVP的弊病是太M（简化）了，也许降低了开发难度，加速了开发进度，然而，却会失去客户。
新的SLC方式应该是MVP的增强版，Simple要求产品小，易于发布，比如谷歌的Docs对比微软的Office，Docs开始只实现了Office的3%的功能，保证在网络环境下有足够快的载入速度，Docs同时也是完备的，complete，因为它可以满足日常应用的几乎所有功能，最后一点，Docs也是可爱的，lovable，和谷歌首页那极简风格一致。
下图包含了SLC相比MVP更以客户体验为主的哲学：
原文链接：https://blog.asmartbear.com/
抄录：
I hate MVPs. So do your customers. Make it SLC instead.
By Jason Cohen, August 22nd, 2017
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:
Build something small, because small things are predictable and inexpensive to test.
Get it into the market quickly, because real learning occurs only when real customers are using a real product.
Trash it if it’s a flop, or invest if it’s a seedling with potential.
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.
A SLC product does not require ongoing development in order to add value. It’s possible that v1 should evolve for years into a v4, but you also have the option of not investing further in the product, yet it still adds value. An MVP that never gets additional investment is just a bad product. An SLC that never gets additional investment is a good, if modest product.
Although not called SLC, there’s a popular meme in product circles that neatly encapsulates the idea of SLC in a diagram: The Modes of Transportation example from the Spotify product team:
A skateboard is a SLC product. It’s faster than walking, it’s simple, many people love it, and it’s a complete product that doesn’t need additions to be fun or practical. At the same time, you can evolve the skateboard by adding a stem and handlebars, to create a scooter — only slightly less simple, and definitely loveable and complete. Next, you could grow the wheels, add a seat and some gears, and you have a bike. Again, less simple but now you have a product with massive benefits of speed, distance, and energy-efficiency. Complete, but many accessories available if you choose.
Zooming into one of our examples above, Snapchat took an SLC progression similar to the transportation metaphor. The first iteration of the product was a screen where tapping anywhere took a picture that you could then send to someone else, at which time it disappeared. No video, no filters, no social networking, no commenting and no storage — simple, yet Lovable and Complete, as evidenced by its massive adoption. The insight of “no storage” was critical, but many people have theorized that the simplicity of the interface was also critical. The very fact that it was as simple as possible (while not sacrificing love-ability or completeness), caused its success.
Later they added lots of stuff — video, filters, timelines, even video cameras inside sunglasses. It’s OK for products to become more complex. Starting out SLC does not preclude becoming complex later.
With SLC, the outcomes are better and your options for next steps are better. If it fails, that’s OK, it’s a failed experiment. Both SLCs and MVPs will have that result because the whole point is to experiment. But if a SLC succeeds, you’ve already delivered business value and you have multiple futures available to you, none of which are urgent. You could build a v2.0, and because you’re already generating value, you have more time to decide what that should look like. You could even query existing customers to determine exactly what v2.0 should entail, instead of a set of alpha-testers who just want to know “when are you going to fix this?”
Or, you can decide not to work on it. Not every product has to become complex. Not every product needs new major versions every two quarters. Some things can just remain simple, lovable, and complete.
Ask your customers. They’ll agree.