One of the most important life lessons I've learnt is to not conflate the model for the reality it tries to capture but also not waste a good model because it doesn't perfectly capture the underlying reality. In this case, poor understanding of both the model and the underlying reality means that people will dismiss both the lean startup methodology and MVP as a technique when both are incredibly powerful tools aimed at exploring if and how a product might be successful.
Absolutely. It's become almost trite at this point to note that "all models are wrong; some models are useful," but it's true and the MVP is one of the better ones. The difficulty is the same one Agile has - the model has become more useful as an excuse to avoid rigor than as a way to get better outcomes or understand the world.
If you say you're "doing agile," you don't have to put the effort into writing rigorous requirements. If you say you're "doing an MVP," you don't have to put in the effort into building a rigorously-engineered product. Neither model is supposed to be about being lazy. They're supposed to be about making trade-offs between different kinds of rigor.
Agile is supposed to unlock the ability to truly re-plan after each sprint and make very different decisions about your product direction. It's only a positive tradeoff if you are being rigorous about looking at your results, generating alternative paths, and assessing them. Otherwise you just end up with no documentation and a shitty architecture.
MVPs are supposed to be prototypes that reveal the answer about a specific hypothesis that is critical to your strategy. It's only a positive tradeoff if you are rigorous about what knowledge you don't have about your customers and technology, and build exactly the thing that will answer the question. Otherwise you just end up with a half-baked and buggy product.
Together, they give you the information you need to head in the best direction and the means to do so. But only if you're taking all that time you were originally spending on system design, rigorous documentation, and product quality and putting it towards stuff that tech teams aren't usually as comfortable doing.
> MVPs are supposed to be prototypes that reveal the answer about a specific hypothesis that is critical to your strategy. It's only a positive tradeoff if you are rigorous about what knowledge you don't have about your customers and technology, and build exactly the thing that will answer the question.
Put differently (to put the misunderstanding to rest): MVPs aren't alpha- or beta-versions of software; don't treat them as such.
> The point is not that all maps are useless; rather, the point is simply to maintain critical thinking about the discrepancies: whether or not they are either negligible or significant in each context, how to reduce them
