What is a MVP?Reading time: 5 mins
MVP is not a smaller, hacked up version of the final product. There’s a lot more involved, in reality, an MVP is a model that will provide you with the best results from tests that you are conducting to verify the assumptions about your business model.
Most concepts from Lean methodologies have become buzzwords over the past few years and the hype cycle generally goes from not knowing the term to the term being overused without ever passing through the phase of actually understanding what the term does. The concept of MVP is no different, however some lack of understanding behind this term is understanding since the whole concept of an MVP is a bit abstract. So let’s agree on the following definition for an MVP: The MVP is a prototype that you’ve made putting in the least amount of money and time to get initial validation for your idea.
This is arguably one of the prominent lines of thought behind an MVP but a lot of people generally interpret this as a smaller and cheaper version of the final goal, the two become intertwined. Let me present a case from Steve Blank’s (@sgblank) blog1 that illustrates this problem very well:
I ran into a small startup at Stanford who wants to fly Unmanned Aerial Vehicles (drones) with a Hyper-spectral camera over farm fields to collect hyper-spectral images. These images would be able to tell farmers how healthy their plants were, whether there were diseases or bugs, whether there was enough fertilizer, and enough water. They would go out to a farmer fields on a weekly basis, fly the drones, collect and process the data and act as a data provider to give it to the farmers in an easy understandable form.
And from their ideas, they decided to make an MVP in the following form:
They concluded that the only way to get a delighted early customer was to build a minimum viable product (MVP). They believed that the MVP needed to, 1) demonstrate a drone flight, 2) make sure their software could stitch together all the images of a field, and then 3) present the data to the farmer in a way he could use it.
And they logically concluded that the way to do this was to buy a drone, buy a hyper-spectral camera, buy the software for image processing, spend months of engineering time integrating the camera, platform and software together, etc.
This approach is the pitfall that Steve is trying to illustrate:
The team confused the goal of the MVP, (seeing if they could find a delighted farmer who would pay for the data) with the process of getting to the goal. They had the right goal but the wrong MVP to test it. The team’s hypothesis was that they could deliver actionable data that farmers would pay for. Since the startup defined itself as a data services company, at the end of the day, the farmer couldn’t care less whether the data came from satellites, airplanes, drones, or magic as long as they had timely information.
They had defined the wrong MVP to test first. What they needed to spend their time is first testing is whether farmers cared about the data. So I asked, “Would it be cheaper to rent a camera and plane or helicopter, and fly over the farmers field, hand process the data and see if that’s the information farmers would pay for? Couldn’t you do that in a day or two, for a tenth of the money you’re looking for?” Oh…
This issue is not isolated in that a lot of people fail to understand the idea of a MVP because it’s very abstract. Situational analysis makes it very easy to fall into a local minima and (Conveniently you have no clue of your relative location in the landscape either) you confuse this local minima as the global minima and stay there2. So I think part of the problem lies in how we define an MVP. If our definition can be updated, then I think we can apply it better and avoid the pitfall is that an MVP is not a smaller, hacked up version of the final product. Here’s my first attempt to try and redefine a MVP:
A MVP is not smaller hacked up version of the final product but
MVP is testing your core-hypothesis (for instance, will customers care for farm data?)
The testing of your MVP is like steering the car while pressing the accelerator, the right kind of testing will steer you forward to learning whether this product can be made into a viable business. The wrong kind will lead you somewhere because you’re still accelerating but you’ll get off the road due to the fact that you’re not steering properly.
From the points above, every single test of your MVP will give you steering and acceleration, not changing transmission to get the car started.