3 ms·

This kind of criticism happens to any popular term. And usually terms become popular because they work. Thinking "minimum viable product" worked -- it turned

by chavesn 13y ago

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!

curun1r 13y ago
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.

by chavesn 13y ago

curun1r 13y ago

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.