Lean Startup Adventure, day 17: Understanding The Minimum Viable Product

In the previous post in this series, François described the Misocell pivot. In this post, I'll talk about what comes after the Problem-Solution fit: going public, and testing the product-market fit with a Minimum Viable Product (MVP).

What Is A Minimum Viable Product?

The first time Eric Ries talked about the MVP, he defined it like this:

"A Minimum Viable Product is that version of a new product which allows a team to collect the maximum amount of validated learning about customers with the least effort."

After a while, he rephrased it as:

"An MVP is the smallest thing you can build that lets you quickly make it around the Build/Measure/Learn loop."

But, as Ash Maurya says in one of his blog posts, we prefer to define the MVP as:

"The smallest thing you can build that delivers value to the customer".

So reduce your solution to something you can build in a few weeks. It must be:

• Minimum: Take out everything that it not crucial to the main use case. Yes, that means that your product will be barebones, and probably ugly. It's not a big deal, because if this product doesn't find the product-market fit, you'll have less to throw away.
• Viable: It is time to test pricing and customer base size. It is time to test the economical side of the business model. The MVP must prove that you can make a living with your solution.

Removing features from a product idea is easier said than done. It requires a mindset shift:

Differences With The demo

There is a great debate within the startup community about the MVP of Dropbox.

Actually, their MVP was a demo video: they cheated on all the features they presented (because those features were not developed yet), but got tons of registrations after the video spread through the internet.

Drew Houston from Dropbox summarized the impact of this video like this:

"It drove hundreds of thousands of people to the website. Our beta waiting list went from 5,000 people to 75,000 people literally overnight. It totally blew us away."

Here is the video:

But that was not a MVP, it was a demo.

• a demo is very useful, and cheap enough, to test the Problem-Solution fit
• an MVP is usually more expensive, and tests the Product-Market fit. Or, to put it otherwise, it answers the question: "Are people really willing to pay for what I've built?"

In the case of Dropbox, the MVP would have been too expensive to build without being sure that tons of people were willing to use their service. And they found out with this simple 3-minutes video that it was the case.

What's In The Misocell MVP?

The Misocell MVP should prove that we can develop what we described in the demo, and that the value it brings justifies a monthly registration. We assume that even an MVP can bring value to our users. That is why our features look that technical.

We reduce the features to a minimum: the ability to register, log in, and save the configuration of an admin dashboard in JSON (not with a fancy Graphical User Interface).

We restrict the perimeter to one paid plan. No free plans, but the first payment happens after a month of usage. That leaves us one more month to implement payment!

Of course, it must be a real product, so we have to do some hard work under the table to be able to connect to external datasources via API endpoints. We choose to only accept AWS API gateway endpoints at this stage.

According to what we have already developed during the demo (we'll reuse the landing page), and what's already inside ng-admin, here are the missing bricks to make this happen:

• As Peter, I can create an account so that I get a personalized dashboard
• As Peter, given I am logged in, I can add an API endpoint to connect to, and get a list in return.
• As Peter, given I add an AWS API Gateway endpoint, I do not want to setup the API mapping.
• As Peter, given I defined an endpoint, I want to be able to customize the CRUD.
• As Peter, I want to allow endpoints with restricted access.
• As Peter, I want to use my credit card to pay for my registration.

We open a Trello board to track the progress of the MVP implementation:

How Much Does It Cost?

A Minimum Viable Product requires a substantial investment - usually a couple dozen thousand euros at least. If it's cheaper than that, then your competitors will have no problem developing a similar product, and the service you're providing is probably too small to justify a payment. If it's much more expensive than that, you're taking too big a risk.

We choose to estimate the cost of our MVP using a well-known SCRUM practice, the Planning Poker. Developers gather to discuss each user story with the Product Owner, and estimate them with ideal man.days. They do so using cards, and estimate all at the same time, hence the name "Planning Poker".

This time, we take into account graphical design, and hosting. After a few hours of discussion, we come to the conclusion that our MVP will cost between 15k€ and 20k€ to develop. We know that the next iteration, which will bring a GUI for the admin panel definition, will probably double this cost. And each new REST connector we add (e.g. to connect to a Wordpress server, Google Anglytics, or a Trello board) will add a few more thousand euros.

All in all, the product with a real marketable value and a large user base will probably cost us at least 50k€.

Next Steps

The MVP scope is defined, now it's time to realize it. Since it's a digital product, most of the work is web development. We won't explain here how web development works, but rather skip directly to the end of our Misocell experiment, and of this blog post series, in the next installment.

Credits:

Thumbnail picture: flint stone mandala 2, by Jos van Wunnik