Case Studies on How to Define and Validate Your Minimum Viable Product (MVP)

Published on by John Teel

In these two videos (and transcript if you prefer reading) you’ll learn all about the lean startup methodology and the Minimum Viable Concept (MVP) concept.

We review two MVP case studies for you to learn from.

In the first video above you’ll learn what exactly is an MVP, and we’ll look at a case study for an imaging drone.

In the second video below, we review a case study for a remote control developed by Steve Wozniak.

These two short videos are actually just a small part of an in-depth 2.5 hour workshop which was held live for members of the Hardware Academy. The full workshop includes 7 in-depth MVP case studies.

You can purchase the full workshop for only $99, or access it plus much more inside the Hardware Academy for only $49/month.

This workshop was hosted by my friend Dave Millman at BizDev.Global. Dave has decades of experience helping hardware startups find their first customers, and he even worked with Steve Wozniak on his first product after leaving Apple. Dave knows his stuff and you would be wise to watch these videos very closely.

Video #1 Transcript:

So, what is this whole MVP thing? You probably hear about it a lot. You hear about lean startup and agile flow, agile development, agile hardware, and the lean startup.

Well, the lean startup approach, this is the diagram that a guy named Steve Blank came up with, the approach that a guy named Steve Blank came up with about 20 years ago or more now. Eric Ries, if you’ve read, Ries started a book with one of his students or apprentices, if you will. But Steve Blank is really the guy. Steve, by the way, started eight companies including six hardware companies.

We’re going to lean on the Steve Blank approach to lean startups and the MVP. His website down there in the corner of the screen, down there in the corner, encourage you to look at it. It’s a crude, old style website but there’s a lot of great content there.

Very recently he wrote on his site that he’s always surprised when critics complain that lean startup Build-Measure-Lean approach is nothing more than throwing incomplete products out of the building and see if they work.

The other comment he made was that that Build-Measure-Learn approach is hard for hardware vendors. How many versions of a product can you actually build? In the last couple of years, he came up actually with a revised approach.

This is the approach that we’re going to be talking about today. Nothing too complex, but we’re going to talk about how you can use a Minimum Viable Product to form a hypothesis, just like we might have all learned back in Science back in school: form a hypothesis; design experiments to validate the hypothesis; test with customers, always with customers, nobody else ;and finally, extract some insight. We are going to give– I think I’ve got five case studies here on the webinar today and even a sixth if we have plenty of time at the end. We get a full agenda.

Now, that drone you saw back on the title screen a few minutes ago was from this article, again, on the Steve Blank website. It’s a great article. I’m urging you all to go read the Steve Blank website. That’s why the first couple of slides are straight off from that website.

Basically, a company came to him that wanted to build drones to gather data, hyperspectral image data, which is basically video data in a whole bunch of different colors of emitted light and then use that data to understand a whole bunch of aspects of how the plants were doing.

The unique aspect is they weren’t going to do it by the field or even by the road. They’re going to be able to do it by the individual plants. It’s super high-resolution data, if the farmer wanted it. They’re going to offer this as a service. They won’t be selling drones. They are going to be building drones and mounting hyperspectral cameras and selling the data as a service. They logically concluded on the screen there that the way to do this was to test their MVP wasbasically to buy it, build it, and test it.

That might seem logical. Maybe if you were told to go test your concept and you wanted to build drones to gather data to sell as a service to farmers, you might think that that might be the logical way to do it.

Lean, this whole lean concept, and the MVP is not about building cheaper or quicker versions of your product. It’s about getting faster to a delighted early customer by testing aspects of your approach.

Again, Steve’s punchline on this whole story was, would it be cheaper to rent a camera and put it in a plane or a helicopter and fly it over some farmer’s field, process the data by hand, don’t even bother to write a line of code, and then present that data to the farmer and see if he wanted to buy it. In that case, there was actually no hardware in that particular MVP even though the product was a hardware product that they were going to use internally to deliver data as a service.

That’s really the punchline that we’re going to be talking about here today is, how can you test your ability to delight a customer with your product. Maybe by designing a cheap hack to test your goal. Maybe by designing a simple product. Maybe by using, God forbid, somebody else’s product to test your product concept and see whether the differentiation will help. Okay?

This may sound real abstract, but something funny happened this week on Hardware Academy. A new member joined from Ghana. I don’t know if you all saw this thread. It’s an amazing thread if you’re at all interested in ramping up low-volume production.

Go read this thread as soon as the workshop’s over because there’s already been some great contributions to it. I want to point out– If you promise to go read the thread, I won’t keep it on the screen because what I really want to point out is this quote from the bottom of his post.

