The Tyranny of the Minimum Viable Product
I am the victim of Minimum Viable Product mentality. Minimum Viable Product (MVP) is a product development methodology popular with start-ups to focus a product on the minimum viable feature that will appeal to a customer. Unfortunately, engineering and business culture often focus on minimum features and forgets the viability part. This results in products that are unstable, unusable, and just plain unacceptable.
Much to my wife's dismay, I am an early adopter of a number of Internet of Things products. At last count, I had a dozen separate systems in my house, my car, my body, and even on my dog to track, monitor, and control all kinds of things. The problem is that many of these systems do not work — they are not really viable. I waste huge amounts of time trying to get them installed, connected, and working as advertised. Sometimes I succeed, sometimes I fail. Here are just a few examples:
Smart home hub. I have a popular "smart home" system to control lights, monitor doors, and generally keep an eye on things. A central function of the system is to turn lights on and off at specified times or at events such as sunset and sunrise. The system randomly misses times and events. And, when my network fails, so does the hub.
— forFitness scale. I have a bathroom scale that wirelessly ties into my online fitness app. After a year or so, the scale required a change of batteries. When I changed the batteries, the scale "forgot" my wi-fi network settings. I had to spend a frustrating 30 minutes using a variety of computers and mobile devices to get the wifi connection working again.
Thermometer batteries. I have a popular internet-connected thermometer with a temperature sensor in the garage. The batteries in the garage sensor need to be changed at least weekly, if not more frequently. Other components have never needed a battery change.
IOT Security device. I discovered a device that was all the rage at a recent trade-show. It purports to protect your entire collection of internet of things devices from malware. All of the reviews were glowing, so I purchased and tried to install. The setup seemed really straightforward but, of course, things did not go as depicted in the instructions. I could not get the device to work. When I contacted tech support, there were several additional steps that I needed to take that were nowhere specified in the instructions. When I got it running, it turns out that my TIVOs could not download their program data. Seriously, this device does not work with TIVOs? Aren't TIVOs pretty common? The device company promised that a fix was in the works and would be automatically pushed to my device. A couple of nights ago, a bunch of my lights would not turn off. I got up and diagnosed it and it turned out my network was completely inoperable (thus taking my smart home hub — which controls the lights — offline). When I traced the problem back, it started at precisely the same time as the fix had been pushed to my security device. When I disabled the security device, the network was once again functioning. To top it all off, one of my security cameras died. When I called tech support for the security company, they determined that the camera went offline at precisely the time of the pushed fix. The camera was damaged and had to be replaced.
Why so many product failures? One could speculate that these are all early stage products, built by struggling entrepreneurs on the ragged edge of failure. Possibly. But some of these products are developed or backed by large, well-funded, and experienced companies. I think something else is going on — the tyranny the Minimum Viable Product.
The Minimum Viable Product (MVP) is all the rage in the startup community. The idea is laudable, to focus on core elements of a product that will appeal to early adopters, then build from there as customer needs are uncovered and customers developed. The intent behind the MVP idea is to minimize wasted effort and risk — to focus the product on only the key elements that will capture the imagination of early customers, let them understand the vision and direction, and see the product as an early demonstration of that vision.
The concept is a good one, but its implementation is often flawed because of this unbalanced view:
Deeply embedded in product development culture is the notion of a "feature" — often taken to be an atomic unit of functionality. Development culture (and product management culture, for that matter) seems obsessed with features. We prioritize them, count them, and try to optimize the number of features we implement. But the very notion of a feature is incomplete. It focuses only on what is to be done, not how it is to be done. It screams functionality, and only whispers viability.
In his 1974 classic of philosophical fiction, Zen and the Art of Motorcycle Maintenance, Robert Pirsig describes two kinds of quality
- Classic quality — based on rational analysis, decomposition into parts and their relationships, concerned with details, inner workings, and mechanics.
- Romantic quality — understanding the overall gestalt or feel, looking at the whole rather than the parts, relating to context, emotion, and being in the moment.
Although this is a gross over-generalization, engineers and business people tend to be educated to think about classic quality and classic quality is the mental model they apply to their work. Designers and artists tend to live more in the realm of romantic quality and that is the mental model they apply to their work. What we often refer to as the "user experience" is the intersection of classic and romantic quality. If we overweight classic quality at the expense of romantic quality, we end up with a poor user experience.
Mapping these two kinds of quality to the way MVP is practiced shows us that this imbalance is what results in products that don't work as advertised, are overly complicated; don't play well with their contexts, and just outright fail. Developers put too much emphasis on features and functions (classic quality) and not enough emphasis on the whole and its context — i.e. viability (romantic quality).
So what is the solution? Obviously, it is to take a more balanced approach — to think about both minimum feature set and product viability in tandem and to give each equal weight.
If we did this, we'd be concerned as much about how the whole product "works" in the design sense — meaning that it implements its functions, but does so in a way that the user can understand the functions, they work within their context (i.e. the other devices and system around), and they actually do the job they are intended to do — flawlessly and painlessly.
There has been a lot of attention to design in product development lately. That is good in that it is bringing romantic quality back to product development. Much of it is, however, superficial — it is about the form of the object. We need a deeper design — one that exercises the entire gamut of romantic quality. We need design that balances classic and romantic quality.
Given limited time and resources, that might mean doing even fewer features. But it will mean doing them exceedingly well. This is possible. I gave a number of examples of failed consumer Internet of Things products above, but one that I recently acquired actually accomplishes this — it is a connected video doorbell. Although it has several "features", it really does only one thing — it is a doorbell with a video camera that can be viewed from a smartphone app. But it does that one thing exceedingly well. The app was easy to use and straightforward. The product was easy to install (including very clear instructions), it connected quickly to my wi-fi network and my existing doorbell, it was visually appealing, and it even included a tool kit that was all that was necessary for installation. It took me about 15 minutes to install and it just worked — the first time — no fuss, no muss. My wife even liked it!
What struck me about this product is that it is probably more minimal than many other products developed under an MVP mindset — yet at the same time it was more functional and more useful than most. By ensuring that it did only one job but did that job exceedingly well, the product is extremely satisfying.
The Minimum Viable Product is a great idea. It focuses teams on what is important. I feel, however, that it has been misused because of too much focus on minimal and too little focus on viable. It is ironic that this is an issue with consumer-based Internet of Things products — after all, the Internet of Things is all about context, connectivity, and networks. The overall gestalt of the networked experience is far more important than each individual thing. Releasing products that aren't viable just begs them to be tried and discarded. App developers for mobile devices know this. They know that an app must be totally usable the first time out, or people will delete it after 10 seconds.
For MVP to truly help develop products that work for the Internet of Things, developers need to focus on romantic quality — viability and user experience as much as or even more than classic quality — features and functions. Bringing viability onto an equal footing with features is what is needed to use the MVP mindset to truly make products people want and love.
