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.
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.