A minimum viable product (MVP) is not about creating a smaller or cheaper product, but how to start the learning process and test the business model. In his article, An MVP is not a Cheaper Product, It’s about Smart Learning, Steve Blank gives an anecdotal example of a small Stanford startup making the mistake of confusing the goal of the MVP with the need to build an expensive prototype.
Their plan was to be a data service provider in an emerging business called “precision agriculture.” They would go out to a farmer fields on a weekly basis, fly the drones, collect and process the data and then give it to the farmers in an easy understandable form.
The team did their research and discovery and the feedback they gathered did confirm that farmers would theoretically see a value in the data this project could offer. The team then laid out their next steps: raise money to build an MVP, as Steve explains:
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 hyperspectral camera, buy the software for image processing, spend months of engineering time integrating the camera, platform and software together, etc. They showed me their barebones budget for doing all this. Logical.
And wrong.
The team confused the goal of the MVP (customer discovery), with the process of building a prototype. Blank proposed the following cheaper alternative to the team which would better prove the goal of their MVP: to find early adopters who would pay for the data:
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…
Blank’s suggestion caused this team to step-back and rethink what their MVP needed to test; this shifted their focus from building a product prototype to understanding what they needed to learn from it. Because they defined themselves as a data services company, they needed an MVP that proves the data they can offer farmers is valuable before spending time and capital:
“That meant that all the work about buying a drone, a camera, software and time integrating it all was wasted time and effort – now. They did not need to test any of that yet. (There’s plenty of existence proofs that low cost drones can be equipped to carry cameras.) 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.”
By showing an example of a team going after what most people would assume is a viable MVP, Blank demonstrates the misconception that has become synonymous with MVP – the need to build a cheap version of the product and get it to potential customers. For example, author John Burgstone cites in this Inc. article:
Lean startup principles encourage entrepreneurs to introduce products quickly to the market and learn from customer feedback. It sounds smart on its face, because learning from customers is hugely important. But going to market with a lackluster product can be insane.
However, as Eric Ries specifically points out in the Lean Startup Principles, “The first step is figuring out the problem that needs to be solved and then developing a minimum viable product (MVP) to begin the process of learning as quickly as possible.” This is a concept many teams miss as they mistakenly focus on building product quickly to get feedback, as opposed to creating an MVP to start learning. At the early stage of learning, you may not even need to write a single line of code, as Eric Ries explains in this TechCrunch article how DropBox used an MVP to learn:
The challenge was that it was impossible to demonstrate the working software in a prototype form. The product required that they overcome significant technical hurdles; it also had an online service component that required high reliability and availability. To avoid the risk of waking up after years of development with a product nobody wanted, Drew did something unexpectedly easy: he made a video.
Blank’s article concludes his example with the team rethinking their MVP with the goal of learning if they had a viable product quickly and without spending money unnecessarily. He concludes with his major lessons learned with this team:
- A minimum viable product is not always a smaller/cheaper version of your final product
- Think about cheap hacks to test the goal
- Great founders keep their eye on the prize