I thoroughly disagree with misusing terms like this. Experimentation and the like are important, but that doesn't mean you get to throw away the term "minimum viable product".
This article is more about "how to find out what an MVP might be".
> An MVP is not just a product with half of the features chopped out
Right, it's supposed to be the absolute core of what is necessary. This requires actually knowing what your customers want. It's perfectly OK to say "I don't know what our MVP should be" and then go and try and find out what it should be. But until you have something that is actually viable as a product then you don't have a MVP.
> You spend months figuring out how to launch custom mobile apps for your clients, only to find out that what a restaurant owner really wants is a mobile-optimized website that’s easy to find on Google.
So you added an extra feature that's unwanted and failed to add a required feature. This is neither minimum, nor viable.
> Or, after using all the latest technologies to build real-time chat, you find out that restaurant owners can barely deal with email and don’t want to sit at a computer all day.
Adding an extra feature nobody needs means you've not built a minimum product.
> Or, worst of all, you might find out that restaurant owners don’t want the hassle of dealing with technology and maintaining mobile apps and have no interest in using your product in the first place.
Then you haven't built a viable product.
> Therefore, the very first MVP could be a mockup of such a mobile app
Not really, since this isn't a viable product.
edit - I think this is a common issue, people taking terms and then bringing in what they "really mean". A "minimum viable product" is a very simple description. If what you have isn't a viable product, then I really do not understand the point of saying you've built a minimum viable product.
Is that at all useful when trying to decide what to do next?
Okay, so an MVP is a product with the absolute minimal set of features necessary. How do you find that core of features? How do you determine which feature you will add (or test) next? How should you build it? Who should you put it in front of?
The advantage of this article is that it provides some answers for those questions. You should build the riskiest feature next. You should build it in the absolute fastest way that will let you have reasonable confidence in the result of your experiment. You should expect to throw out many versions before you find one that works.
It still leaves many questions unanswered - how do you decide what is the riskiest feature? Is there an easier way to test what you'd like to test? But at least it gets you closer to having an actionable plan to reliably figure out market needs.
It's great to have a concrete definition of what an MVP means, but if the result of that definition is that the process of building a startup is "Do you have an MVP?" "Nope." "Do you have an MVP?" "Nope." "Do you have an MVP?" etc, then so what?
I think the usefulness of insisting on reserving the term "MVP" for a successful experiment is that it could help prevent someone from spending months in development, telling themselves "we're building our MVP, we're building our MVP", and thus thinking, when they've built something but not yet shown it to anyone, that it is an MVP. No; you hope it is, but it may not be (and in fact, the odds are against you if you haven't discussed it with potential customers).
So this is not just a semantic quibble, but actually supports the thrust of the article. While you're doing market research experiments, you should call them that. When you actually strike gold, then you have an MVP.
The problem is, you're wrong, historically, on what MVP means. The person who coined the phrase intended it to mean something else, and it's meant something else for a few years for anyone who was in the community (who are also the only people who knew the phrase).
Now that it's become well-known, people are totally misunderstanding what it stands for and why it was coined in the first place. So sure, you can argue all you want about the term being misnamed, but that doesn't help you or anyone else actually understand what it's about or why it's useful. It's not about building a product - it's about turning the idea of "product" on its head, and realizing that the only "product" you need to "build" is the minimum possible thing that will get you feedback on whether you're on the right path.
> This article is more about "how to find out what an MVP might be".
I think that's it in a nutshell. I agree with you that the article is sloppy with the term "MVP", and should instead be calling these steps in the process "experiments". On the one hand, their point about multiple experiments being required is an important one. On the other, it really should be the case that when someone claims to have built an MVP, that they have a product and have solid evidence that it's viable. (I suppose one can never know for sure that it was absolutely minimal.)
So an experiment is not an MVP, but experiments are what one does having set out to build an MVP.
As with any term that becomes a "buzzword" (e.g., DevOps, Lean, Agile), the definition of MVP definitely gets muddled and everyone has their own take on it. I could replace the term with "how to build products by repeatedly identifying your riskiest assumptions and building the smallest possible experiment to test them", but I think "MVP" is a bit easier to read.
> This article is more about "how to find out what an MVP might be".
This sounds a bit tautological. An MVP is the smallest possible experiment to test your assumptions. To find out what that experiment should be, you have to do an experiment to test assumptions...
Also, one of the key ideas in the article is this is not something you do once to build a single MVP. It's a process you use over and over again to develop every aspect of your business, including the product, marketing strategy, software architecture, etc. For example, to build a large software system, you don't write 100,000 lines of code, then hit compile, and hope it works. Instead, you do it incrementally. Write a few lines of code, test them, make sure they work; write a few more lines of code, test them, make sure they work, and so on. Or to quote John Gall, "A complex system that works is invariably found to have evolved from a simple system that worked."
> Adding an extra feature nobody needs means you've not built a minimum product.
This reminds me of the No true Scotsman fallacy [1].
"No MVP should have unnecessary features."
"But that successful company's MVP had all sorts of unnecessary features."
"Yes, but no true MVP should have unnecessary features."
This sort of critique isn't wrong, but it's not useful. How do you figure out which features are necessary and which ones aren't? The best way I've found to do that is to pick your riskiest assumption and to test it. And to do that over and over again, incrementally building up your product as you go. If you don't like the term MVP for that, I suppose that's fair, but then please suggest a better term to replace it.
> the definition of MVP definitely gets muddled and everyone has their own take on it.
I'm quite surprised by this, since to me there's little to disagree about. A "minimum viable product" seems like a very simple description to me.
> An MVP is the smallest possible experiment to test your assumptions.
I'm not sure where this is coming from, unless what you get out of it is a viable product, how is it an MVP?
I'm not saying you shouldn't experiment, or that you shouldn't build small things and try them out, but I see no reason to keep referring to something as a minimum viable product when it meets none of the three words.
> This reminds me of the No true Scotsman fallacy [1].
Again, I'm not really sure why what I've said seems so odd. If it's not the smallest viable product then how is it a minimum viable product? If it's not a viable product, again, it's not an MVP.
This is more like reading an article that says "A Scotsman doesn't need to be Scottish or even a person".
> This sort of critique isn't wrong, but it's not useful.
I feel it is, since I think the concept of an MVP is pretty important because at the end of it you have a viable product. If people are going to use the term MVP to describe proofs of concepts and mockups and a general process, then what term do you suggest should replace it for actually describing minimum viable products?
This reminds me of the discussion on the definition of "Object Oriented". It's a term of art that means a specific thing in the context of programming. [1]
"Minimum Viable Product" is also a term of art to describe a specific concept and can't really be broken down word by word. If you look at Eric Ries, Steve Blank, and Frank Robinson they have a specific meaning for MVP that matches The Macro article.
See for example [2] where Reis says "It is not necessarily the smallest product imaginable, though; it is simply the fastest way to start learning how to build a sustainable business with the minimum amount of effort."
Okay, I'm reading the TechCrunch article you linked to, and I come across this:
In this case, the video was the minimum viable product. The MVP validated Drew’s leap-of-faith assumption that customers wanted the product he was developing not because they said so in a focus group or because of a hopeful analogy to another business, but because they actually signed up.
I think this is a very interesting quote. For one thing, it urges us to expand our notion of what a product is. It isn't necessarily an actual working piece of software; it can be a mock-up or faked demo -- but in any case it's still something that can be shown to potential customers.
But the question that some of us are raising is, when could the video be called an MVP? The answer we would suggest is, it becomes an MVP only after it receives an enthusiastic response from the market. Note that the Ries quote is completely consistent with this interpretation: by the time Ries wrote it, the video had received such a response. Our argument is that while Drew Houston was making the video, it wasn't an MVP yet: it was only an experiment, an attempt at making an MVP, but not yet a validated MVP.
So I disagree that "MVP" is "a term of art and can't really be broken down word by word". Rather, I think that people haven't understood exactly what Ries and Blank mean by it.
Very few people in the Lean Startup world (for example any Lean Startup event or conference) who use the methodology in their own business or coach others see MVP as a Product. Everyone agrees MVP = Experiment.
That's the problem with coining a phrase that gets popular. It starts out as one thing that is not necessarily 100% correct. Then it's too late to change it once you understand it better and understand how to implement it.
Well, that's one way to look at it. Another is to say that it was perfectly clear what it meant when it was coined - redefining the idea of "product" to mean "something that gives you feedback on your plan", rather than "something people can use". It was the idea that you don't need anything more at this stage, not a "real" product.
Sure, without the history people won't understand it, but then that's true of most terms in most fields, and I'm really not sure if there is a way to prevent it.
Note how many of the articles above try to redefine the phrase to reduce confusion, such as "Minimum Delightful Product" or "Minimum Marketable Product." There is confusion about every part of MVP: what "minimum" means, what "viable" means, and what "product" means.
> If it's not the smallest viable product then how is it a minimum viable product? If it's not a viable product, again, it's not an MVP.
How do you do know if it's "smallest" or "viable"? Walk me through your process.
> If people are going to use the term MVP to describe proofs of concepts and mockups and a general process, then what term do you suggest should replace it for actually describing minimum viable products?
Based on the massive confusion around the term MVP, as you can see in the articles I linked above, I think it's fair to say that you need more than an acronym to understand what to do. That's why I tried to define it as a process. Will that fix all the confusion in the world? Of course not. But I hope that focusing on a mindset instead of a product will help at least a little bit.
"How do you do know if it's "smallest" or "viable"?"
There will be done uncertainty, as all possibilities cannot be tested. But just because something is hard or even impossible to identify, it does not mean the concept is not valid.
My question was for IanCal, but since you chose to answer it, I'm happy to ask you the same thing: when you go to build an MVP, how do you decide if what you're doing is the "smallest" or if it will be "viable"? Walk me through your actual process.
Hmm, perhaps you're right on the confusion, though the quote
> So, the minimum viable product is that product which has just those features (and no more) that allows you to ship a product that resonates with early adopters; some of whom will pay you money or give you feedback.
Seems pretty clear to me, perhaps the trickiness comes around whether or not absolutely anything that gets feedback is an MVP? I don't get how you'd say with a straight face that you shipped a product when what you actually did was go around with a questionnaire.
> How do you do know if it's "smallest" or "viable"?
You explicitly chose situations where there were extra, unused features and where the product as a whole was completely useless. If you have a product with more features than you needed, you can't really say you succeeded in making the minimum viable product, and if you have a product nobody wants is it really sensible to refer to it as a viable product?
Is the startup world at such a point that nobody knows what might constitute a viable product? Sure, there's some blurred points around not-yet-profitable-but-growing things, but if your target audience finds your thing absolutely useless is it really that unclear?
> Walk me through your process.
Again, I have no problem with the process and it's a shame this has picked up so much attention instead of actual discussion around that. I just don't want to have to deal with the following conversations:
"We've built an MVP"
"Great! How did the launch go?"
"Launch? Oh my no, we've just finished a focus group session. The next MVP is at 4pm if you want to sit in."
> I think it's fair to say that you need more than an acronym to understand what to do.
Yes, this is true, which is surely why we already have terms like market research. I just don't understand what benefit calling market research "building an MVP" has.
My initial criticism was that you'd redefined what I thought was a well understood term. If I'm wrong about that (which I seem to be) then I'd change my criticism to "If something is poorly understood, please don't redefine it to mean something different again". When I see a title like "X isn't X, it's Y" my immediate thought is that someone is trying to give an old idea a new name to make it more current and sexy, that may not be fair but it's my first reaction to this kind of thing.
Perhaps I just need to step back from all this for a while. Perhaps in this world you really can refer to a marketing video as a viable product, and I'm a crazed outsider. I'd hoped to be clear about simple definitions of words yet caused/opened up even more confusion and disagreement, so I guess I've failed at my minimal useful comment.
> An MVP is the smallest possible experiment to test your assumptions.
This is the point that IanCal and I are disagreeing with. An experiment should be called an experiment. What you get after you've done enough experiments to validate your assumptions is an MVP.
Maybe we need the abbreviation "MVPA" for "MVP Attempt".
A more fitting title for the article could be, "Building your MVP the right way."
The whole point of an MVP is to avoid spending time and other resources building stuff no one wants or the wrong solution to problems.
Therefore the article is a cheat sheet to lean thinking.
1. Draw a mockup, Table of content, vision statement
2. Talk to the target customer as often as possible to clarify every aspect of what you're building
3. If you want to sell your product, nothing says you're on the right path better than paying customers
4. You shouldn't stop validating decisions after you've hit some success eg. Facebook and Google conduct hundreds of thousands of micro experiments on live users to determine button placements, colour choice, increase sign up rate...
So in summary, don't drop the MVP mindset when you hit some level of success. Fail fast, and more importantly, fail often. Be a scientist.
This article is totally on-point. MVPs are the minimal viable test for confirming your hypotheses.
While running a startup consultancy, the idea that MVP is a thing you make once before going on to make the 'real' product, was one of the two biggest misconceptions I saw. The other one was "lean means cheap".
I ended up realising that most startup resources explain these crucial things with misleading terms and a confusing way. Really, the whole process should mirror the scientific method - I started teaching my clients based on that, telling them to forget what they'd already heard. I'm writing a book at the moment about this (working title: The Rational Startup) but that's a subject for another HN submission :)
I'm learning this with my website (http://muxme.com), which is only a month old. I've pivoted about a hundred times, which makes me question what truth is, because literally every bit of copy, UX flow, and strategy has changed. Yesterday the site was personal, friendly, and quirky. Today the site attempts to create the illusion that we're multiple people operating a business. The one truth that is true and universal is that people can enter and win with no purchase necessary, which is what the website revolves around.
Buying a lottery ticket and tweeting demands at Paul Graham are almost certainly feasible methods for obtaining several million dollars by the end of next week. However, neither method is viable because that's not the way things work: to a first approximation, lottery tickets lose and the evidence is that Paul Graham doesn't give millions of dollars to people he doesn't know when they tweet at him.
Unfortunately, it's easy to conflate feasibility with viability because anything that is infeasible is also nonviable: e.g. buying a ticket for last weeks lottery or tweeting demands at Charles de Gaulle. Fortunately, the Brikman's article does not fall into this confusion.
It's easier to determine what is feasible -- two app developers can build a restaurant app and put it in the app store -- than what is viable: build a restaurant app that people use. To be feasible, it only has to be technically possible for the developers to build an app. To be viable, it has to be useful enough that people use it.
One might say that viability is checking feasibility against non-technical goals. If the reason for building the app is to make money, feasibility is based on projected prices, costs, and sales. Viability about assessing those projections.
Brikman's position appears to be that a product is whatever can be put put in front of customers or potential customers. It's reasonably consistent with a world in which many things people tend to consider products are free or fundware. It's plausible.
But I can see why someone might choke on that, so YMMV.
That article, and Eric Ries' book, define an MVP as a "version of a new product which allows a team to collect the maximum amount of validated learning about customers with the least effort." A "version of a new product" doesn't have to be a product.
The classic example of an MVP that Eric Ries uses is the explainer video Drew Houston created for DropBox before building the actual product [1]. The video worked as an MVP by helping Houston test his assumptions, but I don't think you could say the video itself was a "product."
There's a lot of disagreement in this thread about the definition of MVP, and I think it stems from the interpretation of the "Viable" part.
Based on the definitions by writers who helped popularise the term, like Steve Blank and Eric Ries, I think this word should be clarified as "viable for the purpose of the entrepreneur". Then the definitions of MVP as a process or marketing experiment make more sense. A MVP does not need to be viable for the customer (e.g. a complete, but minimal product) , just as an experiment.
Yeah I saw this on Reddit too. I'm not sure what the point of the article is. It references Ries in passing as if it's only vaguely relevant, and proceeds to say precisely what Ries said 10 years ago in the first few pages of probably the most prolific book in the startup community. It then tries to make the article more relevant by conflating Lean with Agile and suggesting that they're both only vaguely relevant, when the entire article is specifically talking about Lean concepts. (And I say all this as someone who hated The Lean Startup).
If something is called a "product", then its in search for users. If its called "process", then its the way to do something. The author exchanges the terms – but mixing both will get you nowhere while both are neccessary to succeed: You don't go from zero to MVP but have to develop a process to create a working MVP.
I have to agree with the other commenters, the logic is super muddled here. Building an MVP is a process, and determining when you have an MVP and can now launch is a process. But an MVP itself is emphatically a product.
I agree with the sentiment wholeheartedly. MVP has been bastardized in most shops I have been in. What's actually built is a "minimally compliant product." We need a better name for the idea that we are searching for something valuable for customers to buy. How about Market Viable Product which is the anticipated end result of the process of searching for product/market fit?
There is a big problem with the term MVP. It does not work uniformly in all markets, especially in mature markets when you are trying to substitute either your own product or competing with a very mature product of your competitor.
I give author credit how to break down MVP process easy enough to execute fast. Folks startup isn't academia. Please do not discuss purity of this article against lean.
This was insightful. Google Car - classic example. Once you can prove you can do something, doesn't mean what you've done is something you can market and make a profit, etc. Regardless of the outcome (including failure) your MVP is where your process took you and it ended (with every stakeholder happy or everyone agreeing to stop).
This article is more about "how to find out what an MVP might be".
> An MVP is not just a product with half of the features chopped out
Right, it's supposed to be the absolute core of what is necessary. This requires actually knowing what your customers want. It's perfectly OK to say "I don't know what our MVP should be" and then go and try and find out what it should be. But until you have something that is actually viable as a product then you don't have a MVP.
> You spend months figuring out how to launch custom mobile apps for your clients, only to find out that what a restaurant owner really wants is a mobile-optimized website that’s easy to find on Google.
So you added an extra feature that's unwanted and failed to add a required feature. This is neither minimum, nor viable.
> Or, after using all the latest technologies to build real-time chat, you find out that restaurant owners can barely deal with email and don’t want to sit at a computer all day.
Adding an extra feature nobody needs means you've not built a minimum product.
> Or, worst of all, you might find out that restaurant owners don’t want the hassle of dealing with technology and maintaining mobile apps and have no interest in using your product in the first place.
Then you haven't built a viable product.
> Therefore, the very first MVP could be a mockup of such a mobile app
Not really, since this isn't a viable product.
edit - I think this is a common issue, people taking terms and then bringing in what they "really mean". A "minimum viable product" is a very simple description. If what you have isn't a viable product, then I really do not understand the point of saying you've built a minimum viable product.