The idea of minimum viable product is gaining currency, and I’m glad for that. It’s another way of saying Something Simple Right Now, or Learn to Fail Faster. It’s a method for distinguishing what will work from what we wish would work.
Please take a look at this excellent brief example from Steve Blank of how a bunch of entrepreneurs were about to go down a path that was far more expensive and wasteful than necessary—all the while thinking they were being cheap and efficient.
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.
In other words, their plan was to build a demonstration version of their product as cheap and efficiently as possible. But they had set out to answer the wrong question. No one doubts that such a product could be built. The unanswered question was whether farmers were interested in paying for the service that the product would provide. And there was a far simpler, faster, and cheaper way to answer that question:
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…
I like that Blank ends his tale with this honest response from the engineers.
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.”
I used to see this all the time when I worked for high-tech corporations. The solutions proposed by any given team—marketing, sales, research, development—had an uncanny propensity to be just the sort of thing those kinds of guys would find fun and interesting to execute. I’ve been that guy myself, leaning towards proposing that we use a particular programming language or software tool or piece of hardware because I wanted to play with it, not because the project required it.
I’ve learned to resist such urges, but not perfectly, so I’ve also learned to defuse the urge by indulging it in harmless ways while also reminding myself that it is an indulgence. Did I need my Nexus 7 tablet, or the top-of-the-line Kindle, or a portable Bluetooth keyboard? No, but they fit within my indulgence budget, and each brought with it some good—I love the keyboard, like the Kindle a lot, and use the tablet from time to time. Having made those purchases (relatively small ones, and over the space of a couple of years) helps take the edge off my lust for cutting-edge technology for its own sake, and keeps me practiced at actually evaluating a potential adoption, rather than just always saying yes or no.