In honor of March madness, I thought I would talk about MVPs and why you should stop admiring them. I was working at a company developing a product with the primary goal of delivering an MVP to market as fast as possible. Great, I said. I am a firm believer in the power of the MVP to deliver a quality product to market. No, I’m not talking about Most Valuable Player in the sports-sense, but rather Minimum Viable Product as presented by Eric Ries in his best-selling book, The Lean Startup.
[amazon_link asins=’0307887898′ template=’ProductAd’ store=’flyin059-20′ marketplace=’US’ link_id=’7e553030-140a-11e7-b37b-9332fa29805b’]
An MVP is supposed to:
- ~Test Market Assumptions
- ~Satisfy Customers
- ~Start Making Revenue
However, some companies seem to have lost their way and mutated the definition into some grotesque freak show. There is a growing base of consumers that are becoming increasingly disgusted with the quality of products being delivered to store shelves. Why is this? What has shifted and can it be fixed? I am a firm believer that as long as we are still breathing, there is still time. So, what do we do next? To answer this question, we need to see a successful MVP in action. Dropbox started out as just such an MVP.
For all its seeming simplicity, if you were to look under the hood of Dropbox, so to speak, you would see a Lamborghini. Dropbox software interfaces with numerous Operating Systems like Apple’s iOS and Microsoft Windows. It handles virtually any file type and all while in real time. This is not a small feat. However, in order to gain initial funding, Dropbox founder Drew Houston needed a demo. What is a startup techie to do? Naturally, he turned to The Lean Startup methodology and the concept of the MVP. The software was way too complicated to prototype, so he fudged it. He created a demo video full of Easter Eggs for his target audience that demonstrated how the software would work and then used that as an engine to drive capital. For Dropbox, the MVP was the demo. And it worked brilliantly, generating over $250 million. Now, the Dropbox team had to focus on emulating that video. They developed and tested frequently with real people. Eventually, they ended up with a seemingly simple yet powerful piece of software. According to TechCrunch, “one of Dropbox’s biggest competitive advantages is that the product works in such a seamless way that the competition struggles to emulate it.” Just how an MVP should work. For more information on Dropbox and their demo video, check out How DropBox Started As A Minimal Viable Product.
From Dropbox, we move to Windows 8. What was once a lukewarm product has morphed into a memory-hungry, slow moving giant. Too many features that many users don’t enjoy (myself included) released too early, leading to unhappy customers. Unfortunately, options are limited. You can switch to Apple iOS, along with your hardware, and software programs, which may not even be available to an Apple-based platform. Or you can switch to a freeware operating system like Linux with its own quirks, but with an extremely loyal fanbase. Not pretty. There must be a better way.
In Alan Cooper’s 2004 book, The Inmates are Running the Asylum, he extends this sentiment across most technology. Further asserting that, at its core, technology is designed by technophiles, while most users are technophobes or at least not early adopters. There needs to be a stronger link between user and designer. There needs to be a better definition and path forward. There needs to be a better MVP.
[amazon_link asins=’0672326140′ template=’ProductAd’ store=’flyin059-20′ marketplace=’US’ link_id=’29419be2-140f-11e7-a489-2d6023dd7b92′]
We need to redefine MVP from the minimal amount of work to get the product out the door, to the minimum fully-tested and functional feature set to make our target users happy. Not satisfied. Not lukewarm. Happy. Ecstatic even. We all need to be in the happiness delivery business. Everyone of us.
The first step is starting with your users, the people that touch your product and ultimately control your company’s fate. Then, expand from there. As with product development, test early and test often. The trick is to focus on what needs to be tested. You are not verifying a completed product, but rather narrowing down your feature list. At least at first. This is sort of like feature creep in reverse.
Let’s say you have a concept for a new alarm clock. Initially, you have 5 “must-have” features:
- It must tell the time.
- It must allow you to set the time.
- It must alarm.
- It must allow you to set the alarm.
- It must light up and flash when it alarms.
However, after a little brainstorming you think, “wouldn’t it be cool if it did these things too? Our customers would really like this. We could go viral!”
- It must make coffee.
- It should have removable face plates.
- The alarm should turn off when you touch it without the need for a button.
- It should be able to play music from your favorite Pandora station.
- It should turn on the lights.
Cool ideas, but how do you know if your customers will actually want them? What if your customers don’t drink coffee? What if they don’t listen to Pandora and use Spotify or a CD player or the radio? Let’s make a prototype and see.
The first step is hacking together a prototype. It needs to be able to perform the 5 minimum required features, and lets pick three of the brainstorm ideas to test. How about removable face plates, turn off when it is touched, and plays music? We eventually want to test all of our ideas (assumptions), but these items are quick to implement, probably in a week or less, and can be cheaply prototyped. We make some 3D prints, use some off the shelf hardware like Arduino, and code some simple software. In parallel, we use resources like Craigslist, LinkedIn, etc. to gather 5 people. We bring them in one at a time and give them a small task to do, such as set the alarm or turn off the alarm by touching the alarm and record what they do. Most importantly, while they are doing this, we make sure that they think out loud. The goal is to get into the mind of your user. Get feedback on what they prefer by asking questions, just don’t show them what to do.
After our test, we learned that our customers really didn’t want to change the faceplates and a simple radio was just fine. No need for more complications and this saved us a bundle in complexity and cost. Time to rinse and repeat. This time, we can take a play from Dropbox’s playbook. Let’s make a video or power point simulator and show the users what the product could do with regard to making coffee and turning on the lights. Again, we construct our prototype while gathering our user group. We test one at a time, gather feedback, and review. It turns out neither feature is wanted, as they buy their coffee at Starbucks and prefer to turn on the lights by themselves.
Looking at our requirements, we went from 10 fairly complex requirements to 7 very simple ones:
- It must tell the time.
- It must allow you to set the time.
- It must alarm.
- It must allow you to set the alarm.
- It must light up and flash when it alarms.
- The alarm should turn off when you touch it without the need for a button.
- It should play music via radio.
This quick user testing was done cheaply but with a high quality standard. Requirements were lowered, resulting in an overall cheaper product, which when sold at the desired price point leads to a higher margin. In addition, this was tested with a small group, rather than an entire market. If the initial requirements were used and given to a market, and then the product refined, there would be a number of unhappy customers, a big hit to the bottom line, and probably a few folks out of work. When you go to launch revision 2, you will not only have to relaunch the product, but convince now skeptical users that no, really, we actually did fix it this time. Take our word for it. By keeping testing small and fast, we come off to our customers and companies as heroes. No, you can’t learn everything from Use Testing, but you need to establish evidence that you can expect happy users with the product you have. By limiting the scope of the audience and the cost of the prototype, risk is minimal, but the reward is absolutely huge.
We need to stop launching products before they are ready. We need to identify the feature set that will make our customers over the moon, and do no more and no less. We need to test those features to make sure they work flawlessly by placing our prototypes in front of real people and getting their unadulterated feedback. We need to start asking ourselves, If I wasn’t able to make any further changes to this product, would I be happy with my name attached to it?
Would I want this for myself?
We need to launch products we are happy with and that our customers love. Once we have a successful launch, we can look at adjacent markets and repeat the process. Amazon successfully launched first in books, establishing themselves as a leader, and then expanded into adjacent markets. This is a very powerful strategy. It can be done. It’s time to think more strategically, more long term. Business is like chess. You need to develop your pieces, try different tactics, and eventually corner the product you want.
Our end game is certainly not a loss, or even a SuperBowl win, but rather a good, solid touchdown.