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.
70 responses to “I hate MVPs. So do your customers. Make it SLC instead.”
Great post! The hardest part is deciding what makes the SLC really C. We just deployed a brand new feature. Clearly simple. Lovable, maybe. Complete (I thought). But then customers demanded that it have one more enhancement to make complete. So it wasn’t until we deployed it, got it into their hands did we know that it wasn’t complete. Perhaps more prototyping up front could have been useful but nothing like real time feedback.
None of us get things perfect the first time! The question is intent — is the intent to create something complete, or intentionally incomplete “because it’s a test.”
And what’s interesting is, it was “viable” when you first deployed it. You got MAJOR validated learning from it, didn’t you?
True, you learned and that’s great. But I guess the issue people have is if the customers then
abandon the product forever because they had an unsatisfying experience. That’s the “you only get one chance to impress view” of things…
And that in itself is also a valuable life lesson :) which is why I’d lean towards getting to something I would consider a complete solution to some problem before I ship. I’ve never actually been in the position to ship something deliberately that wasn’t an attempt at a “complete enough” solution to some problem.
The SLC mantra is cute, but what is it really solving? My personal interpretation and understanding of MVP was never one that implied any level of incompleteness, or one that delivered no value. Does it really warrant a new mantra? Or should we focus on fixing the “interpretation” problem? In a world full of mantras, do we need another one?
If there is more M than V in the MVP, then you could argue that with time there might be more S or L than C in your SLC. Food for thought..
Yes, either way you might not have been successful. The question is, what is your goal? Many MVPs are not complete, maybe because “complete” is *expressly not* what an MVP is. It’s partial — only the minimum necessary to learn.
To quote Lean Startup — the “bible” of MVP: A minimum viable product (MVP) is the “version of a new product which allows a team to collect the maximum amount of validated learning about customers with the least effort”
That isn’t about a wonderful product or a complete one. My argument is this definition leads to putting bad things into market.
So, what SLC solves is to change the definition of what a v1 should be, that still creates validated learning.
Good point quoting the source.
Agreed. This is debating semantics. No good Product person takes “minimum viable” literally; it’s just something to keep in mind to help control the scope of the project and prevent feature creep.
If “SLC” makes more sense to folks, go for it.
“No true scottsman” fallacy. People do take it literally.
Enjoyed the article, but the “V” in MVP is “viable” meaning it works. So pictures 1, 2, and 3 (the wheels without the car) aren’t actually MVPs bc it’s not viable. I agree with @perezbox:disqus it’s more of an interpretation problem. I think what “SLC” does is to make it more clear for people who misinterpret MVP.
We all want to get to the same end state. But words matter. I don’t know about you, but the majority products I’ve seen which their creators dubbed “MVP” are not SLC. My point is, I think that behavior is wrong. You can say “but that’s not what MVP means,” but that’s what it often actually is in practice.
Yup, you’re trying to communicate what you want in an effective way as a leader in the company. You’re talking in practice vs in concept.
Amen. And personally, I find L far more arbitrary and subjective than V.
If it’s not viable, it’s definitely not MVP. Viability isn’t determined by whether it “does” some thing or whether it does that thing well. Viability is determined by how willing a potential user is to use it and by extension, pay (in money or time) for that utility and the value it brings to them.
If you try to sell me a shell of a car when I see no utility in that on its own with no way to invest in it, a shell of a car isn’t viable. But if I have an engine and wheels and you offer me a body and a chassis and I’m willing to invest the time, physical and cognitive energy needed to turn the combination of those parts into something more, then even just a shell _is_ a viable product.
MVP *must* take into account the audience/target market. Without this, viability is too loose and indeterminate to make any assessment of whether a product is truly MVP… or any other TLA you can think up for it.
It’s my experience in practice that objects which their creators dub “MVP” are certainly M but often not V. You argue that this means they just don’t understand V.
I can accept that, in which case I would argue that SLC helps *define* V in a more concrete way, and I would argue that the MVP concept *needs* better definition of V because people are often not doing it properly.
The other way to do it — the way I took in this article — is to escape the baggage of MVP and try to change the attitude.
If MVP is “often not V” than this is not MVP. So you can’t say MVP is not good. Because you already discuss not MVP.
I guess the whole problem is nobody knows how minimal can still be somewhat viable. The MVP mantra does encourage startups (in versions that I’ve seen) to emphase the M, to launch, in order to experimentally find out whether V or not yet V holds, to make the point that perfectionism burns cash without empirical support. (I suppose there is something selfish about using customers as guinea pigs.)
I think, as some article commenters suggest, the V is the key part to the MVP model. Maybe that’s what gets lost with some products teams. The graphic logic is flawed in that products 2 and 3 are not products that have any viability at all and isn’t a true representation of what happens with a competent product team. These models ultimately are exactly the same thing, however, SLC just strongly emphasizes viability and explains further what true viability should mean.
Finally, someone calls out the Emperor for having no clothes.
The MVP fan boys are always going to claim the “V” covers any sins or omissions, but it really doesn’t.
Let’s talk about another Emperor’s wardrobe while we’re at it. VC’s want to reduce risk as much as possible for themselves regardless of what that means in terms of increasing risk for entrepreneurs or their customers.
I’ve worked with them through 6 different startups and that’s a black and white fact, not an opinion.
Michael Porter defines 3 successful strategies:
– Build the Best
– Sell the Cheapest
– Serve a niche that #1 and #2 aren’t adequately serving
There’s no, “build the minimum viable product” competitive strategy there, but you can certainly see how those 3 benefit the customer which is more than I can say for MVP.
Make your customers happy by delivering something they want badly and can’t get anywhere else. That’s all any entrepreneur should be worried about.
An MVP can be a way to figure out what #2 or #3 is. “Does this still meet the requirement while being cheaper cheaper cheaper?” (Can I get away with making X out of cardboard instead of plastic or metal) and “Does this meet the requirement as understood differently from how the incumbents have understood it?” (Are there customers who care more about “battery-operated cordless vacuum” than about “powerful vacuum for my whole house”?)
OK, like the article. Here is the problem, and maybe you can help me with some ideas.
Let’s say my industry is cars. Everyone has cars at stage 5. They drive Fords and Chevy. Of course, I want to disrupt cars and make them electric. Yep, I’m that guy.
My MVP can not be an electric skateboard. It has to be the Tesla sports car. If it is an electric skateboard I will never get to the big market.
My industry is not cars, I am trying to bootstrap. Do I have to raise money from VC to get a usable MVP?
I completely agree that there are products in which neither “MVP” nor “SLC” are appropriate models. Cars are one. Rockets are another if we’re invoking Musk. But also pharmaceuticals and restaurants and many other things.
So I agree “SLC” is not a universally good idea, but I submit that in those conditions in which an MVP would be appropriate, the SLC idea is also appropriate, but a better attitude towards the work and the goal.
Loveable article I should say. And the entire debate too. Why? Its progress….there are many concepts and key words in Agile (Scrum and not only) that we need to come back to, with clarity and new meanings that come from practicing Agile in the real world. A great insight is “spoken here” – people don’t really get what a MVP is. Proof? The v1’s they release in the market.
Spot on!
“Viable” has two different synonyms “Usable” and “Possible”. My observation is that most of the products take the meaning of “Possible”. In the sense that do what is “possible” with the resources on hand. Getting that 1.0 version out is more important. “Usability” can be always addressed/tinkered/polished in the next version.
With SLC, “Complete” is brought into discussion. Keeps it in the forefront. Hopefully, SLC will catch on.
Not sur I understand the C. The purpose of an MVP is to mitigate risk by validatig assumptions and release a viable product to learn and readjust your assumptions. If by complete you mean pretty much all bells and whistles then I hope you don’t have any assumptions made on your product because the longer you wait the more you risk to produce waste.
Don’t need icing and sprinkles, but do need the cake to be baked.
OK then, you don’t mitigate your risk and better be sure that everyone will love your product the way you imagine it.
Interesting point of view. If you hate MVP’s you are not an early adopter and should not be using them.
For me MVP’s provide enough value that they are a desired alternative to current solutions or lack thereof.
Fair point, but many MVPs are not honestly portrayed as early products, so people in the middle majority might not realize (until it’s too late and they have a bad experience) that they are actually alpha testers. I completely agree that if you call it “alpha,” you’re being honest and then something that’s not yet lovable or complete is not only acceptable, but it’s expected and appropriate.
Agreed, I think too many startups try to gain traction and grow outside early adopters prior to reaching product market fit. Thanks for the post.
I work in a mature market, we practice lean (as we can) and we like the term Minimum Compelling Product, something that a customer would be willing actually pay for and use in their business or convert over from and existing product. We gather feedback all along the way, but it is not really a Viable product until one of those 2 things happen.
I like “compelling!” Thanks for adding that idea to this mix.
What if you end up with 4 skateboards instead of a entry level family car. This is what I have seen happening. The push to launch a completely new feature means that ‘simple’ features never get iterated on and improved.
Agreed. Of course MVPs suffer from the same problem. I agree “SLC” doesn’t solve the problem you identify.
Version 1 has to transform the lives of a user…otherwise it likely kill the project…
Any experience of applying the SLC mindset on Enterprise products?
The Enterprise realm always seems a step (or two) behind consumer based products and the Agile/MVP mindset is setting in. So I’m looking for advice on moving the needle even further based on the knowledge you’ve gleaned.
We specifically sell to Enterprise, so yes! The older Enterprise companies act like you’re saying, but the new ones don’t. I do agree that often “For Enterprise” does mean more complex, for example in integration with authentication systems, control & governance & compliance concerns, etc, depending on what it’s for. Not everything can be simple, and yet complete.
Very interesting insights Jason! Thanks to your post and the commentary, I’ve gained a lot of knowledge on making more progress by leveraging the SLC concept mixed with MVP.
That brings up a good point. Enterprise vs consumer-based products aren’t in the same category to compare, however. BUT when you develop ‘enterprise’ or say, ‘non-consumer’ products, I think you can call it SLC or MVP or frickin’ PDQ (for all that matters) because the client constantly holds up the SLC/MVP to their pre-conception of the ‘finished’ product and both SLC & MVP fall short; and they always will. Regardless of what you call it.
With consumer friendly types, you’re introducing something so there’s no pre-conception to overcome. Cuz isn’t that what it’s about? Managing expectations?
Ugh. Reading what I wrote here…I am jaded. LOL
Haha! Hope I didn’t start your weekend off with a bad vibe!
Not remotely. I appreciate it. We’re already starting to implement a “SLC” approach here.
You seem to start be redefining “MVP” as a piece of junk, and then spend many paragraphs explaining how customers don’t want junk. (That part, at least, is true.) But if you’ve built something that nobody wants, how could it have been “viable” in the first place? What do you think “viable” means?
You even show Spotify’s cool graphic which says “MINIMUM VIABLE PRODUCT” in all-caps across the top … and then in the very next sentence you claim that this graphic actually describes a “SLC product”. That’s not just dishonest, but utterly dismissive of and disrespectful to the Spotify team. I think they know what an MVP is.
Where did you get this idea that “MVP” means it must be crap? You go to great lengths to split MVCs into successful and well-executed ones, and failed poorly-executed ones. The good ones get rebranded as “SLC”, a term you just invented. Any that were not successful must have been merely an “MVP”. No true Scotsman would disagree with this categorization!
Thank you for the constructive rebuttal.
I didn’t get the idea that MVP *must* be crap; rather I observed that often, in practice, it is crap. In fact, the impetus of creating this idea three years ago (we’ve been using it for a while at WP Engine) is because other people were talking to each other about how they hate feeling like they’re really alpha testers for new apps that aren’t ready, which creates defend by saying “it’s just an MVP.”
Furthermore, while I agree with you that the *spirit* of MVP *ought* to not be that way, I would argue with you that the canonized literature on the subject de-emphasizes the points I’m making and emphasizes that the point is a selfish one — to do the absolute minimum required to learn.
As evidence, the direct quote from Lean Startup, which surely counts as a canonical work on this topic, is: “A minimum viable product (MVP) is the version of a new product which allows a team to collect the maximum amount of validated learning about customers with the least effort.”
It’s true that this definition doesn’t detail what “V” is. So, if you like, you could consider SLC as a sensible shorthand that defines V. In that case, maybe you’d agree it is indeed useful to have some definition of V that does NOT include using customers who think they’re getting a real product, as alpha testers of a crappy product.
IMHO MVP does define “viable” — “enough to collect maximum validated learning.” Which a crappy implementation won’t do– it’s bad enough that it is impossible to learn much from because people won’t engage with it. It has serious dealbreaking limitations.
These were my exact thoughts reading this article. I’m sure it does well as click bait. Sigh I hate the internet sometimes.
My take is that products need to “delight”, even those few features. The problem with many MVPs is they’re half-baked. In a world with too many options, if you don’t make a good first impression, it’s game over.
“Delight” is a nice goal, but like “Lovable”, it’s absolutely not a requirement unless that’s the entirety of the benefit. Is a jet engine “delightful” or “lovable”? I suppose it’s possible, but plenty of wonderful products aren’t thirsty for customers’ love and affection.
Good article. But you may misunderstand what MVP is. Your SLC is almost same as MVP by definition. Especially in Silicon Valley all good startup’s MVP has completed core function, absolutely beautiful. The problem is most entrepreneurs misunderstand the idea of MVP. Their self-claimed MVPs is actually a prototype.
And the reason you have to be embarrassed with your MVP is not because your MVP is incomplete, but because you can not know the right answer for new market or radically new solution.
“Their self-claimed MVPs is actually a prototype.”
I think that’s really the heart of this article, not that MVP is a bad term inherently, but that people misunderstand it, or use it to justify releasing a prototype, and excuse it’s shortcomings by calling it an MVP. While it makes for a lengthy acronym, it seems like most commenters here would agree that SLC and MVP really should be the same thing, but people interpret the V differently (or forget about it), so the SLC term is valuable for me to be able to easily define what that is.
Great article! I like the change in perspective, SLC is how the customer should view the product. Undoubtedly this changes how you approach your design. MVP is more focused on how to help the company, not the customer.
I think what you are trying to say here is that how people are making MVPs is wrong, as what you described as an MVP in the beginning is not really an MVP at all. And, what you described as an SLC is actually very close to what and MVP really is.
Whats wrong is how people have construed the meaning of it, which is exactly how people talk about agile and lean as a bunch of processes.
I think it depends on how you explode the term MVP. In my mind, the minimum a product must achieve to be viable includes a level of loveable and understanding of end-user. The assumption that an MVP can’t be loveable and is somehow incomplete is totally based on the mind assessing the MVP. So when I hear “I hate MVPs”, am told “we should be making Simple, Loveable and Complete” I look for a solid argument to back it up. This argument is far from solid, but subjectivity based on assumptions. I call bullshit. SLC does not express a comparable methodology, but just helps define the criteria of how to asses an MVP. It could also be taken apart easily with a subjective argument.
“[…] without re-evaluating whether it’s the right way to maximize learning while pleasing the customer.”
This looks like a convenient lie to set the stage. But it is simply not true. The bastardisation of the MVP, and its effects on product development is an ongoing discussion, and has led to alternative formulations, like Minimum Marketable Product, being proposed. Ironically, the illustration by the Spotify team is an artefact from exactly the discussion you claim doesn’t exist. :-)
Taking “MVPs done right”, slapping your own brand on it, and claiming you invented it is sure to backfire.
This is reinventing the wheel to me, you even show the skate to car sample which has been the MVP mantra sample for decades, exactly the same example but turning it into something subjective to the end user perception which if applicable, it’s all about perceptions from these consumers/end-users. It’s been a long while that people was moving away from the MVP concept, the concept that was a norm in mid 2000’s and earlier when it barely existed Google and Amazon, not even Facebook globally around yet, and there was so much room to grow that making some initial crappy products was ok. It’s pretty obvious that the internet has evolved enough to make customers pickier and they not embracing minimal products, they raise their expectations on what’s viable, lovable. I can’t see the value of being “lovable”, it’s too subjective and it’s hard to make someone love something as everyone likes things their way, maybe in B2C models it might have some sense trying people to irrationally love your toy, in Business Schools they spent dollars and time in teaching how to dig into consumers mind to make them love your brand or product, not necessarily related to development not capabilities or features of the actual product, this model is not definitively suitable in the B2B space where rationality is the norm.
Anyway, in my startups we use the concept of EVP (Exceptional Viable Product), and we use it in both B2C and B2B as it makes sense in both and it’s far more objective:
https://public-media.interaction-design.org/images/uploads/eeed84f28dd350ac56cec63214ad267a.jpg
Exceptionality comes to many ways, not always bound to nice to have features or making the product “lovable”, it runs away from pursuing a minimality because in our current world you cannot go with crappy products, and when we talk about the exceptional product we talk about: stability, scalability, real 24/7, real HA, start off from the beginning with SLA if B2B at least in Custom tiers, customer support, customer success staff (likely to be the founder(s)), good documentation, etc. not only the UX, the features, etc. When people faced, in the old world, an MVP, they forgot about almost everything, they ask themselves: “why do I want a very expensive, time and resource consuming tasks like setting an in-place customer support, why in the hell I have to do a duplicated resources infrastructure with HA if I only got 10 customers and it’s costing me big bucks, why should I apply high security standards from databases’ disks to front servers instead of going to cheap SSL certificates and we’ll see in the next phases? Twitter was 25% or more time down for excess of traffic during a long time and they did not care much it seemed to me, and they were successful, very MVP mentality”.
Exceptionality is turning your MVP in features and Exceptional product from the very beginning into something real, robust, beyond tangible, simple or slick but absolutely complete in terms of customer success. In the skateboard to car typical example an EVP would be at least the number 2 with vitamins: the skate with handle and seat
http://image.made-in-china.com/2f0j00mNpasZMrGvoA/Popular-Folding-Electric-Skateboard-with-Handle-and-Seat.jpg
The skate with handle and seat (and brakes) is actually an EVP, is something that is far more usable for a broader audience, has far smaller learning curve and has tiny previous skills to have, easy to learn (most people knows how handle a full bicycle), more appropriated to more customers (the ones that have never skated before, they gonna have a bad trip with the MVP version of a simple skateboard), the skateboard with handle and seat can even have brakes, and you have to ensure you give a good service if some part fails, be ready to change in the first moments the wheels, the brakes, the seat, the handle for free if for some reason they break, you want your very first customers to have the best experience of their lives, UPS free of charge drop and redeliver to their homes. Believe me when I say that your competitors going for the bare skateboard no matter if you consider MVP or SLC no way no-previously-skaters (early-adopters) would choose them.
It’s not about making it lovable because of the set of functionality or how you use it, it’s more about making a product exceptional in all the terms and details and operation, is ensuring that your customer success strategies will work and you will not be left behind for technology or not having invested enough in what really matters, is going far beyond minimal and giving for granted it would be lovable, of course it should be, but in 2017 with the competition out there you better be exceptional.
Totally agree with Stephen Brown’s comment Viable -> Compelling. Viable was usually discussed with expectation that users would accept more inadequacy than was realistic. Further, the premise of the whole article is CRITICAL to anyone trying to GTM with a true enterprise product. (used for process chains not *individually* by multiple people) Individuals can afford to alter their behavior to *try* something new. Organizations have to do much more to plan and coordinate even a trial of a new product – and that requires that it have a pay-off for at least most of the users, but definitely for the organization as a whole. As a 35+-year veteran PdMgr, PdM coach and now/again product creator, we brand and market around a strength of UI/UX/EX (enterprise experience) that evolved from this thinking.
Admittedly, I haven’t read all the comments (read a substantial number though) – so, may be, I am repeating something already mentioned by others.
I agree with you, absolutely, that the term MVP has a huge interpretation problem. At the same time, I also tend to agree with one other commentor that over a period of time, SLC could also garner the same problem. Again, we will end up in the subjective soup – what is SLC to me is probably not SLC to my customers.
The crux is the process we use to determine the distance between what we (product owners) have in mind Vs. what the customers are willing to pay for, or at least use.
This is where I believe that a lot of people see MVP as the first step of that process – that is, build some barebones (shell) product that you can use to ‘demonstrate’ to others and get feedback.
In my view, that approach is a death-knell for many ideas – simply because when you approach others with something working, they make an instant assumption that you are selling them that exact product – you can slap any number of alpha, beta type monikers, but given the attention span of people currently, they couldn’t care. They will simply say that they will not use your product – they will omit the part (knowingly or unknowingly) “in the current form”. They do not have the time/patience to give feedback on what they perceive as a baked product.
The alternative is to NOT build anything – MVP, SLC, otherwise. Rather, be 100% clear on who your customers are, which market you are in, and what problem you are solving (or want to solve).
And then, approach those specific customers – agree on the problem characterization, and then a sketchy outline of the solution. Engage them in the thought process of coming to that solution, and dynamically tune your solution on their feedback. Remember, you are not committing to anything, you are just engaging their thought process – that is the way to get feedback on your solution, not creating an MVP/SLC.
My 2 cents.
An excellent article, and echo’s a view point I have been promoting for a long time. See: http://www.dynconcepts.com/minimal-viable-product/
As with everting, if something is poorly implemented or misunderstood it sucks. Same with MVP’s. Doesn’t mean we redefine them we just get better.
However I do think design is becoming more and more a commodity rather than competitive edge. i.e the bar has moved up, so we need to consider this part of the V in MVP ;)
You should rename your article to “I hate MCPs (Minimum Crappy Products)” because crappy and viable are two very different things. If you your MVP is crappy, it means you’ve released something crappy, not viable. Maybe, if you had done an MVP for this article, it may have turned out less crappy. (haha, see what I did there?).
Brilliant post, simple and elegant in its drive and the perfect anti example of the skateboard that is always referenced in MVP discussions. We use MVP with clients all the time, and sometimes it is right. However I do like this pivot back to building simple but complete experiences that can grow or plateau as part of the strategic plan. great post.
I have some experience with “MVP”, as I was at IMVU (the basis for Eric Ries’ Lean Startup) from the time it had 30 customers to the time it had millions of customers. I’ve seen MVP applied in many ways and I support the criticism that too often it is actually Mvp, where minimal is emphasized and viable is highly subjective, but leans towards “not viable”. It’s not that MVP is a bad concept, it’s simply difficult in practice.
I appreciate Jason’s approach to SLC, as I have appreciated previous approaches for MLP (minimum lovable product) and variants, trying to capture what is important to being “viable”, and reducing the opportunity to simply ship a broken experience to customers with the excuse that it is learning.
I also see a lot of value in the “simple but complete” requirement… I witnessed many MVP projects that shipped in half-done limbo as some customers liked it sort of, but it was broken, but not valuable enough to finish… the result is many rough edges and missed opportunities to delight customers.
In my experience there’s not only a problem in how the V is used in practice. Also the M is often misused in practice, especially in a corporate environment. Marketeers and business managers often think that their ideas for extra features are minimum viable. At the end a product is more over-complete then minimum viable. When used in practice, your SLC is not going to help in that.
Jason, I find your SLiCk concept brilliant.
The problem with MVPs is the language, and even the execution. MINIMAL does not evoke any lovable product, it evokes a minimal prototype people might use, but probably will not.
VIABLE means different things to different people. Some make it equivalient to your term SLiCk as many comments below reflect. For one, I welcome replacing MVP with SLiCk much more.
What is a fantastic SLiCk product? To me nothing beats iPhone 1.0, few remember how low featured it was. But it was SIMPLE, LOVABLE AND COMPLETE. It was not a protototype, it was fully functional, and fully lovable from day one.
Great post!
Thanks so much!
I can’t tell who is being ripped off here. You’ve just chosen another TLA that means the same damn thing. SLC = MVP = SLC
This is a great post, and the discussion below is even better. It reasured me that the quality is important. I’ve been told by my manager that we don’t need client side validation for MVP. We can add it later you see. The same guy created an MVP to replace a paperwork process, covering all the required features. It got rejected by the same people doing the paperwork because the software was s#!t.
I agree that we should not need to reinvent the wheel, but it is too easy to apply any acronims to your own context. Only discissions like this can remove wrong assumptions. Thanks for the good content.
Good take. I really like Simple Loveable Complete. It’s a more customer centric viewpoint. I’ll adopt this. If using SLC charges up your team/process and produces a better end result – then it’s correct. It’s not about the words as much as the idea words conveys. The words SLC convey the essence of the goal to somebody else without having to provide a lot of extra context. So I agree w you that SLC is better than MVP as shorthand for an overall concept. I mean, would you rather hear your baby is “loveable” or “viable?” Better standard.
You just got MVP right, and renamed it to SLC. The viablitity of MVP implies completeness, the minimality implies simplicity. Anyway, it’s a well written article, you have my vote :)
Great article. I love that Spotify diagram.