7 ms·

Customers hate MVPs – Make it simple, loveable, and complete instead (2017)

77 points by notoriousarun 7y ago

danShumway 7y ago
Minus the buzzwords, here's what this article is saying: when you build an MVP, you should bias towards cutting features rather than cutting polish or introducing bugs. If your MVP is filled with bugs, it isn't actually viable. You should also focus on making an MVP that people actually want. If it isn't solving a real problem ("loveable"), it's not actually a product. In other words, increase the polish of your initial releases by making them smaller and including fewer features. That's valuable advice. But if I can rant for just a minute: Do you need a completely brand new concept or paradigm or acronym to say that? No, you don't. This is mostly just playing semantic games and allowing WP Engine to subtly imply that they're better at building polished products than other companies. How do you make something simple? You make it do less stuff. That's what "minimal" means. What does "loveable" mean? It means you're solving an actual problem -- you have a real Product. How do you build an SLC? You radically cut down on the number of features you plan to ship in an initial product, to the point where you have time to polish them in your initial release. That sounds a lot like an MVP to me. If WP Engine just put up an article saying, "our software is always very polished and very usable, even in the first release", nobody would care. The way to make people care is to pretend that you've found a completely new paradigm for building software, when all you really mean is, "we're quite good at building MVPs that people like." The article isn't talking about new concepts, it's just debating what other people intend when they say individual words, and I couldn't care less. It's like saying, "we don't focus on making our product 'fun', we focus on making it 'delightful'." Okay, but what does that mean beyond the fact that a business manager somewhere thought it tracked better with potential buyers?
- oblib 7y ago
  What I got from Startup School was that an MVP didn't have to do anything at all. It just had to demonstrate what it "will" do. It's basically a "mockup".
  - danShumway 7y ago
    Huh, that's really interesting. I don't have anything against mockups, but that's almost the opposite of what I and engineers I know think of when we say MVP. The point of an MVP as we use it is to not plan in excessive detail about what your final feature-set will be, because you don't know what customers will and won't find valuable until you have a product in their hands. Get the smallest, most specific version of a useful product released, and then after that you can figure out what future iterations should do. How are you going to release an MVP to customers that doesn't actually do anything? Why would anyone download or use it?
    - DoubleFree 7y ago
      I think the point here is that your MVP should behave like the actual product in the eyes of the customer, but you do not have to actually build the functionality. By providing a lot of the service manually, you can get your initial customers quickly. Having customers means getting feedback from the product's target audience. Getting this feedback before actually heavily investing in automating the product means when you do automate, you have a much better idea of what the final product should look like and which features you should prioritize, wasting less time and money on building the wrong things.
      - danShumway 7y ago
        Just to make sure I understand what you're saying, let me try to think of an example. A number of AI companies start out by outsourcing the "AI" to something like Amazon Turk or remote contractors. From the customer perspective, the system is working as intended. The system transcribes their videos, or schedules their appointment, or whatever. In the backend, the system doesn't exist. It's just a bunch of people manually transcribing videos and manually creating Calendar links. And those companies are validating that customers will want to use the fake version before they spend the time building an AI-driven real version. Do I understand correctly, or is that different from what you were trying to say? But in that case, you're still building a product that does a thing. It's just that the product doesn't currently scale, and the business isn't being up-front telling any of its customers what they're actually buying. I wouldn't say you built a mockup in that situation, I would say you built a call-center, and you're thinking about whether or not to automate it based on demand.
- maroonblazer 7y ago
  This is a common phenomenon I see in a lot writing, both online and in print. People will take an idea, strawman it, then pretend to invent a new idea. The last step is optional. Sometimes they'll simply attack a popular idea in a - seeming - attempt to get attention. I.e. "Look at me! I'm claiming the Emperor has no clothes!". There was an HN post here in the last 48 hours critiquing mental models that followed this same recipe. https://news.ycombinator.com/item?id=22948723 https://news.ycombinator.com/item?id=22948723
  - ianai 7y ago
    I’ve worked with people who do precisely this. They’re a drag on progress at best and catalyst for breaking teams apart at worst. But they think they’re getting somewhere by doing it.
- timerol 7y ago
  They give away the whole renaming game when they talk about the image of transportation mechanisms: skateboard, bike, car, etc. They talk about it as if it's a SLC image, but the image title is "How to build a Minimum Viable Product"
- JoeAltmaier 7y ago
  Folks are getting owly in lockdown... Many startup concepts are simple, and have catchphrases. Pivot. Lean. Standup. And on and on.
- pdubs1 7y ago
  Same here. This article just lost me respect for WP-Engine. What a pedantic, naive, intelligence-insulting article. It insults my intelligence to tell me what my "customers" want, given that they've never met my customers.
- brayhite 7y ago
  I don't plan to die on this hill, but I think this practice is somewhat forgivable when assuming good intent. The author may have realized that "MVP" has lost its originally _good_ meaning and became something else. They wanted to publish a post bringing focus back to what MVP originally was supposed to be, but felt that it's meaning has become so tied to its new, less good one, that they needed a new acronym to wrap their message in. It's all reactionary, and in your own words, you acknowledge nobody would care if they just presented it as "our MVPs are what they _should_ be". I try to assume good intent; they want to use influence to reign back the practice of building MVPs in a poor UX sort-of-way, and felt a new acronym was the best way to get an audience and tell the story.
