In product development, the term minimum viable product (MVP) is an important concept that everyone involved with product development should know. The MVP is a product with the fewest possible features that can still be used by early adopters. The purpose of the MVP is to solicit feedback from early adopters. Following the lean start-up principle to achieve the MVP can help you confirm or dispute assumptions made about the market, manage costs, manage scope creep, and reach the market faster.
Planning the MVP can be the most argumentative phase in the product development life cycle. Stereotypically, there is a power struggle between the non-technical professionals who want all the bells and whistles and the technical professionals who want to limit scope. The differing perspectives of each party makes it difficult to agree on what features belong in an MVP.
Based on our experience, here are some considerations that support features proposed for an MVP:
Critical Business Function – This one is obvious, but if your business is in the business of helping customers find pizza deals, then your MVP should probably include some ability to help customers find pizza deals. This doesn’t necessarily mean you must build this service from scratch. You can consider leveraging other technologies out in the market, or even manually servicing customer requests. Since finding pizza deals is a critical business function, you should offer the service in some way, shape or form.
Strongly Advocated by Market Place – If your potential customers have asked for a feature on numerous occasions, then it is a worthwhile consideration for an MVP. Sometimes you can have the community of early adopters vote on the feature they like to see most. This helps your team prioritize development. Everyone will agree that advancing one feature will delay the release of another feature.
Metrics to Evaluate Usage – There should be some way to evaluate the success of an MVP. Initially, you might be able to ask an engineer to inspect the database for key metrics, but if it is simple and straightforward, you should consider a crude report that exposes key performance indicators. This is especially the case if the business subcontracts execution to an outside vendor that may not always be involved in the business.
Here are some considerations that may not support features proposed for an MVP:
Does Not Leverage Existing Resources – If a proposed feature does not leverage the capabilities of other features, then it might not be a critical business function. It might be an entirely separate service that deserves a separate initiative.
Not Approved by Market Place – If a proposed feature has not been presented to early adopters for the feedback, then it should not be part of the MVP. If the early adopters gave negative feedback on the proposed feature, it probably should not be a part of the MVP.
These are the popular points of consideration when deciding on which features belong in the MVP. Do you have any suggestions to add? How would you challenge features proposed for an MVP? Let us know in your comments below!