Defining An MVP Properly for Your Goals

When you need to create a minimum viable product (MVP) the process is not that different from designing any other product. However, the process is more challenging. The process requires tighter control over the scope of requirements through to deployment. This type of product is becoming a standard way to step towards funding and is worth closer examination. Why Create An MVP? As with any software product, the decision to create an MVP needs to be made. Thus, we need to look at whether an MVP is a better choice than a full-blown product. The first thing to understand is that an MVP must be a product that has value and is usable. That is the "V" of the equation. It may seem contradictory, but you need to have a good idea of the full product to decide whether an MVP is the right choice. I have found that starting with the full solution and whittling away to a smaller, yet viable, application is the most straightforward approach. When you do this, you have the complete picture in mind while you are taking off less-important pieces. It is harder to start with nothing and add in features until it becomes viable. This approach also makes it easy to look at the differences between the minimum and full product. When those two versions of the product are very close to the level of effort, then an MVP is not a good choice. Throwing Features Overboard The hardest part of the minimal approach is finding out what can be pushed off and workarounds that are needed to compensate for missing pieces. There are best practices that we want to embrace. However, those approaches may be a bad thing for the minimum product. This includes some potentially significant aspects of a product like scalability and even stability. I assume that the funding and resources available once the MVP is accepted will be enough to correct any shortcuts you take. If that is not the case, then you will have to avoid some (or all) shortcuts while building the minimum. Focus on what the user sees and experiences. This makes some features easy to drop. For example, any administrative functions should be assumed as not needed until a strong case be prepared for them. Long-term features like archiving data and large-scale reports or features are also obvious candidates for the "future" list. That enterprise-class solution you vision at the end is not what you need when just starting out. Therefore, any feature that is only moderately useful (or less) when users are just getting started with the solution is one that should be pushed to the future. The Bottom Line The goal of an MVP is getting to market with a minimum investment. Thus, we want to focus on implementation and the core features. Any feature that is not directly related to the main problem being solved should be skipped. Once you have stripped down the elements to bare-bones, add what you need to make a useful application. Beware of features that increase the mass appeal. You only need to provide a minimal appeal for the solution at this point. In particular, appeal to the investor(s) and your MVP will be successful.