- kthejoker2 7y ago
  Excluding your rant (which is totally on point, BTW) Every feature you drop is time saved. You can choose to invest that time into improving your remaining features; or you can simply save it for later and ship your release sooner. Product release management is a balancing game. Your goal as a product owner is to determine the ideal balance between: 1) Shipping as soon as possible i.e. the "velocity" of the feedback loops. 2) Shipping something different enough than what you shipped before that there is valuable feedback to be gained from shipping ie. the "size" of the loop. In one extreme, you wait until the product is "1.0" and ship one time and you have one huuuuuuuuuge feedback loop with a ton to process. In another extreme, you ship every single (nano!) second of the day and you have a billion tiny feedback loops, most of which have no delta at all. What most people have compromised on is some kind of fixed duration loop (aka "the sprint") that the resulting loop is, Goldilocks style, not too big or not too small, but juuust right to address within the fixed duration. By fixing the duration, we now have a clear focus from a product development side: generate enough delta between what was shipped last time and shipped this time to ensure the size of the feedback loop is what we need to gain enough information on what's needed for the next shipping cycle. And the hypothesis is that if we could compare the product built using the 3 choices - extreme size, extreme velocity, Goldilocks - over some long enough period of time, that the Goldilocks product would be the most valuable. MVPs themselves are tricky because they are the "first release" so they don't have a delta nor feedback. They can technically be shipped any time! But it's still important to choose a fixed duration for your MVP release, for three reasons: 1) It falls in line with the general principles of "fail fast", "ready, fire, aim", "you are not the customer", "avoid analysis paralysis", "perfect is the enemy of good", etc. You will always struggle to get a "polish"/feature-based MVP out the door - there's one more thing to do, you're more critical than your customers ... One is way more "negotiable" (in a negative sense) than the other. 2) By choosing a specific date you're going to ship on no matter what features are there, you've already guaranteed an M and a P. All that's left to negotiate is the V. So now your point about the tradeoff between number of features vs. the polish of those features is valid, which leads to .. 3) There is no right answer to #2. If I saw a lot of polish on someone's MVP I might ask what features they're missing entirely. If I saw a lot of half-baked features I might ask why they didn't drop features X and Y to add polish to "core" feature Z. Amazingly, the answers to those questions only matter if you're a user of the product! So ship fast and get answers.
- em-bee 7y ago
  i am confused (by the article), i thought this when you build an MVP, you should bias towards cutting features rather than cutting polish or introducing bugs. If your MVP is filled with bugs, it isn't actually viable. is what an MVP was about, the minimum effort that gets people interested. You should also focus on making an MVP that people actually want. If it isn't solving a real problem ("loveable"), it's not actually a product. finding out if people want something is usually the goal. if don't want it you change the product until they do.
troelsSteegin 7y ago
What is the difference between "viable" and "complete"? Complete, as in "Simple, Lovable, Complete", is about your customer's ability to derive net utility from using your product for their job to be done. Viable, in the MVP context, I interpret as signalling a credible offering in a market. The audience for viable is investors in your business, or customers willing to invest in a relationship with your business, in the expectation that your product will get to a point later of being distinctively useful. Viable is promising, complete is useful today. The question is which approach will best fund your company to the point of operational self sufficiency. As an engineeer, I would far rather make SLC products. However, if I am racing for mindshare in a market or with investors, I have to think MVP. SLC is harder to acheive. As Pascal sort of said, "If I had more time, I would have written an SLC".
- 9wzYQbTYsAIc 7y ago
  > What is the difference between "viable" and "complete"? That’s where a lot of people get tripped up: development may have one idea about what is viable whereas the business team has a completely different idea.
  - loopz 7y ago
    ...and customers have a third valid opinion on the same.
    - 9wzYQbTYsAIc 7y ago
      Which should get subsumed into that business team as an accurate VOC.
oblib 7y ago
I have to agree with the author. The MVP concept was new to me when I attended Startup School a couple years ago and while I understood what it gets at (not spending too much time or money on a concept that no one may want) it feels too much like selling a "promise" of what something will be, and it assumes that promise can be fulfilled. To me, an MVP felt like showing someone a battery powered skateboard while telling them what you're really working on is an electric car. You may get investors, and that's great, but you may also spend years finding out you can't scale the tech to build the car.
- stronglikedan 7y ago
  It's more like the MVP is a basic electric car. You can sit in it, start it, and drive it. However, it doesn't have a radio or sunroof, and maybe not even a trunk or passenger seat. I'm not sure the author understands what an MVP is. I parse the title as I hate MVPs, because I hate what I don't understand.