“We are making about 100 units per run. Testing it out among farmers,” that’s his customers, “fixing issues we’ve identified from both hardware and software and making a new batch of 100.”

In other words, he’s doing MVP cycles. That was his first post on the forum. I think this guy’s going to go far.

Video #2 Transcript:

This is dating myself, and I probably shouldn’t do that, but I’m holding something up right in front of the camera. Does anybody know what this is? You’re going to see some much better images on the screen in a minute, not by my camera. This is the first product built by Steve Wozniak when he left Apple way back in 1987.

When Steve left Apple in 1987– He eventually returned. But when he left Apple in 1987, he went off to start his own company to build his own product, and it was this product that you see on your screens right now. It was called the CORE remote control, and it was the world’s first remote control. I’ve got to tell you something. This is an amazing product even today.

Here’s the packaging of the CORE remote control. I guess we’re all on mute, but usually at this point, when I’m showing this live in a room, people start laughing. Does anyone want to volunteer on chat, what might be wrong with this product? Does anybody have any ideas? [silence] Here, this might be the problem, and this is actually my manual. I have the product.

They brought me in to do marketing way back in ’87. I hope you can see that on the screen, but on the big screen, you can see the manual, and I’m showing you a couple of pages of it. There’s some interesting things going on in this manual.

Let’s take a look at how Steve intended for people to adjust the volume. This product had automatic volume adjustment and here is the program for adjusting the volume.

With 30 years hindsight and the fact that we don’t ship manuals with products anymore because they all have to be obvious how to use it from the get-go. This might be really funny, but I’ve got to tell you, it was funny back then too.

That sequence of commands is just not really consumer-friendly for setting volume. Software guys might recognize this, single-step verification, this computer, this universal remote control had a debugger built in. That’s something that only a geek could love, right?

In the maintenance and troubleshooting page, there’s an interesting little comment. Above all, you should not remove the batteries for extended periods of time. The reason that I can’t power up my CORE remote control right now, I’m sure it was built with the finest components that might still be working after 30 years.

But the reason it will definitely not power up is because at some point I let the batteries die and because the firmware was in volatile memory, it died. In fact, every remote control they ever shipped died the minute the batteries died.

This was not really a product destined for a big consumer success. In fact, we should all get written up in the New York Times one day, successes or failures. Unfortunately, Steve’s write-up in the Times that year was a failure, Wozniak Unit to sell assets.

I’ve got to admit, I have not been written up in the New York Times myself yet. Steve has accomplished a whole lot more than I have in life, but this perhaps was not his most shining moment. What went wrong here? Anybody want to volunteer what went wrong? I see that Andy typed in that the manuals– He spotted right away that the manuals was the problem.

Does anyone else want to volunteer in chat what might’ve gone wrong with this product? Again, this was intended to be a consumer product. I’m going to show you one more thing, by the way. We’ll dig in a little bit. Zero customer feedback, ergonomics, not consumer-friendly. Yes to all of those three answers. Now, we’re going to use a technique here. This is one of the reasons you came to the workshop, was to learn these techniques.

Technique number one is to dissect your pitch. What I mean by that is dissect your pitch to identify every single one of your assumptions, because if you say that you’re going to build a premium product that does this and this, well, then you’ve just assumed that people will pay more money than they pay for the commodity products out there for your premium functionality.

If your product pitch says that you’re going to build a faster or a better or a cheaper product that does whatever, you’re assuming that people will pay for a faster or a better or a cheaper. We’re going to be using that technique of dissecting the pitch over and over and over today in the case studies. All right? We don’t have any remaining pitches from the CORE remote control.

Steve Wozniak funded that company himself, so he probably never wrote a business plan. If he had, he might’ve gotten a little feedback, but we do have the manual. The manual has a couple of pages of introduction of the product. In fact, I’ve got two features highlighted there. It’s universal because it can learn, and learning remotes are cool, right? Also, it has a master module which is, not only is it the one of the most powerful transmitters in the industry, but it’s removable.

Let me show you that. This is amazing from a geek perspective. You can remove the infrared module from this remote control, and when you do so, you expose an RS-232 port. You can connect up a keyboard and peripherals to your remote control. I mean, this is a geek’s dream, right? He assumed that these would be desirable features, the removable IR module and the RS-232 port.

Scroll down that page a little bit, and it’s programmable. We saw already some examples of writing programs on the machine with that amazing keyboard, that makes it so easy to write those 20-step long programs. It’s got two custom microprocessors.

The Apple II had one processor, but the CORE remote had two. I think you might be getting a sense of some of the assumptions that Steve might have been making on this product.

