5 ms·

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".

by oblib 6y ago

danShumway 6y 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 6y 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 6y 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 6y 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.
- loopz 6y ago
  Too much software mindset. You can build a no-code solution, see how potential users interact with it, and learn from that. You can gage interest just by presenting something to a focus group in a somewhat interactive way. MVP could even just be a poll. No need for a "product" or even a demo. If you can build a prototype fast and deliver fast, that could be valuable, but is often waay before evaluating what to build in the first place. There are success stories building something and iterating on that. If you yourself is multi-talented, have the time, clout and love your software, there might be some odds others might like/need it too. The latter is associated with most failures though. So be a business, not a software delivery function.
  - danShumway 6y ago
    Sure, you don't need to code anything. You can build a no-code solution, see how potential users interact with it, and learn from that. But your no-code solution still needs to be a minimal feature set that people can actually use. If I'm building an MVP for a restaurant, maybe there's no code at all in that system. Maybe I'm manually taking everyone's orders and serving at most one or two dishes on a street corner. But I'm not just showing people pictures of food. Your no-code solution still needs to be a solution, it can't just be a promise that there will be a solution at some point in the future. An MVP doesn't mean code, it means: Build the smallest possible product (whether that involves code or not) that actually solves someone's problems in the real world, and then put that product in their hands so you can see what they do with it. A poll is not a product. No customer is going to pay you so that they can take a poll.
    - loopz 6y ago
      You may not generate much income with initial MVP, or whatever you want to call it. The point is to learn while minimizing costs, risks and time to market. To expect greatness without work, is folly.. Your example with the restaurant is a perfect example: Have someone execute the MVP manually. Map routines that works great, optimize and document outcomes. This becomes spec for initial automations. The alternative could be someone in a corner office applying systems thinking and predicting everything required in the system. This tend to overcomplicate system designs and make them less amenable to adapt over time.
rjtavares 6y ago
How is a mockup a viable product?
- troughway 6y 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 6y 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 6y 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 6y 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 6y 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 6y ago
stronglikedan 6y ago
Sorry to say, but I think you should ask for a refund, as the word "viable" in MVP implies exactly the opposite.
rgblambda 6y 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 6y 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 6y 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 6y 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.

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".

by oblib 6y 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 6y 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 6y 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 6y 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 6y 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.
loopz 6y ago
Too much software mindset. You can build a no-code solution, see how potential users interact with it, and learn from that. You can gage interest just by presenting something to a focus group in a somewhat interactive way. MVP could even just be a poll. No need for a "product" or even a demo. If you can build a prototype fast and deliver fast, that could be valuable, but is often waay before evaluating what to build in the first place. There are success stories building something and iterating on that. If you yourself is multi-talented, have the time, clout and love your software, there might be some odds others might like/need it too. The latter is associated with most failures though. So be a business, not a software delivery function.
- danShumway 6y ago
  Sure, you don't need to code anything. You can build a no-code solution, see how potential users interact with it, and learn from that. But your no-code solution still needs to be a minimal feature set that people can actually use. If I'm building an MVP for a restaurant, maybe there's no code at all in that system. Maybe I'm manually taking everyone's orders and serving at most one or two dishes on a street corner. But I'm not just showing people pictures of food. Your no-code solution still needs to be a solution, it can't just be a promise that there will be a solution at some point in the future. An MVP doesn't mean code, it means: Build the smallest possible product (whether that involves code or not) that actually solves someone's problems in the real world, and then put that product in their hands so you can see what they do with it. A poll is not a product. No customer is going to pay you so that they can take a poll.
  - loopz 6y ago
    You may not generate much income with initial MVP, or whatever you want to call it. The point is to learn while minimizing costs, risks and time to market. To expect greatness without work, is folly.. Your example with the restaurant is a perfect example: Have someone execute the MVP manually. Map routines that works great, optimize and document outcomes. This becomes spec for initial automations. The alternative could be someone in a corner office applying systems thinking and predicting everything required in the system. This tend to overcomplicate system designs and make them less amenable to adapt over time.

rjtavares 6y ago

How is a mockup a viable product?

troughway 6y 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 6y 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 6y 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 6y 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 6y 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 6y ago

stronglikedan 6y ago

Sorry to say, but I think you should ask for a refund, as the word "viable" in MVP implies exactly the opposite.

rgblambda 6y 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 6y 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 6y 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 6y 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.