mabbo 7y ago
Interpretation of language is the problem here. What is "viable"? What is "minimal"? The author's complaints are that customers are upset with the MVP. Well, that's because it was so minimal that the customers don't see it as viable. There's not enough viability to make up for the minimalism. Using the product is not a good deal for the customer. So what's the answer the author provides? Use different language that can be misinterpreted. Here's what will happen with SLCs: "Oh, that doesn't have <feature X that 1% of users want, but VP likes>, so it's not COMPLETE yet, so it's not an SLC". "We don't need to add <X> because that's not SIMPLE, so it's not an SLC, just ship without <critical feature that 90% of users need>". "You know, it's good, but I just don't love it yet. Can you just give it some more work so that it's an SLC?" I've seen it happen. "Minimum LOVABLE product" made it's rounds at my company once. Yes, they called them "MLPs" having no idea about My Little Pony or the various communities who care deeply about such things. It did not bring us joy. The true answer lies not in changing the words but in deeply defining what you mean and getting everyone to agree on them. It means working closely with your customer and asking them if you're ready to launch with this minimal set of features (for now). It means earning trust and quickly iterating based on feedback. Buzzwords gonna buzz. Ignore them. Just sit down with your customer and solve their problems.
glofish 7y ago
I don't agree with the content. The whole premise is to mischaracterize what an MVP is supposed to be. The figure they have there where they compare a half car with no wheels (MVP) to the scooter (SLC) is quite telling. That half car would never be considered a Minimally Viable Product, a half car with no wheels does not work at all - how is that viable? The scooter would be an MVP.
- danShumway 7y ago
  The Spotify team is explicitly saying in that chart, "example 1 is not an MVP, example 2 is." And then WP Engine is turning around and saying, "see, example 1 shows why MVPs don't work. Instead you should build example 2 which is a totally different concept we invented." I don't know why, but that really rubs me the wrong way. How does someone look at a two-diagram infographic and take away the exact opposite lesson that it's trying to teach?
- IshKebab 7y ago
  I think they're right, but they've just phrased it in a way that means lots of pedants will say "well that isn't an MVP then is it?". It's more or less the No True Scotsman fallacy. "No true MVP has too few features - otherwise it wouldn't be viable!" In any case I think it would be much clearer to say "Most 'MVPs' have few too features be actually be viable, so they aren't actually MVPs." I think that is true.
commandlinefan 7y ago
So... "Don't try to be realistic about what can reasonably be accomplished, instead do everything completely right the first time". Well, ok, thanks for the advice, I guess.
- vikramkr 7y ago
  I love that they complain that MVP is not a good approach and that SLC is better and clearer, but "simple" and "complete" can be antagonistic forces and create the same amount of ambiguity as the interaction between "minimum" and "viable." I imagine you are looking at complete and read it as saying everything must be done right the first time, while the author likely would respond with "no you are missing the point it should also be simple." But I might agree with your interpretation, as would a lot of other people, meaning its ambiguous and potentially less meaningful. At least the ambiguity in MVP is less, it's the minimal product that is viable, which presumably does have an empirical, if perhaps unknowable, answer. It's a clear target. What is simple and complete though? I dont think theres a clear target there.
dasil003 7y ago
All of this could be said without trying to coin a new acronym. MVP already covers these angles, and it feels like a bit of a strawman to claim it doesn't. The hard part and simultaneously whole point of building an MVP is to figure out the proper scope. This will vary a lot from product to product and in different markets, and there's no magic formula. I don't see how adding new abstract principles helps. Should it be simple, lovable and complete? Well duh.
- kasey_junk 7y ago
  The emphasis on complete is a new take. The entire idea of an MVP encapsulates the idea that it will change into something in the future. Just changing the mental goal to something that can live on its own with no further development is an important difference. Does it need a new acronym? I don’t know but I never liked MVP anyway.
  - mikeg8 7y ago
    The reason shooting for completeness is not ideal is because it’s usually a waste of time. Very rarely can founders guess the compete solution to their customers problem out of the gate. It’s the mismatch between what the company imagines the complete solution should look like versus integrating customer feedback to make “complete” solution more people will pay for.
santoshalper 7y ago
The author spends an entire article demonstrating that he or she does not understand what an MVP is, then proceeding to tell us about a new invention that is, in fact, an MVP. Newsflash - an MVP is not a piece of shit. It's the simplest version of the product that solves the problem.
- richardjennings 7y ago
  It seems "Simple, Lovable and Complete" is the authors context specific meaning of the Viable in MVP
  - pdubs1 7y ago
    It also seems really dumb, to me, for incorporating "Love" into a business/engineering product/project stage-of-development naming convention. Any good business person or engineer understands that objective, unbiased, un-emotionally attached decisions and validations are antithetical to subjective, biased emotions such as "love".
