Lesson: Customer Development with Steve Blank

Step #8 MV Product: Build a product with only the necessary features to get money and feedback from early adopters

This is where the difference between physical and web mobile channels first come into play. The MVP for a physical channel that is something you sell directly through stores and with a direct sales force is very different from something that you might be building for the web or even more so for a mobile channel.

So in a physical channel what you really want to have is something that the customers can touch and feel because you're going to be out talking to them and well you can certainly go out with a PowerPoint deck with a photo of what the product is going to look like, etc. My advice always is, invest a day or two to in building something even if it's out of Styrofoam and cardboard.

Or if it's something as small as a chip, a micro-photograph or a micro-photograph of a proposed die layout. That is almost for any physical product you should probably be going out and trying to get some reaction based on something people can see and touch.

In doing that you're going to test your understanding of the problem, test your understanding of the solution and when you do that it's going to prove that it solves the core problem for the customers. You're going to learn what the minimum set of features are from the early evangelists.

In a physical channel, this requires lots of interviews demos and prototypes and lots of eyeball contact.

In a web or mobile product instead of building a physical prototype you need to have a "low fidelity" app or website available for customer feedback. What does "low fidelity" mean? Well, that's just kind of my description of, you don't need an entire finished website but you should at least have a wireframe.

If you don't have a wireframe, you should at least have a PowerPoint of mock ups or flash demo or something so that people could see not only what you're describing in words but actually can say "Oh, I get it." Now remember, don't demo that first. Your goal here is to first understand the problem.

I make people, sometimes, who like to give demos leave all that stuff home when you're first having the problem discussion. The minute you get into the "Well, would something like this solve your problem," for a web mobile app, you really want it to get feedback on a low fidelity app as quickly as possible.

When we teach this as a class, literally by the second week of the class, if you're building a web and mobile app you have to have your site or wireframe up and running so that people can actually see it and give you feedback.

Later on you're going to build what I call the "high fidelity" app and that tests your understanding of a solution. This actually has most of the features, might not have help files, the graphics might not be complete but a high fidelity app gives you more resolution on "We really didn't like that color," "that button was in the wrong place," etc.

This helps you avoid building products no one wants and it maximizes the learning per time spent on the product and on customers. Now why you're doing all this is to define the "Minimum Viable Product" or sometimes called the MVP for short.

The MVP basically is what product or service you're building in your first instance that's delivered to customers. The MVP is not in alpha or beta, it's a big idea. In the old days, the product development process would go from seed funding to concept to a market requirements document to an engineering requirements document and blow out into an entire waterfall development process.

Part of those steps were alpha tests, beta tests and first customer ship. You'd be shipping and telling customers "Here's a buggy, unfinished product, why don't you test it for me." Then you'd always argue with sales about whether you should charge for it or not.

The MVP is actually quite different. The MVP says, "No, no, no, were not specing a version 1.0 product that has a spec 18 pages long," were actually doing the work outside the building first and trying to understand what's the minimum version of a version 1.0.

Not what engineering or the founders thought but what is it that customers are going to tell us, they'll pay for a use now, and while it might be "a beta product", we never use that word. We actually tell customers it's a "minimum viable product".