How iterating the MVP can be your Most Valuable Process

Being successful in business depends on one thing: selling something that customers will buy at a cost they can afford.

 Not achieving that goal is the No. 1 reason companies fail. Building a series of minimum viable products (MVPs) allows you to create products you know people will buy, thereby minimizing your risk. Here is how you should build your MVPs to get the results you want.

The goal of your product is for people to purchase it; it’s not enough for customers to merely say they want something. Conversations with your customers to find out what they want can be a good thing and teach you a lot, but those conversations are not MVPs.

The point of an MVP is to test whether a product is something customers will purchase. The key is to focus on whether something is viable, or something that could be a functioning business. If you are an engineer you might focus on whether it is feasible to make, or if you are in sales you might be concerned whether your product is desirable. But if your product does not make enough money to be self-sustaining, the other two don’t matter. Therefore, your MVP should be sold and not given away. Selling your MVP is the only way to determine whether your customers will buy the product. The goal should be to sell your MVP to the minimally sufficient number of customers. You want to expose your product to enough people so you get a good understanding of which customers would be interested. At the same time, you don’t want to expose your entire customer base to a product that’s not yet finished.

The idea is to design your MVP roll-out to ensure that you can release a product, learn how your customers respond to it, and then make changes based on those observations.

If you put too much effort and features into your early MVP, it might be difficult to alter your product based on what you learn. However, you need to make sure you don’t try to overcompensate when you scale back features in early prototypes. When some designers start building their MVP, they often focus on the “minimum” part of the term. This is a mistake because in their rush to build a simple, minimal product they don’t ensure the product is viable, which provides poor data for them to use when they try to make improvements.

 

When designing your tests and MVP to assess your assumptions, consider the following four factors:

The key, especially early in the MVP process, is to test the most important features and assumptions first and then add the bells and whistles with later iterations. An assumption is risky if it has the potential for making a big impact but the likelihood of it occurring is relatively low.

The assumption that has the potential to have the biggest impact is likely to be the core of your product. Your earliest MVP should be focused on the core, and most likely riskiest assumption, of the product you want to build to determine if there is a business there. You need to test the core assumption as soon as possible because if the customers don’t appreciate that feature, the product will fail.

 

Once you have identified all your assumptions, write them down. Also, note how you plan to test each feature.

This provides you with a road map for testing. Test one or two assumptions at a time to ensure you don’t get ambiguous results.

It is important to remember that it is very rare for your assumptions to be completely independent of each other; how a customer responds to one assumption might very well influence how she reacts to another. So when you chart your assumptions and plan how you test them, be aware of how different factors might influence your results and try to adjust for that.

An MVP is developed along two criteria; fidelity and coverage. Fidelity describes how close your MVP is to your original completed concept. So a high fidelity MVP would be a complete, tangible prototype that a customer can use with all the bells and whistles while a very low fidelity MVP might be a written description or interview. Coverage describes how many customers you try to reach with your the MVP; the more customers the higher the coverage. Early on when you have many assumptions to test, you should use low fidelity and low coverage MVPs since these sorts of experiments can be quickly performed and provide more info faster. As your assumptions begin to be verified and there are fewer unknowns, you should then shift to a higher fidelity, higher coverage MVP.

Now that you have identified what you need to accomplish and what assumptions you need to test, it’s time to build your MVP.

For you to learn the most about your customers, the MVP must be stable and usable. If the product doesn’t deliver on its promises, you can’t know if the features are something customers want. When designing your MVP, limit the number of features to only those that test your assumptions, but make sure that those features are well designed.

These few features probably won’t thrill your customers at first. What you need to do is find your “early adopting” customers — those clients for whom the problem your MVP solves is so painful that they are willing to accept a less-than-perfect product now and hope to get the perfect solution later. These are the clients who will have the patience for using your MVP and will give you the best data for future iterations.

Follow these steps and you will increase the likelihood of developing a product that has a faithful customer base and is profitable.