jameslk 7y ago
The premise of this article is based solely on this statement: > The problem is that customers hate MVPs. But I don't see much in the article to support this claim.
fenwick67 7y ago
I don't want to move to Utah, thanks.
goatherders 7y ago
I worked at WPE years ago when the core product was still being improved upon and enhanced and new ideas were still being shipped. I assure anyone reading that the company shipped plenty of MVPs that turned out to not be Minimum, not be viable and failed as products. That's not to be a criticism - I love that the company tried new things and the product team wasnt afraid to put new tech in the hands of customers. But there was no new paradigm or standard then as this article from 2017 (which is right around when I left) suggests. The author is one of the smarter people I've been around, in the tech world or any other. And I've enjoyed his writing over the years. But I tend to agree that this piece doesnt really make a lot of sense aside from ascribing a new acronym to an established idea.
Adrig 7y ago
I'm not going to rewrite comments that have been presented in this thread (I usually use the name Main Delightful Product), but I'll make an argument for ugly MVPs : All products and features don't have to bring joy to users. Sometimes they just are sick of their problem. The fulfillment of their pain don't translate into appreciation of the product. Examples could be safety features (security alarm, protective gear,..) or reliability enhancer (monitoring software,...) Doing an ugly MVP will give you plenty of proofs of concept, and will provide the majority of what users want : the solution to their pain point. Taking the extra time to make it lovable will only impact marginally the perception of value from your users
Ididntdothis 7y ago
It seems when things like MVP, Agile or OOP are invented they are useful observations. But as soon as they become popular they get distorted to the point they don’t make sense anymore or are even damaging. At this point whenever I read something about MVP it seems it’s mainly discussing semantics and ideology. Time for a new buzzword cycle.
torpfactory 7y ago
The big problem with MVP is that it is now simply one more corporate buzzword. Many using the term may have heard the 30-second description from a colleague and now repeat it freely. Like a game of telephone, what was said and what was heard about MVP keep changing. As such, it has lost most of its meaning and has no firm definition. It's an easy target for a piece like this, given the circumstances. At least in my organization it had no useful definition. Usually the term MVP would be thrown around by management as reasoning for any number of decisions. Taking too long to understand a core technology limitation - my lucky MVP ball says just get it sort-of working and ship it. Regressing on performance to meet an arbitrary timeline - just make it MVP (in our organization this meant ship on time, no matter the content). Reducing cost by shipping completely untested designs - that's what MVP is. Not that any of these examples couldn't or shouldn't be viewed with the MVP rubric, but it didn't seem to mean anything in particular.
waylandsmithers 7y ago
In my consulting experience MVP doesn't have much to do with whether the least amount of work to make the thing possible is being done, but has mostly been used as a negotiating tactic when fighting for scope-- "We'll save that feature for V1, but we're going to focus on these features for MVP"
dkersten 7y ago
If your customers hate MVP’s then you got the V wrong. The whole point is it’s the minimal things that’s Viable and how much that is depends on the product and market. For some products, the minimal thing that’s viable really is minimal, for others it’s rather complete. IMHO the point of MVP’s is to do the least work necessary to make the customer happy with the product (ie not was to big time on unnecessary or nice to have things that can come later), not to build a minimal thing.
mywittyname 7y ago
Remember how Telsa started by building skateboards before moving to scooters, bikes, then cars? No? Oh that's right, they started with cars, but outsourced the design and production of components that were not their core competency, then slowly replaced those outsourced designs until they had something entirely their own. What product is complete when launched? I can't recall anything. Most of the products I know and love got to that point through a series of small, incremental, improvements over time. And this is exactly the foundation the MVP paradigm seeks to lay out: get something out the door that's useful, and get feedback from customers to make those incremental improvements.
- gofreddygo 7y ago
  > they [...] outsourced the design and production of components that were not their core competency, then slowly replaced those outsourced designs until they had something entirely their own. This is interesting. Any references to read more on this ?
  - mywittyname 7y ago
    I'm referring to the original Roadster being built on a heavily modified Lotus chassis while the Model S was ground up design. The fact that older Roasters can get upgrades from the Model S suggests a good deal of component sharing for the drive trains. I'm not sure if anyone has written anything extensive on it.
pdubs1 7y ago
This article smells of a naive, inexperienced author. "I hate the accepted industry abbreviation. Use my abbreviation! It's better! Woo I'm so smart and and my opinion is so important." How about... I hate SLC. Use MVP instead. (Or POC - Proof Of Concept) "simple loveable complete" Please. Just... please. This author sounds like another non-technical person trying to insert themselves into an area (technology) where they lack experience. Simple Entryism. First they enter a domain, then they want to start making changes, whether they are merited or not, and whether the person is knowledgeable/experienced or not. So sick of it. 1. Stop trying to tell people what to do, sweetheart. 2. Stop telling me what my customers want-- You don't know me, nor do you know my customers. 3. Stop acting as if you represent anything other than your own inexperienced opinion. "Love" does not belong in an engineer or business person's vocabulary, when it comes to validating value. "Love" is subjective and BIASED. Good decisions are objective, data-oriented, lack bias, and lack emotional attachment. Please, keep gullible lovey-dovey hippies & "entryists" out of technology.
- arunaugustine 7y ago
  The author is Jason who is the founder and CTO of WP-Engine which started in 2010. He sold two companies before that. From the Author bio: https://blog.asmartbear.com/jason-cohen https://blog.asmartbear.com/jason-cohen
Traster 7y ago
I hate these corporate brand management exercises masquerading as real technical insight. We get it, it's important to your company to be viewed as a thought leader in order to attract talent and customers. The way you do that is by doing things, not half-arsing a blog post. If you have nothing meaningful to say, don't say it.

