6 ms·

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 introduci

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.
      - DoubleFree 7y ago
        First things first, I think companies should be up-front with their customers. That means not marketing non-AI solutions as AI. However, lots of companies do not sell AI, they sell a service. And as long as that service is good, it should not matter to the customers if part of that process is manual, as long as you do not lie about it. I am not saying this is the best way to handle things; it's just the way I interpreted the "MVP as mock up" idea.
- rjtavares 7y ago
  How is a mockup a viable product?
  - troughway 7y ago
    The hypothetical idea behind these "new" MVPs is that you should do the least work possible to start getting clients. If that means it's a phone call, then that's an MVP. Very bizarre twist of words, but that's what it is.
    - MaxBarraclough 7y ago
      But that isn't what the term means. If your product isn't yet viable, you don't have an MVP. Being able to silver-tongue your way to clients doesn't change that.
      - loopz 7y ago
        That's business. Of course it can be done in an underhanded way, but with transparency, respect and for the right reasons, it can be valuable input what to build initially. Wether you call it "MVP" or not is purely semantic. thus irrelevant to the context.
        MaxBarraclough 7y ago
        > can be valuable input what to build initially Sure. Just don't pretend it's something that it isn't. > Wether you call it "MVP" or not is purely semantic Well, no. It's not the correct use of the term. Let's be dramatic and look at the worst case: deliberately misusing a term-of-art like 'MVP' may be tantamount to misleading investors and clients.
    - colinjoy 7y ago
      I like to think of these as P=Proposition ... useful to evaluate if it makes sense to pursue the idea as a P=Product.
  - docandrew 7y ago
- stronglikedan 7y ago
  Sorry to say, but I think you should ask for a refund, as the word "viable" in MVP implies exactly the opposite.
- rgblambda 7y ago
  What I was told in my graduate job induction that what you are describing is a prototype and an MVP is developed after the successful demo of the prototype. The MVP is the "official" product that is used by customers.
- quantified 7y ago
  That’s why this article has some value. I interpret what you’re describing as the usual M-without-V flavor of MVP. Customers (including me) hate the mockups, we want something real even if limited.
- kcorbitt 7y ago
  Hey, I'm one of the folks at YC working on Startup School. I wouldn't characterize our advice this way. It's important that an MVP actually solves a problem that a user has, although it's fine for it to require some manual intervention at first that you plan to automate away in the long term. That said, you should definitely be talking to potential users long before your MVP is ready, and one way to find potential users is by building an initial landing page and trying to get signups. Obviously, you should be upfront about the fact that the product doesn't exist yet if you choose to get user feedback in this way. You can see more in Michael's lecture on the topic: https://www.startupschool.org/videos/65 https://www.startupschool.org/videos/65
  - oblib 7y ago
    Well, when I hear that I think of Theranos. I'm not an investor, but that approach feels a bit like putting the cart before the horse to me. For example, if I went to horse riders and asked them if they'd buy a saddle for $2000 that attached itself to a horse and could steer the horse based on GPS tech and follow built-in directions to anywhere they wanted to ride, and keep it from bucking or running off, they'd probably all say "heck yeah!" So, now that I've demonstrated market fit from that point I need to make a working prototype and if I haven't a clue but do have a good pitch to investors that convinces them I can do it I'm still not accomplishing anything (except maybe a short free ride). I'm sure investors are aware of this but Theranos proved they can be had and I think that approach is why and how they can be. But that's not really my side of the story. I want to make something first and then see if people will buy it. From that point of view the "V" in MVP seems most important and the minimal part is easy to described and easy to measure real progress on. So I do agree the initial goals for a product should be minimal, for example, maybe just a saddle that attaches itself to a horse to begin with. But even if we get a prototype done we still don't know if we have salable product, so really, this is where market fit comes face to face with a product and we truly start finding out what an MVP is. Finding that needs testing with a real product, but at least we've not blown a lot of cash on actual product viability and almost none on marketing.
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.

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.
    - DoubleFree 7y ago
      First things first, I think companies should be up-front with their customers. That means not marketing non-AI solutions as AI. However, lots of companies do not sell AI, they sell a service. And as long as that service is good, it should not matter to the customers if part of that process is manual, as long as you do not lie about it. I am not saying this is the best way to handle things; it's just the way I interpreted the "MVP as mock up" idea.
