Don’t Waste My Time With Your Minimally Viable Product
A few weeks ago, I wrote The Tyranny of the Minimum Viable Product. The crux of the argument was that the Minimum Viable Product was being applied in an unbalanced way — too much focus on features, too little on viability. I provided some examples. Now, I’d like to amplify a bit and provide some prescriptive tenets for how to balance features and viability — and thus avoid creating a minimally viable product.
The key idea behind the minimum viable product is to focus on the smallest set of capabilities that do a job for a customer and determine what customers value before creating more capability. The measure of what a customer needs is their willingness to pay for the product. We often think of this in terms of dollars, but we should also consider time. As a customer, my time is often more important than my money. This is particularly important for a new product. I want the product to do a job for me. There is a dollar cost and a time cost. When I determine the value of the product, I look at both time and money.
My friend Frank Robinson, the guy who claims to have originally framed the idea of the minimum viable product, said his goal is to reduce time to money. That is a perfect goal for the developer. As the customer, I have the inverse goal of reducing time to success. I weigh the cost of the product in both dollars and time. Time costs are very real and they include:
- Time to learn about the product and determine it is something that might do a job for me
- Time to acquire the product
- Time to install the product
- Time to understand and learn how to use the product
- Time to get the product working correctly (this is particularly insidious if the product requires the dreaded call to technical support)
- Time to debug the product and provide feedback to the developers.
All of this time is costly to me, but developers seem to think my time is free. They are wrong. I am far more likely to abandon a product that wastes my time than my money. I want to minimize my time to success with the product.In The Tyranny of the Minimum Viable Product, I described a number of Internet of Things (IOT)products which were simply not viable. One was a hardware security device for your wireless network to prevent malware from infecting your IOT devices. There were a number of challenges with the product including setup and installation, incompatibility with some of the devices on my network, damaging devices on my network, and actually disabling my network from functioning.
I ended up spending about 2 1/2 hours on two separate phone calls and a number of emails with the company’s technical support team trying to figure out why the product was trashing my network. Ultimately they determined that my product was “installed incorrectly” even though I had followed the somewhat convoluted, ambiguous, and contradictory instructions.
In one of my emails to tech support, I sent a link to The Tyranny of the Minimum Viable Product. I received an email from company’s head of product design who wanted to get together with me. We met for coffee and he was clearly excited about his product and its prospects. He showed me a number of features in the product — none of which I could use because I could not get the product to work. He also showed me some nice capabilities that I would never have known about without him showing me. Many were secondary to the job I wanted the product to do — manage security of my IOT devices — so they violated some of the tenets of Minimum Viable Product orthodoxy.
There was minimal documentation for the product and few affordances in the product to give me cues as to how to proceed. While the design of both the product and the supporting app were visually nice, the design did not help me use and understand the product. There was little documentation and the support pages of the company web site were incomplete — despite the very slickly produced marketing sections.
We spoke about my challenges in getting the product to work. I told him that I had a lot of devices on my network — around 56. He was shocked and worried about performance of his product. He said that they envisioned their target customer as a young couple living in an apartment with two laptops, two smartphones and perhaps a tablet and smart TV. They had not envisioned someone who owns a house with a lot of IOT devices. They also envisioned their target customer as having a low level of technical expertise. I thought this kind of curious. Wouldn’t an early adopter of the product be likely to have a number of devices and some level of technical expertise? Would the young couple they envisioned as a customer have the need or desire for his device? More importantly, would they be willing to invest time and money in it?
Eventually, I got the product to work, and it discovered all of the devices on my network. There were a few issues here and there — which consumed time. The device and app were interesting but not terribly useful (IBNU). The app reported on traffic but, given that the entire purpose of the device is security, it would be useful to see what security threats it is seeing and preventing. Maybe there were no threats — but how would I know that?
I spent a huge amount of valuable time on this product with little payoff. It apparently does the job I bought it for, at a modest cost in dollars — but a huge cost in time. I have paid the cost because I am experimenting on myself to really understand the challenges of the Internet of Things — but I am probably atypical. Would a typical customer be willing to pay so much valuable time?
Given my experiences, here are some tenets I’d like to propose — beyond balancing features and viability — to avoid wasting customers’ valuable time.
- Know who your customers are. A new product requires an early adopter. This particular product appeals to someone who has a number of IOT devices and wants to minimize security threats — probably not the young apartment-dwelling couple the company visualized. The marketing was very broad-brush. If the company had a target customer, it was not obvious from their marketing.
- Focus on the job the customer wants done. I bought the product to monitor security — yet there was little indication of how well it was warding off threats. Maybe there were no threats, maybe a lot were thwarted. How would I know? There were also features in the product which were nice to have, but not essential to the job of monitoring security. I would much rather the developers work on viability than those extraneous features. Make sure everything you do focuses on getting the job the customer wants done. Avoid IBNU features.
- Disclose product limitations. One of the things I learned from Frank Robinson is to disclose product limitations to the customer. If your product only works with 25 devices, say so. Disclosing limitations ensures that, in fact, the limitations you have are not such that they prevent the customer from getting the job done. It is far better to be explicit about limitations than to let the customer find out the hard way.
- Design is a balance of form, function, and performance. The physical design of the product, the app, and the marketing materials was beautiful — even the packaging was aesthetically well-designed. But aesthetics is only part of the problem. A well-designed product is designed in a balance of three dimensions: form, function, and performance. Focusing primarily on form is to trivialize what good design is about.
- The product should show you how to use it. The product has minimal documentation — which I applaud. Too often documentation makes up for bad design. Ideally the product would make it obvious what to do. It would have a clear and transparent conceptual model and strong affordances.
- It just has to work. Given the consumer nature of the product,it has to work. It is not acceptable to take hours of valuable time debugging a non-functioning product.
- Documentation and support matter. This company had a beautiful marketing web site but the support part of the site was extremely minimal and incomplete. Spend less on the fluff, and more on the substance.
It may seem that I am just a bitter customer complaining about a product and company. That is not the case. I’ve invested a lot in this product to try to understand the implication for such products going forward. I have 56 IOT devices in my house. That young couple the company envisioned may only have 8 devices today but in a couple of years they may have hundreds and I may have thousands.
Alas, the story has a sad ending for the developer of the IOT security device. Last weekend, I found that my Tivos were unable to connect to their servers and were running out of program info. I tried a bunch of things — taking lots of time — and eventually disconnected the IOT security device. My Tivos then worked fine. That was the last straw. I could not waste any more time on this device. I contacted the developer’s technical support team asked to return the device for a refund. My wife applauded my decision. I will get my $200 back, but can never regain the lost time. By squandering my time, the developer not only lost a customer, but the chance to improve their product and test it with someone who really had a job for it to do.
One of the challenges I had is that one device would fail and cause other devices to fail — in other words, unintended consequences. It is a pain to track down the cause of the problem and debug in a network of 56 devices. If my friend and colleague, designer Mickey McManus is right, the Internet of Things will create trillions of devices. In such a world, we cannot afford failures like I have seen with devices designed using Minimum Viable Product approaches as practiced. As the number of IOT devices increases, complexity increases exponentially, and we will have to find ways to manage it. We must create truly viable products or we will be inhabit a world of chaos. And that would be a huge waste of everybody’s time.