77 points by notoriousarun 7y ago

Minus the buzzwords, here's what this article is saying: when you build an MVP, you should bias towards cutting features rather than cutting polish or introducing bugs. If your MVP is filled with bugs, it isn't actually viable. You should also focus on making an MVP that people actually want. If it isn't solving a real problem ("loveable"), it's not actually a product. In other words, increase the polish of your initial releases by making them smaller and including fewer features. That's valuable advice. But if I can rant for just a minute: Do you need a completely brand new concept or paradigm or acronym to say that? No, you don't. This is mostly just playing semantic games and allowing WP Engine to subtly imply that they're better at building polished products than other companies. How do you make something simple? You make it do less stuff. That's what "minimal" means. What does "loveable" mean? It means you're solving an actual problem -- you have a real Product. How do you build an SLC? You radically cut down on the number of features you plan to ship in an initial product, to the point where you have time to polish them in your initial release. That sounds a lot like an MVP to me. If WP Engine just put up an article saying, "our software is always very polished and very usable, even in the first release", nobody would care. The way to make people care is to pretend that you've found a completely new paradigm for building software, when all you really mean is, "we're quite good at building MVPs that people like." The article isn't talking about new concepts, it's just debating what other people intend when they say individual words, and I couldn't care less. It's like saying, "we don't focus on making our product 'fun', we focus on making it 'delightful'." Okay, but what does that mean beyond the fact that a business manager somewhere thought it tracked better with potential buyers?

oblib 7y ago
What I got from Startup School was that an MVP didn't have to do anything at all. It just had to demonstrate what it "will" do. It's basically a "mockup".
- danShumway 7y ago
  Huh, that's really interesting. I don't have anything against mockups, but that's almost the opposite of what I and engineers I know think of when we say MVP. The point of an MVP as we use it is to not plan in excessive detail about what your final feature-set will be, because you don't know what customers will and won't find valuable until you have a product in their hands. Get the smallest, most specific version of a useful product released, and then after that you can figure out what future iterations should do. How are you going to release an MVP to customers that doesn't actually do anything? Why would anyone download or use it?
  - DoubleFree 7y ago
    I think the point here is that your MVP should behave like the actual product in the eyes of the customer, but you do not have to actually build the functionality. By providing a lot of the service manually, you can get your initial customers quickly. Having customers means getting feedback from the product's target audience. Getting this feedback before actually heavily investing in automating the product means when you do automate, you have a much better idea of what the final product should look like and which features you should prioritize, wasting less time and money on building the wrong things.
    - danShumway 7y ago
      Just to make sure I understand what you're saying, let me try to think of an example. A number of AI companies start out by outsourcing the "AI" to something like Amazon Turk or remote contractors. From the customer perspective, the system is working as intended. The system transcribes their videos, or schedules their appointment, or whatever. In the backend, the system doesn't exist. It's just a bunch of people manually transcribing videos and manually creating Calendar links. And those companies are validating that customers will want to use the fake version before they spend the time building an AI-driven real version. Do I understand correctly, or is that different from what you were trying to say? But in that case, you're still building a product that does a thing. It's just that the product doesn't currently scale, and the business isn't being up-front telling any of its customers what they're actually buying. I wouldn't say you built a mockup in that situation, I would say you built a call-center, and you're thinking about whether or not to automate it based on demand.
maroonblazer 7y ago
This is a common phenomenon I see in a lot writing, both online and in print. People will take an idea, strawman it, then pretend to invent a new idea. The last step is optional. Sometimes they'll simply attack a popular idea in a - seeming - attempt to get attention. I.e. "Look at me! I'm claiming the Emperor has no clothes!". There was an HN post here in the last 48 hours critiquing mental models that followed this same recipe. https://news.ycombinator.com/item?id=22948723 https://news.ycombinator.com/item?id=22948723
- ianai 7y ago
  I’ve worked with people who do precisely this. They’re a drag on progress at best and catalyst for breaking teams apart at worst. But they think they’re getting somewhere by doing it.
