Media Query Source: Part 31
The responses I provided to a media outlet on December 16, 2020:
Media: We are looking for the top reasons for why your MVP may fail or succeed.
Gfesser: The top reason for MVP (minimum viable product) success or failure revolves around its very definition. Has consensus been reached amongst stakeholders? Does this consensus include approaching what is to be built like a product? Is the product to be built both viable and minimal? If the answers to these three questions can accurately be communicated as "yes" for a given MVP, it is likely headed in the right direction. If not, the question needs to be raised as to why stakeholders are referring to what is to be built as an "MVP".
An itemized product backlog first needs to be built. A product backlog essentially defines the product, as it is a list of what is needed to improve the product over time. Products have lifespans, and a product backlog lists the priority order in which each improvement is to be built. When an MVP is defined, it is defined with a subset of these improvements, focusing on what will be minimally needed to get it in front of end customers to start eliciting feedback.
However, stakeholders need to understand that while getting feedback is a goal en route to building, deploying, and releasing an MVP, end customers typically do not have visibility to the supporting infrastructure and software beyond the user interface. As such, stakeholders need to understand considerations for longer term viability, making tradeoffs with the builders along the way.
Yes, what is built for an MVP can technically be replaced following release, but doing so needs to be carefully considered, especially in cases where the supporting infrastructure, software, and data behind the user interface can be seen as the primary product, as the initial user interface only implements a small number of use cases and the flexibility of the platform is paramount. Certainly, such is the case when application or data platforms are built, as these are intended to subsequently support additional use cases.
Lastly, it is beneficial for the team building an MVP to be dedicated to the product and free of dependencies on other groups or individuals, to be cross-functional, and to work in an agile manner. Teams exhibiting these qualities will be self-sufficient and flexible as the buildout takes place. In addition to stakeholder lack of consensus and not approaching the MVP as a product, these are among the common reasons I have seen either failure or extreme challenge.
See all of my responses to media queries here.