Here is a comment that Steve made on his blog, back before there were blogs, about the product. Also, you could connect the terminal to the remote control with a serial link that we made and could bring up a lot of debugging aid, similar to those on the Apple II. You could enter programs in machine code and even operate the LCD display and keyboard. “I’m sorry, I didn’t take this capable machine further.” Who was Steve designing this capable little machine for? Was this going to be a consumer product? It was the first, by the way.

There was no such thing as a universal remote control out there in the market, to be clear. He was a pioneer, but was this going to be a universal consumer product? Anybody want to comment on that? Yes, John just wrote that he was designing it for himself, and Jay just wrote, “Other folks like himself.” That’s exactly right. Let’s do an exercise. First of several similar exercises we’re going to do during the workshop today.

The exercise is, please list on chat and John, I’m going to ask you to start representing the crowd here and reading out some of the nominations. Please type into chat the assumptions that you’ve identified that Steve Wozniak could have tested in order to, basically, he could’ve formed a hypothesis, people want a replaceable IR module, for example.

Please write down the assumptions that you identified that Steve Wozniak was making that could have been tested through the MVP hypothesis process here.

The first one, the assumption that Wayne pointed out is that anyone else wanted the product.

Well, I’ll remind you of one. How many gadgets have you seen in any era where you could pull off the business and get an RS-232 port? Prateek said, “How many other RS-232 products did the customer own?”

Geeks like Steve Wozniak and me at that time did have RS-232 ports on other products, but I’m guessing not a lot of the consumers that were looking for a universal remote for the TV did. That’s a good one.

Others? How many people wanted programmability with a one-step debugger so they could write really complex and long programs to control their home peripherals?

Andy actually wrote something good here. Andy wrote that customers had so many remote controls that they needed another one that could replace them all. That was the core hypothesis of the entire product and absolutely should have been the starting point, yes.

With 30 years hindsight back to 1987 when he did this, we can see that yes indeed there was a market for universal remote controls. You can type that search term in Amazon right now. You can type that search term in the Amazon right now and come up with hundreds of universal remote controls, everyone from Logitech down to dozens of manufacturers you never heard of.

Wayne wrote, “I have a Logitech Harmony programmable remote, and I’m still the only one who will use it.” [laughs] I had a universal remote, and I was in fact the only one in my family who used it too. So, Wayne, I’m with you there. Personally, I think the hypothesis, that he wanted to delight customers with was learning ability and programmability. Now, this is getting really interesting here.

This is probably my key insight to the entire case study. It’s the insight that Steve Wozniak might have gained 30 years ago if he had actually tested any of this with consumers. Does anybody know what the number one motivating factor is for consumers who go to the store or go to Amazon to buy a universal remote right now? Does anybody want to suggest what that is? Because millions of universal remotes are sold every year now.

Wozniak was way ahead of the curve, but– Bingo, first answer, and Jen wrote, “Lost remote.” That is the number one motivating factor. That is why people buy universal remote controls. Learning is cool, and I use learning because I’m a geek. When I had one, programmability is cool, I could tell it to turn on four things at once. Yes, right. Lost remote is the main motivating factor.

In fact, if you’ve lost your TV remote, you can’t turn on your TV and you run down to the store to go buy a universal remote. You don’t have the remote to learn with, you can’t do this thing where you point the old remote at the new remote and have it learn, which this thing does. If you’ve lost the remote, it can’t learn. Learning is of no use, the killer factor and maybe what Steve could have gotten insight to if he’d done the research and asked customers, “Why would you buy such a thing? How could we delight you?”

The winner is the nicest-looking, friendliest remote that has the most codes in it for Sony TVs and Panasonic TVs and LG TVs and Samsung TVs and every other TV made plus every Roku box and Blu-ray player. That was the killer fact and that was the insight that eluded Steve 30 years ago. Maybe he was too early but that’s the kind of insight that you can learn if you test with customers.

If you remember the diagram I showed you, we’re going to look at it again about hypothesis to insight, that’s the insight you could learn. Now, imagine if Wozniak had gotten that insight, it’s about the lost remote, wow, we’d be talking about the CORE remote family today and other remotes would each have a fractional share in the marketplace.

That’s enough with the 1980s examples. We’re going to jump forward now to a much more modern example, and it’s right smack in the middle of hardware start-ups. Take a look at this. When I show this at hardware incubators, people get pretty excited. Let’s take a look at the product…

If you read only one article about product development make it this one: Ultimate Guide – How to Develop a New Electronic Hardware Product in 2020.  

Other content you may like:

0 0 vote
Article Rating
Notify of
Inline Feedbacks
View all comments

Privacy Policy          Terms and Conditions