timerol 7y ago
They give away the whole renaming game when they talk about the image of transportation mechanisms: skateboard, bike, car, etc. They talk about it as if it's a SLC image, but the image title is "How to build a Minimum Viable Product"
JoeAltmaier 7y ago
Folks are getting owly in lockdown... Many startup concepts are simple, and have catchphrases. Pivot. Lean. Standup. And on and on.
pdubs1 7y ago
Same here. This article just lost me respect for WP-Engine. What a pedantic, naive, intelligence-insulting article. It insults my intelligence to tell me what my "customers" want, given that they've never met my customers.
brayhite 7y ago
I don't plan to die on this hill, but I think this practice is somewhat forgivable when assuming good intent. The author may have realized that "MVP" has lost its originally _good_ meaning and became something else. They wanted to publish a post bringing focus back to what MVP originally was supposed to be, but felt that it's meaning has become so tied to its new, less good one, that they needed a new acronym to wrap their message in. It's all reactionary, and in your own words, you acknowledge nobody would care if they just presented it as "our MVPs are what they _should_ be". I try to assume good intent; they want to use influence to reign back the practice of building MVPs in a poor UX sort-of-way, and felt a new acronym was the best way to get an audience and tell the story.
kthejoker2 7y ago
Excluding your rant (which is totally on point, BTW) Every feature you drop is time saved. You can choose to invest that time into improving your remaining features; or you can simply save it for later and ship your release sooner. Product release management is a balancing game. Your goal as a product owner is to determine the ideal balance between: 1) Shipping as soon as possible i.e. the "velocity" of the feedback loops. 2) Shipping something different enough than what you shipped before that there is valuable feedback to be gained from shipping ie. the "size" of the loop. In one extreme, you wait until the product is "1.0" and ship one time and you have one huuuuuuuuuge feedback loop with a ton to process. In another extreme, you ship every single (nano!) second of the day and you have a billion tiny feedback loops, most of which have no delta at all. What most people have compromised on is some kind of fixed duration loop (aka "the sprint") that the resulting loop is, Goldilocks style, not too big or not too small, but juuust right to address within the fixed duration. By fixing the duration, we now have a clear focus from a product development side: generate enough delta between what was shipped last time and shipped this time to ensure the size of the feedback loop is what we need to gain enough information on what's needed for the next shipping cycle. And the hypothesis is that if we could compare the product built using the 3 choices - extreme size, extreme velocity, Goldilocks - over some long enough period of time, that the Goldilocks product would be the most valuable. MVPs themselves are tricky because they are the "first release" so they don't have a delta nor feedback. They can technically be shipped any time! But it's still important to choose a fixed duration for your MVP release, for three reasons: 1) It falls in line with the general principles of "fail fast", "ready, fire, aim", "you are not the customer", "avoid analysis paralysis", "perfect is the enemy of good", etc. You will always struggle to get a "polish"/feature-based MVP out the door - there's one more thing to do, you're more critical than your customers ... One is way more "negotiable" (in a negative sense) than the other. 2) By choosing a specific date you're going to ship on no matter what features are there, you've already guaranteed an M and a P. All that's left to negotiate is the V. So now your point about the tradeoff between number of features vs. the polish of those features is valid, which leads to .. 3) There is no right answer to #2. If I saw a lot of polish on someone's MVP I might ask what features they're missing entirely. If I saw a lot of half-baked features I might ask why they didn't drop features X and Y to add polish to "core" feature Z. Amazingly, the answers to those questions only matter if you're a user of the product! So ship fast and get answers.
em-bee 7y ago
i am confused (by the article), i thought this when you build an MVP, you should bias towards cutting features rather than cutting polish or introducing bugs. If your MVP is filled with bugs, it isn't actually viable. is what an MVP was about, the minimum effort that gets people interested. You should also focus on making an MVP that people actually want. If it isn't solving a real problem ("loveable"), it's not actually a product. finding out if people want something is usually the goal. if don't want it you change the product until they do.

troelsSteegin 7y ago

What is the difference between "viable" and "complete"? Complete, as in "Simple, Lovable, Complete", is about your customer's ability to derive net utility from using your product for their job to be done. Viable, in the MVP context, I interpret as signalling a credible offering in a market. The audience for viable is investors in your business, or customers willing to invest in a relationship with your business, in the expectation that your product will get to a point later of being distinctively useful. Viable is promising, complete is useful today. The question is which approach will best fund your company to the point of operational self sufficiency. As an engineeer, I would far rather make SLC products. However, if I am racing for mindshare in a market or with investors, I have to think MVP. SLC is harder to acheive. As Pascal sort of said, "If I had more time, I would have written an SLC".

9wzYQbTYsAIc 7y ago
> What is the difference between "viable" and "complete"? That’s where a lot of people get tripped up: development may have one idea about what is viable whereas the business team has a completely different idea.
- loopz 7y ago
  ...and customers have a third valid opinion on the same.
  - 9wzYQbTYsAIc 7y ago
    Which should get subsumed into that business team as an accurate VOC.

oblib 7y ago

I have to agree with the author. The MVP concept was new to me when I attended Startup School a couple years ago and while I understood what it gets at (not spending too much time or money on a concept that no one may want) it feels too much like selling a "promise" of what something will be, and it assumes that promise can be fulfilled. To me, an MVP felt like showing someone a battery powered skateboard while telling them what you're really working on is an electric car. You may get investors, and that's great, but you may also spend years finding out you can't scale the tech to build the car.

stronglikedan 7y ago
It's more like the MVP is a basic electric car. You can sit in it, start it, and drive it. However, it doesn't have a radio or sunroof, and maybe not even a trunk or passenger seat. I'm not sure the author understands what an MVP is. I parse the title as I hate MVPs, because I hate what I don't understand.

mabbo 7y ago

