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.
Nobody releasing a product into the wild is going to be 100% happy with every aspect of it - it is then labeled as a MVP.
On the flipside, throwing ideas against the wall to see what sticks may be far too "minimum" in a saturated market.
The viability is what drives the whole concept.
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.
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.
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?
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.
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 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.
"Minimum" is the least amount of resource it will take you to show off that characteristic.
(I'm agreeing with you, btw. :-) )
Most Valuable Player Most Verbose Parrot Most Vindictive Pariha Moose Vamoosed Perennially (ok now I'm stretching)
"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.
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.
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."
