Business folks like to talk about the “Minimum Viable Product“, generally defined as the smallest product (in terms of functionality) that will still be accepted by the market. It’s an important concept – possibly the most important concept in new product development. Unfortunately, it’s often understood in a way that leads teams to failure. In this incorrect sense, MVP is understood to mean “what’s the least amount of work we can do and still succeed?”
The problem with focusing on “least amount of work” or “smallest number of features” is that it can simultaneously lead you to do less work than you must to be viable and more work than you must to be minimal. Let’s look at each.
Most seasoned engineers and product designers will tell you that it can take a lot of work to make something simple for end users, from both a code and a design perspective. Just look at Google – one search box, with one of the world’s most powerful technical infrastructures backing it up, all to make it possible for billions of people to just type a word or two and find the information they are looking for. Sergey Brin and Larry Page could probably have done less work if they’d thrown a bunch of knobs and dials in front of people, but such a search engine would not have been successful. A few early adopters may have shown up, intrigued by the powerful tech, and MVP theory would have had Sergey and Larry asking for their feedback and making refinements. But this would never have resulted in the simple one-box interface. More likely, they would have just added more knobs and dials.
Which brings me to the second point – focusing on the smallest number of features might, ironically, lead to more work than necessary. Especially when working with early adopters, many product teams find it hard to distinguish between feature requests that are truly necessary to make their product viable and those that are nice-to-haves or even just idiosyncratic to the requester. This leads to more knobs and dials, which forces the team to work harder, delays the product launch, and often makes the product harder to use and less desirable for the 99.9999% of customers who didn’t request the feature.
So if MVP doesn’t mean “do the least amount of work” or “build the smallest number of features”, what does it mean?
I like to borrow a line from the Extreme Programming folks (remember them?): Make the Simplest Thing That Could Possibly Work.
They were mostly talking about simplicity of code, but I’m also talking about the simplicity of the product and its user experience. Why do I use this mantra? Because of its emphasis on simplicity: saving time and getting to market fast is important, but it’s not as important as finding simple, elegant solutions to customer problems. This gives us a good heuristic for determining what feature suggestions are necessary – does the suggestion make the product experience simpler or more complex? If the latter, is it really worth the added complexity?
The late, great Steve Jobs was a master of finding the simplest things that could possibly work. The original iPad shipped without many of the features early adopters were expecting and hoping for, leading to some lukewarm reviews by pundits. But Apple never skimped on the simplicity of the experience. And sales shot through the roof.
Fortunately, you don’t have to be Steve Jobs to find true Minimum Viable Products. You just have to stop asking “what’s the least I can get away with?” and get good at asking “What’s the simplest thing that could possibly work?”
One Response to Minimum Viable Product? Try Simplest Possible Product