Admit it: When you read “MVP” in the title of this article, you thought “most valuable player." Huh? Sorry to disappoint, but in this context, MVP has nothing to do with sports and everything to do with the success of a software development project. In software development, MVP stands for minimum viable product.
What the Heck is an MVP?
MVP is a recent concept in software development that dovetails nicely with the agile development methodology. Simply put, MVP is the bare-minimum set of core functionality that must be included for the software to be at all useful. Think of it in terms of an automobile: The minimum features a car needs to make it useful are:
- A control to make the car go
- A control to make the car stop
- A control to make the car turn
That’s it. If any one of these features are missing, the device is useless. Obviously, there are some assumptions wrapped up in these features, such as there being a way to store energy and convert it to motion. But from a user-interface standpoint, the above three features are all that’s required to get from A to B.
So what good is an MVP? The MVP is the first working version of the software, and it is typically used to validate the development team’s understanding of the client’s needs. It’s more than a prototype, but less than a finished product. It’s useful for getting client feedback to ensure the developers are on the right track at an early stage of the project, before expending time and money on other features.
To extend the car analogy, you could build a car with heated seats and power cup holders, but if you forget the brakes, you’re wasting your time.
MVP Mistakes
As simple as the MVP concept is, it’s actually quite difficult to figure out what constitutes that core set of features. It requires a good deal of discussion and collaboration between the development team and the client to get it right. Three of the most common mistakes when building an MVP are:
- Mistaking “viable” for “saleable." One natural impulse is to include all the “important” features that will differentiate the product in the marketplace. The key idea to keep in mind is that the MVP is not intended for release—it’s a stepping-stone on the way to a releasable product. The goal of an MVP is to implement the critical features—and only the critical features—with maximum speed and minimum cost, in order to get meaningful client feedback.
- Overestimating the MVP feature set. For both commercial (revenue-generating) software and internal business applications, it’s easy to get caught up in all the great ideas for features and lose sight of what is critical and what isn’t. Good development teams have tools and methods for evaluating each idea and determining whether it is a critical, MVP-worthy feature.
- Underestimating the MVP feature set. It’s also easy to fail in the other direction, stripping the feature set down past the minimum level. Fortunately, this error is easy to spot during the prototyping stage, before an actual MVP is even built.
Establishing the MVP feature set is tricky, and it takes a fair amount of experience to get it right. At AndPlus, we have the skills to identify the core features and build an MVP that reflects these features. An MVP based on a well-defined set of core features gives the client a clear idea of the otherwise hidden assumptions behind a project and course-correct the development effort at a stage when it is still inexpensive to do so. It’s an essential step in a robust development methodology…with no athletic ability required.
