If he hasn't already, the author should really read The Lean Startup before criticizing the term that it popularized. In the context of the Lean Startup, the V in MVP doesn't refer to financial viability.
"To apply the scientific method to a startup, we need to identify which hypotheses to test. I call the riskiest elements of a startup's plan, the parts on which everything depends, leap-of-faith assumptions."
"Once clear on these leap-of-faith assumptions, the first step is to enter the Build phase as quickly as possible with a minimum viable product (MVP). The MVP is that version of the product that enables a full turn of the Build-Measure-Learn loop with a minimum amount of effort and the least amount of development time." - Eric Ries, The Lean Startup
An MVP is simply the smallest possible product that is capable of testing your assumptions about the value you think you can provide to customers. An MVP doesn't have to represent a viable business model, it only has to provide a viable means of testing your assumptions.
It forces people to really struggle with their domain. What is viable? For whom? How do you pick that group? What's the minimum? Can you go lower than that? How about lower still? If you go too low, will you be getting data that tells you what the thing left out is? It's tricky.
Is that hard? Great. It should be. It took Lewis and Clark 18 months to do a trip I did in a few days. That my trip was fast and easy wasn't a sign they were doing it wrong. Exploration is necessarily hard and confusing. If it weren't, it wouldn't be exploration.
The problem is that "viable" confuses what the purpose of the launch is. The purpose of the initial launch is to experiment and test a market and idea, not necessarily to release something that is "viable" (in what sense?). If it's a test, let's call it a test. No need for it to have a confusing label like viable.
To me "minimum viable product" means a product that achieves a goal with the minimum amount of features. It doesn't necessarily have to test anything, but usually does. Maybe its not 'viable' in a market --> if you were using it to test its success in a market your test failed, but the minimum viable product still did something, and was thus viable.
I see no problem with minimum viable product. That's exactly what Segment.io had, a minimum viable product. The minimum amount needed to test if your product could be viable and is worth testing out and building out further. Seems like we're just arguing semantics here, and the definition of MVP will change based on your goal (e.g. social network viability could be engagement or user growth and a SaaS product could be whether someone pulls out their credit card to pay for something).
Other comments are arguing its a difference of semantics. I disagree, I think it's a difference of perspective. The idea of MVP is your idea of the minimum set of functionality that represents a product that you want to test out to determine if you have something that's worth something to someone else.
He's coming at it from the perspective of the user's use of your idea and I think that's not what most people think of when thinking about MVP. Certainly I never did. If you come at it from that way, you never know you have something until after it's been proven viable ... how is that even useful?
"The idea of MVP is your idea of the minimum set of functionality that represents a [complete] product that you want to test out to determine if you have something that's worth something to someone else ... [in a completed state]."
An MVP, an unfinished product, simply gives you a level of confidence that the effort to complete it will reward you with resonance with your target market.
This is a difference of semantics. A significant amount of people understand that an MVP is the bare minimum to meet the specs of your project idea without investing significant time in maturing aspects of it that are not core to the functionality of the project.
An MVP is a tool to test whether your idea has steam. The key idea about MVP is to NOT spend too much time/money before validating your product's reception with your target market.
If the tool/product you're making only takes two weeks in a near-complete offering then MVP really doesn't apply to your lucky situation. For those making stuff that will take months to build, the MVP (sketches, drawings, fake buttons, etc) is a great idea.
An MVP is a starting point. Generally an MVP is not market-viable; it's somewhere between a tech demo and a beta product. But it's complete enough to start having talks with potential customers / investors about where the product should go from there. When you're just talking about a theoretical product that doesn't exist yet, it can be hard to have a constructive conversation with people.
No two people will probably agree what an MVP is for a specific product at first; but it doesn't matter. I think too many companies focus on an MVP as a stage-gate versus just planning feature priority (and revisiting as necessary). The whole idea behind an MVP is that you don't really understand the market, so you build a barebones product to go start to learn what you're doing from a market positioning standpoint. Then you go develop features to reinforce your position.
I have come to see an MVP as hopefully viable for a very narrow slice of the market.
In Crossing the Chasm, the author talks about readiness to adopt as a bell curve. At the very eager end of that curve are people who will put quite a lot of work in. For a product I'm researching now, I'm trying to find the smallest thing I can give to a very eager customer and have it produce value for them. Hopefully enough value that they will say, "Ooh, let me get my checkbook."
That it will take a ton more work to be viable for mainstream customers is fine by me. If it were appealing to more than 5 or 10% of my target market, that would tell me I could have been more minimal.
Yeah; it shouldn't be appealing to the wider market: you don't even know what that market is at the point you're building your MVP. The MVP is as much a tool to help you learn about the market as it is an actual product.
This kind of criticism happens to any popular term. And usually terms become popular because they work. Thinking "minimum viable product" worked -- it turned on the light bulb for many people (like myself) who polish instead of test, or seek perfection instead of iteration.
I feel like Reinhardt is complaining about the term "minimum VIABLE product" when most people emphasize it "MINIMUM viable product".
In that emphasis, the two mean almost the same thing. However, I see another difference:
- "viable" makes you think about what users want. Sure, you can get carried away, but that's why "minimum is there to reign you in.
- "testable" could mean anything -- you can test anything, in any direction -- it doesn't make you think about what users want.
This is problematic.
Viable is a good word. It points you in the right direction. "Testable" helps to limit you, but "Minimum" is already there to do it.
I say stick with MVP, but if you, or team, start getting carried away, just remember - Minimum, minimum, minimum!
For me, the viable part has always referred to required aspects of the product.
For example, a forgot password feature might require two components, the webpage where users indicate that they've forgotten their password and the backend that sends them an email with a reset link. Without the V in MVP, you could implement just the webpage side of it and push it out to start learning about user behavior. But without the backend, users will be frustrated and the feature won't work.
However sometimes a feature that has multiple components can be rolled out sequentially to increase the time that your users are using the feature and you're learning how to improve it. An example might be Amazon's product reviews. An MVP mindset could allow you to have a phase 1 that is simply collecting reviews without displaying them anywhere. The feature may be more compelling when all aspects implemented, but it's at least somewhat functional in a partially implemented state.
And that's where the judgment comes in...when developing a product, you have to distill the eventual vision of what you want to build into the minimum thing that doesn't have holes that either make it unusable or compromise your ability to learn from the way that user's interact with your product.
This is the dumbest thing I've read in a long time. He's defending MVP, but prefers the word testable to viable. Even though, viability is a primary criteria prior to testing. If your idea is not capable of success, then there isn't much point testing it. Lets say I have a plan for a helmet that lets you talk to god. Is it viable, no. Is it testable, yes. Testability is useless if you don't have viability.
MVP definitely means something. It means "my opinion of what we must build to ship something."
In other words, its a meaningful definition that is absolutely meaningless. It is a fancy term introduced to allow circular arguments when pushing for your own pet feature: "this feature is needed for the MVP, because it's a feature that must be there for the product to work and be tested."
"Viable" is a characteristic of your product such that it looks and "feels" close to the real deal (but isn't!) in the hands of the customer. (Think viable as "fakable")
"Minimum" is the least amount of resource it will take you to show off that characteristic.
"To apply the scientific method to a startup, we need to identify which hypotheses to test. I call the riskiest elements of a startup's plan, the parts on which everything depends, leap-of-faith assumptions."
"Once clear on these leap-of-faith assumptions, the first step is to enter the Build phase as quickly as possible with a minimum viable product (MVP). The MVP is that version of the product that enables a full turn of the Build-Measure-Learn loop with a minimum amount of effort and the least amount of development time." - Eric Ries, The Lean Startup
An MVP is simply the smallest possible product that is capable of testing your assumptions about the value you think you can provide to customers. An MVP doesn't have to represent a viable business model, it only has to provide a viable means of testing your assumptions.