Let’s start off with what a Minimally Viable Product (MVP) is not – it’s not the least amount of stuff that can be done in a sprint. What it is intended to be is a learning tool, you’re supposed to be validating your hypothesis (or hypotheses) with an MVP. If you’re not validating something then you’re not really building an MVP.
When I talk to Scrum Masters, development teams, other Product Owners, they seem to be confusing the intent of Build-Measure-Learn with The-Least-Amount-We-Can-Do-And-Still-Be-Considered-Successful, or TLAWCDASBCS. The TLAWCDASBCS is a function of team availability, capital, time, and volition. It’s the minimal amount of stuff you can do to get people off your back and appear to be making progress.
If you’ve reached product-market fit and you need to refine features further, you can then drop one level down conceptually to a Minimally Viable Feature (MVF) to learn more from customers about what the features truly need to do for them.
