An MVP is not a Cheaper Product. It's about Smart Learning
A minimum viable product (MVP) is not always a smaller/cheaper version of your final product. Defining the goal for a MVP can save you tons of time, money and grief.
Drones over the Heartland
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. (The camera has enough resolution to see individual plants.) Knowing this means farms can make better forecasts of how much their fields will produce, whether they should treat specific areas for pests, and put fertilizer and water only where it was needed.
(Drones were better than satellites because of higher resolution and the potential for making more passes over the fields, and better than airplanes because of lower cost.)
All of this information would help farmers increase yields (making more money) and reduce costs by using less water and fertilizer/chemicals but only applying where it was needed.
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.
Customer Discovery on Farms
I don’t know what it is about Stanford, but this was the fourth or fifth startup I’ve seen in precision agriculture that used drones, robotics, high-tech sensors, etc. This team got my attention when they said, “Let us tell you about our conversations with potential customers.” I listened, and as they described their customer interviews, it seemed like they had found, that – yes, farmers do understand that not being able to see what was going on in detail on their fields was a problem – and yes, – having data like this would be great – in theory.
So the team decided that this felt like a real business they wanted to build. And now they were out raising money to build a prototype minimum viable product (MVP). All good. Smart team, real domain experts in hyper-spectral imaging, drone design, good start on customer discovery, beginning to think about product/market fit, etc.
Lean is Not an Engineering Process
They showed me their goals and budget for their next step. What they wanted was a happy early customer who recognized the value of their data and is willing to be an evangelist. Great goal.
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 They showed me their barebones budget for doing all this. Logical.
And wrong.
Keep Your Eyes on the Prize
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. Here’s why.
The team’s hypothesis was that they could deliver actionable data that farmers would pay for. Period. 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.
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.
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…
They thought about it for a while and laughed and said, “We’re engineers and we wanted to test all the cool technology, but you want us to test whether we first have a product that customers care about and whether it’s a business. We can do that.”
Smart team. They left thinking about how to redefine their MVP.
Lessons Learned
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
This concept is important enough to coin a new term, say “maximum learning action” - the thing to do next that will test hypotheses efficiently.
This will emphasise the point, rather than being dragged back by incumbent interpretations of the words “product” or “viable product”.
Good advice!
Some experimentation and proof of concept discussion and demonstration with the prospective user/customer, before committing to build a mission-capable prototype.
Hmmm… what other enterprise could use this approach? 😉