Is the term MVP vastly overused / misunderstood?
Disclaimer: I know the Minimum Viable Product is closer to Lean than Scrum itself, but I think it still fits into general 'agile world' and fits the forum.
Don't you think that the term Minimum Viable Product is greatly overused nowadays?
Seems like we tend to label every new product as an MVP. I see people with a 2-year development plan without any intention to pivot/validate hypothesis, and they still label their first production release as an "MVP".
What's your opinion? Do you think MVP term is vague enough and it's fine to use it as a substitute for "brand new and barely complete", or should it be reserved for products that specifically aim for hypothesis validation and initial market feedback? Can the very first release of the product be named MVP, even though the product owner doesn't intend to pivot based on the market reception?
What's your stand on MVP definition? I feel like 80% of the time the term MVP is misused just because something is "new".
I agree with you that the term MVP is misused, and it is a fine topic for this forum. Here is a definition I like, and forget where I heard it (probably from Eric Ries of Lean Startup):
MVP: The smallest thing you can build to gain validated learning.
I think it fits in well for validating hypothesis and for getting customer feedback.
I see people with a 2-year development plan without any intention to pivot/validate hypothesis, and they still label their first production release as an "MVP".
An MVP might enable validated learning, or its purpose might be to demonstrate viability to stakeholders so as to trigger further funding. One consumes the availabe runway on which to pivot, the other builds it.
Anyone can have a 2-year "development plan". Having enough runway on which to pivot and learn is something else entirely.
I've most commonly seen an MVP as not the bare minimum to learn from, sadly, but the bare minimum to 'prove' the team is working hard. Essentially a milestone to demonstrate progress along a traditional project path.
Like it or not, this term means different things to different people.
If your teams and stakeholders are using this, it's probably a good idea to at least make sure they can agree on what it means to them. If they don't agree, it can actually expose some long term misunderstandings.
If a customer gives me a broad set of expectations and I cannot convert that into something I can demo for them in a few weeks, maybe two months tops, I don't have an MVP.