Your MVP is neither minimal, viable nor a product

I find myself in a frustrating conversation when I talk about minimal viable products. A goodMVP is not viable and is certainly not a product, that's what the term is about. Chances are it isn't as small as you want it to be.

In the world of lean startups, founders have to figure out how to fail as fast as possible. If you fail, you end up with a functioning business. Trying to fail involves looking at your business opportunities and thinking about where you might fail in the future. Go and figure that out.

If the entire customer base is already happy with eBay, you can't build the world's best platform for selling Beanie Babies. If the scooter companies don't care if the scooters get stolen, then it's not a good idea to create a lock for them. It would be great if there was a way to know if anyone would buy your product before you write a single line of code.

So where do they come from? The smallest amount of work you can do to confirm or debunk your hypothesis is called an MVP. Eric Ries, the author of The Lean Startup, uses a particular example. It wasn't a full product, but it was full of features. A lot of features were not stripped away. The video showed how a product might work. If they build it, they will be able to find a customer base for their product. They built the product and made it a huge success.

How DropBox Started As A Minimal Viable Product

Designing a good MVP

Thinking outside of the box is what a good MVP is. How much code can you write? Is it possible to get away with doing no design? If your biggest question is whether you can attract customers for a customer acquisition cost that makes sense, could you just run an advertising campaign and a check-out page, and then just refund whoever places an order? If you're worried about brand risk, could you create a fake brand and get an answer to your product?

The trick is to think carefully about the hypothesis, what needs to be true about your product, the market, the problem space you are entering, the customers you are hoping to attract and the competitive landscape. Are your assumptions correct? A really good question is what starts the design of a goodMVP. There are a few examples.

• Is it possible for us to reduce four hours of manual accounting tasks to a script that can be run in three minutes? This is a technical MVP — you probably need to hack together some code to see if you can reliably automate manual tasks.
• Can we find someone who is willing to pay to automate this task? In some cases, the answer will be “no” — yes, you might save a junior accountant some time, but in some industries, people simply don’t care about how much time junior staffers spend on doing manual tasks. In this case, you need to determine whether you can find 20-30 customers who are willing to pay for it. Remember that someone saying “oh that sounds like a good idea” is different from them reaching into their pockets and actually paying you money.
• Does design matter for this product? A lot of B2B software is hideously ugly. It isn’t because good designers don’t exist, but because it simply isn’t a priority; the people who have to use the product might prefer a better design or an easier UX, but the decision-makers don’t care, and the users don’t get a say. In other words: Don’t spend half your development budget on making something easier to use, if you can’t find a business case for it. Especially if it turns out that you inadvertently end up developing the wrong featureset in the process.
• Will an incumbent copy us and destroy us? If you have a number of incumbents in your space, do some research and see how they have reacted to other startups. If they tend to acquire them, great. If they tend to copy their features and innovations and then crush them, less great. A little bit of Googling (and, of course, reading TechCrunch for your industry) can save you a lot of headaches in the future. If the incumbents are routinely stealing innovations, invest more in patents and set some money aside for lawyers.
• Does this feature make sense to our customers? It may be that you get a very loud minority of your customers asking for the same feature, but you wouldn’t be the first company to have launched a new feature to great fanfare only to be met by a collective shrug. Loud customers don’t speak for your whole customer base, so be judicious in how you groom your backlog — if a feature doesn’t add significant value to the overall business objectives of your company, don’t prioritize it over ones that do. One way to design an MVP around this is to just add a button to your UI and track how many people click on it. Throw up a “coming soon!” message when it is clicked, for example. Yes, it is annoying to the users, but it’s a lot “cheaper” than spending several development cycles adding a feature that almost nobody will use.

The key is to think carefully about what the question is, and then come up with elegant, low-lift ways of asking it. Could a survey work without shipping code? Could a video demo give you the answers you need? Can you call 50 customers and ask them questions to see if they suggest a solution to the problem? They might surprise you in two ways, one being that your customers may either overwhelmingly want what you're suggesting or they may hate it.

I don't have a suggestion for a better name for it, just don't fall into the trap of thinking of it as a product, being viable or simple. There are some things that are complex. To get an answer to your questions, you should spend as little of your resources as possible.