An MVP Is Not a Cheaper Product—It’s About Smart Learning

7/23/13Follow @sgblank

A minimum viable product (MVP) is not always a smaller/cheaper version of your final product. Defining the goal for an 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.




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 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 was 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. 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 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.


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 are 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 testing first was 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 farmer’s 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…



Lessons Learned

  • Think about cheap hacks to test the goal
  • Great founders keep their eye on the prize.



  • All Hat, No Cattle

    Brilliant, though I’d replace MVP with “Proof of Concept”.