Interpretation of language is the problem here. What is "viable"? What is "minimal"? The author's complaints are that customers are upset with the MVP. Well, that's because it was so minimal that the customers don't see it as viable. There's not enough viability to make up for the minimalism. Using the product is not a good deal for the customer. So what's the answer the author provides? Use different language that can be misinterpreted. Here's what will happen with SLCs: "Oh, that doesn't have <feature X that 1% of users want, but VP likes>, so it's not COMPLETE yet, so it's not an SLC". "We don't need to add <X> because that's not SIMPLE, so it's not an SLC, just ship without <critical feature that 90% of users need>". "You know, it's good, but I just don't love it yet. Can you just give it some more work so that it's an SLC?" I've seen it happen. "Minimum LOVABLE product" made it's rounds at my company once. Yes, they called them "MLPs" having no idea about My Little Pony or the various communities who care deeply about such things. It did not bring us joy. The true answer lies not in changing the words but in deeply defining what you mean and getting everyone to agree on them. It means working closely with your customer and asking them if you're ready to launch with this minimal set of features (for now). It means earning trust and quickly iterating based on feedback. Buzzwords gonna buzz. Ignore them. Just sit down with your customer and solve their problems.

glofish 7y ago

I don't agree with the content. The whole premise is to mischaracterize what an MVP is supposed to be. The figure they have there where they compare a half car with no wheels (MVP) to the scooter (SLC) is quite telling. That half car would never be considered a Minimally Viable Product, a half car with no wheels does not work at all - how is that viable? The scooter would be an MVP.

danShumway 7y ago
The Spotify team is explicitly saying in that chart, "example 1 is not an MVP, example 2 is." And then WP Engine is turning around and saying, "see, example 1 shows why MVPs don't work. Instead you should build example 2 which is a totally different concept we invented." I don't know why, but that really rubs me the wrong way. How does someone look at a two-diagram infographic and take away the exact opposite lesson that it's trying to teach?
IshKebab 7y ago
I think they're right, but they've just phrased it in a way that means lots of pedants will say "well that isn't an MVP then is it?". It's more or less the No True Scotsman fallacy. "No true MVP has too few features - otherwise it wouldn't be viable!" In any case I think it would be much clearer to say "Most 'MVPs' have few too features be actually be viable, so they aren't actually MVPs." I think that is true.

commandlinefan 7y ago

So... "Don't try to be realistic about what can reasonably be accomplished, instead do everything completely right the first time". Well, ok, thanks for the advice, I guess.

vikramkr 7y ago
I love that they complain that MVP is not a good approach and that SLC is better and clearer, but "simple" and "complete" can be antagonistic forces and create the same amount of ambiguity as the interaction between "minimum" and "viable." I imagine you are looking at complete and read it as saying everything must be done right the first time, while the author likely would respond with "no you are missing the point it should also be simple." But I might agree with your interpretation, as would a lot of other people, meaning its ambiguous and potentially less meaningful. At least the ambiguity in MVP is less, it's the minimal product that is viable, which presumably does have an empirical, if perhaps unknowable, answer. It's a clear target. What is simple and complete though? I dont think theres a clear target there.

dasil003 7y ago

All of this could be said without trying to coin a new acronym. MVP already covers these angles, and it feels like a bit of a strawman to claim it doesn't. The hard part and simultaneously whole point of building an MVP is to figure out the proper scope. This will vary a lot from product to product and in different markets, and there's no magic formula. I don't see how adding new abstract principles helps. Should it be simple, lovable and complete? Well duh.

kasey_junk 7y ago
The emphasis on complete is a new take. The entire idea of an MVP encapsulates the idea that it will change into something in the future. Just changing the mental goal to something that can live on its own with no further development is an important difference. Does it need a new acronym? I don’t know but I never liked MVP anyway.
- mikeg8 7y ago
  The reason shooting for completeness is not ideal is because it’s usually a waste of time. Very rarely can founders guess the compete solution to their customers problem out of the gate. It’s the mismatch between what the company imagines the complete solution should look like versus integrating customer feedback to make “complete” solution more people will pay for.

santoshalper 7y ago

The author spends an entire article demonstrating that he or she does not understand what an MVP is, then proceeding to tell us about a new invention that is, in fact, an MVP. Newsflash - an MVP is not a piece of shit. It's the simplest version of the product that solves the problem.

richardjennings 7y ago
It seems "Simple, Lovable and Complete" is the authors context specific meaning of the Viable in MVP
- pdubs1 7y ago
  It also seems really dumb, to me, for incorporating "Love" into a business/engineering product/project stage-of-development naming convention. Any good business person or engineer understands that objective, unbiased, un-emotionally attached decisions and validations are antithetical to subjective, biased emotions such as "love".

jameslk 7y ago

The premise of this article is based solely on this statement: > The problem is that customers hate MVPs. But I don't see much in the article to support this claim.

fenwick67 7y ago

I don't want to move to Utah, thanks.

goatherders 7y ago

I worked at WPE years ago when the core product was still being improved upon and enhanced and new ideas were still being shipped. I assure anyone reading that the company shipped plenty of MVPs that turned out to not be Minimum, not be viable and failed as products. That's not to be a criticism - I love that the company tried new things and the product team wasnt afraid to put new tech in the hands of customers. But there was no new paradigm or standard then as this article from 2017 (which is right around when I left) suggests. The author is one of the smarter people I've been around, in the tech world or any other. And I've enjoyed his writing over the years. But I tend to agree that this piece doesnt really make a lot of sense aside from ascribing a new acronym to an established idea.

