We all know that to build a successful minimum viable product (MVP), all you have to do is formulate a business hypothesis, decide on core features, and hire Yarandin, Inc., which offers its famous six-day MVP, to validate your hypothesis. We’ve discussed this previously. It’s a no-brainer. What we have not discussed, though, is how exactly you are going to decide on features that should make up your MVP. As is often the case in business, the answer is not trivial, and this is the topic of today’s article.
Let’s recall the example of Uber from “How to Build Your First MVP Mobile Application.” As you may know, the minimum viable product that Uber developed contained very limited functionality. In fact, what it did was connect drivers with clients and allow payments. Yet today’s Uber has a much more sophisticated application with hundreds of features, some of which are hidden from the end customers with the goal of enhancing their experience. Uber started with a business hypothesis that turned out to be true, but would what would have happened if it hadn’t? Let’s consider another example. OpenTable, an online restaurant reservation service company, also started its business with a minimum viable product, but it did not build a simplified solution. Its founder, Chuck Templeton, instead worked with clients and manually guided them to find out who would pay and how much. In its early days, OpenTable, in fact, provided more features than it does today to invalidate the necessity of some of them.
These two examples demonstrate that there are different types of MVPs: those that validate a business hypothesis, like Uber’s, and those intended to prevent entrepreneurs from solving the wrong problems (sometimes called “concierge MVPs”) by invalidating assumptions, like OpenTable’s. The goal of each minimum viable product, of course, is to maximize learning and drive out risk by testing assumptions. But different types of MVPs accomplish that goal differently, and the right choice between the two is not at all obvious. In many cases, invalidating MVPs do a good job of invalidating business assumptions, although they can also be effective in learning what problems should be solved. It is also important to understand that the two types of minimum viable products do not exclude each other. It is often a good idea to begin with an invalidating MVP and then switch to an MVP that validates a business hypothesis.
In conclusion, deciding on the right type of minimum viable product is not a trivial task. To build a successful MVP, it is not enough to formulate a business hypothesis and develop a product with core features you built based on your experience and best judgment. First you have to decide whether you’re going to validate or invalidate your business hypothesis with an MVP. This is an important strategic decision—and this is why you should always hire MVP developers who, like Yarandin, Inc., provide both MVP development and consulting services. Making strategic decisions, such as choosing the right type of MVP, can lead to success or failure for your business. You don’t want to make a mistake.