rjtavares 7y ago
How is a mockup a viable product?
- troughway 7y ago
  The hypothetical idea behind these "new" MVPs is that you should do the least work possible to start getting clients. If that means it's a phone call, then that's an MVP. Very bizarre twist of words, but that's what it is.
  - MaxBarraclough 7y ago
    But that isn't what the term means. If your product isn't yet viable, you don't have an MVP. Being able to silver-tongue your way to clients doesn't change that.
    - loopz 7y ago
      That's business. Of course it can be done in an underhanded way, but with transparency, respect and for the right reasons, it can be valuable input what to build initially. Wether you call it "MVP" or not is purely semantic. thus irrelevant to the context.
      - MaxBarraclough 7y ago
        > can be valuable input what to build initially Sure. Just don't pretend it's something that it isn't. > Wether you call it "MVP" or not is purely semantic Well, no. It's not the correct use of the term. Let's be dramatic and look at the worst case: deliberately misusing a term-of-art like 'MVP' may be tantamount to misleading investors and clients.
  - colinjoy 7y ago
    I like to think of these as P=Proposition ... useful to evaluate if it makes sense to pursue the idea as a P=Product.
- docandrew 7y ago
stronglikedan 7y ago
Sorry to say, but I think you should ask for a refund, as the word "viable" in MVP implies exactly the opposite.
rgblambda 7y ago
What I was told in my graduate job induction that what you are describing is a prototype and an MVP is developed after the successful demo of the prototype. The MVP is the "official" product that is used by customers.
quantified 7y ago
That’s why this article has some value. I interpret what you’re describing as the usual M-without-V flavor of MVP. Customers (including me) hate the mockups, we want something real even if limited.
kcorbitt 7y ago
Hey, I'm one of the folks at YC working on Startup School. I wouldn't characterize our advice this way. It's important that an MVP actually solves a problem that a user has, although it's fine for it to require some manual intervention at first that you plan to automate away in the long term. That said, you should definitely be talking to potential users long before your MVP is ready, and one way to find potential users is by building an initial landing page and trying to get signups. Obviously, you should be upfront about the fact that the product doesn't exist yet if you choose to get user feedback in this way. You can see more in Michael's lecture on the topic: https://www.startupschool.org/videos/65 https://www.startupschool.org/videos/65
- oblib 7y ago
  Well, when I hear that I think of Theranos. I'm not an investor, but that approach feels a bit like putting the cart before the horse to me. For example, if I went to horse riders and asked them if they'd buy a saddle for $2000 that attached itself to a horse and could steer the horse based on GPS tech and follow built-in directions to anywhere they wanted to ride, and keep it from bucking or running off, they'd probably all say "heck yeah!" So, now that I've demonstrated market fit from that point I need to make a working prototype and if I haven't a clue but do have a good pitch to investors that convinces them I can do it I'm still not accomplishing anything (except maybe a short free ride). I'm sure investors are aware of this but Theranos proved they can be had and I think that approach is why and how they can be. But that's not really my side of the story. I want to make something first and then see if people will buy it. From that point of view the "V" in MVP seems most important and the minimal part is easy to described and easy to measure real progress on. So I do agree the initial goals for a product should be minimal, for example, maybe just a saddle that attaches itself to a horse to begin with. But even if we get a prototype done we still don't know if we have salable product, so really, this is where market fit comes face to face with a product and we truly start finding out what an MVP is. Finding that needs testing with a real product, but at least we've not blown a lot of cash on actual product viability and almost none on marketing.

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.