Adrig 7y ago

I'm not going to rewrite comments that have been presented in this thread (I usually use the name Main Delightful Product), but I'll make an argument for ugly MVPs : All products and features don't have to bring joy to users. Sometimes they just are sick of their problem. The fulfillment of their pain don't translate into appreciation of the product. Examples could be safety features (security alarm, protective gear,..) or reliability enhancer (monitoring software,...) Doing an ugly MVP will give you plenty of proofs of concept, and will provide the majority of what users want : the solution to their pain point. Taking the extra time to make it lovable will only impact marginally the perception of value from your users

Ididntdothis 7y ago

It seems when things like MVP, Agile or OOP are invented they are useful observations. But as soon as they become popular they get distorted to the point they don’t make sense anymore or are even damaging. At this point whenever I read something about MVP it seems it’s mainly discussing semantics and ideology. Time for a new buzzword cycle.

torpfactory 7y ago

The big problem with MVP is that it is now simply one more corporate buzzword. Many using the term may have heard the 30-second description from a colleague and now repeat it freely. Like a game of telephone, what was said and what was heard about MVP keep changing. As such, it has lost most of its meaning and has no firm definition. It's an easy target for a piece like this, given the circumstances. At least in my organization it had no useful definition. Usually the term MVP would be thrown around by management as reasoning for any number of decisions. Taking too long to understand a core technology limitation - my lucky MVP ball says just get it sort-of working and ship it. Regressing on performance to meet an arbitrary timeline - just make it MVP (in our organization this meant ship on time, no matter the content). Reducing cost by shipping completely untested designs - that's what MVP is. Not that any of these examples couldn't or shouldn't be viewed with the MVP rubric, but it didn't seem to mean anything in particular.

waylandsmithers 7y ago

In my consulting experience MVP doesn't have much to do with whether the least amount of work to make the thing possible is being done, but has mostly been used as a negotiating tactic when fighting for scope-- "We'll save that feature for V1, but we're going to focus on these features for MVP"

dkersten 7y ago

If your customers hate MVP’s then you got the V wrong. The whole point is it’s the minimal things that’s Viable and how much that is depends on the product and market. For some products, the minimal thing that’s viable really is minimal, for others it’s rather complete. IMHO the point of MVP’s is to do the least work necessary to make the customer happy with the product (ie not was to big time on unnecessary or nice to have things that can come later), not to build a minimal thing.

mywittyname 7y ago

Remember how Telsa started by building skateboards before moving to scooters, bikes, then cars? No? Oh that's right, they started with cars, but outsourced the design and production of components that were not their core competency, then slowly replaced those outsourced designs until they had something entirely their own. What product is complete when launched? I can't recall anything. Most of the products I know and love got to that point through a series of small, incremental, improvements over time. And this is exactly the foundation the MVP paradigm seeks to lay out: get something out the door that's useful, and get feedback from customers to make those incremental improvements.

gofreddygo 7y ago
> they [...] outsourced the design and production of components that were not their core competency, then slowly replaced those outsourced designs until they had something entirely their own. This is interesting. Any references to read more on this ?
- mywittyname 7y ago
  I'm referring to the original Roadster being built on a heavily modified Lotus chassis while the Model S was ground up design. The fact that older Roasters can get upgrades from the Model S suggests a good deal of component sharing for the drive trains. I'm not sure if anyone has written anything extensive on it.

pdubs1 7y ago

This article smells of a naive, inexperienced author. "I hate the accepted industry abbreviation. Use my abbreviation! It's better! Woo I'm so smart and and my opinion is so important." How about... I hate SLC. Use MVP instead. (Or POC - Proof Of Concept) "simple loveable complete" Please. Just... please. This author sounds like another non-technical person trying to insert themselves into an area (technology) where they lack experience. Simple Entryism. First they enter a domain, then they want to start making changes, whether they are merited or not, and whether the person is knowledgeable/experienced or not. So sick of it. 1. Stop trying to tell people what to do, sweetheart. 2. Stop telling me what my customers want-- You don't know me, nor do you know my customers. 3. Stop acting as if you represent anything other than your own inexperienced opinion. "Love" does not belong in an engineer or business person's vocabulary, when it comes to validating value. "Love" is subjective and BIASED. Good decisions are objective, data-oriented, lack bias, and lack emotional attachment. Please, keep gullible lovey-dovey hippies & "entryists" out of technology.

arunaugustine 7y ago
The author is Jason who is the founder and CTO of WP-Engine which started in 2010. He sold two companies before that. From the Author bio: https://blog.asmartbear.com/jason-cohen https://blog.asmartbear.com/jason-cohen

Traster 7y ago

I hate these corporate brand management exercises masquerading as real technical insight. We get it, it's important to your company to be viewed as a thought leader in order to attract talent and customers. The way you do that is by doing things, not half-arsing a blog post. If you have nothing meaningful to say, don't say it.