Minimum viable product: your first customer already is the MVP

You'll be told that a minimum viable product is the smallest version of your product.

That isn't a lie. But it falls short.

And because it falls short, a lot of people build an MVP that teaches them nothing.

What is a minimum viable product?

The term was popularised by Eric Ries in The Lean Startup. The idea is simple: instead of building the whole product and crossing your fingers, you build just enough to learn whether anyone wants it.

Notice the important word. It isn't "minimum".

It's learn.

An MVP isn't a cheap product. It's a question you ask the market with as little work as possible.

And only one answer counts: someone uses it. Better still: someone pays for it.

Think of it as a question, not a cut-down version

The usual way to make an MVP goes like this: you write a list of features, cross out half of them and launch what's left.

That's your product with fewer things in it. Which isn't the same.

The useful question isn't "which features do I cut?". It's this:

What am I most afraid isn't true?

That people have the problem? That they'll pay to solve it? That they'll use it every week, and not just on day one?

The MVP is the fastest way to find out. Sometimes it's software. Sometimes it's a spreadsheet. Sometimes it's you, doing it by hand.

Our MVP was a form

PagoCRM, our software that helps sports clubs collect membership fees, wasn't born as software for clubs.

It was born as a form for the parents at a football club. A client project. One client with one very specific problem: collecting from families without chasing them one by one.

We didn't call it an MVP. We didn't even know we were building one.

But it was one: the least we could build to solve a real problem, for someone who was paying for it.

Then an athletics club came along with the same problem. And that changed everything. Because one client is a project.

The second one is a product.

How to build a minimum viable product without starting a startup

1. Start with a problem someone already pays you to solve. If you're already being paid, half the validation is done.
2. Write down the riskiest assumption in one sentence. For example: "Clubs would pay to stop chasing membership fees."
3. Build just enough to test it. If you can do it with a tool that already exists, even better.
4. Put it in the hands of someone real. Not your cousin. Someone who has the problem.
5. Watch what they do, not what they say. Compliments don't pay invoices. Usage does.
6. Find the second customer. They're the one who tells you whether you have a product or a favour.

MVP vs prototype

A prototype shows what it would be like. An MVP tests whether anyone actually uses it.

A prototype gets looked at. An MVP gets used.

And, if possible, paid for.

Minimum viable product examples

• Dropbox showed in a video how the product would work before it was finished. What it measured was how many people signed up to try it.
• Zappos started selling shoes online without a warehouse: its founder photographed shoes in shops and, if someone bought a pair, went and bought them himself.
• PagoCRM started as a form for football parents, paid for by a club that needed to collect fees.

None of the three was pretty. All three answered a question.

What really matters

The MVP isn't a project phase. It's a way of thinking: before you build a lot, prove a little.

Don't build to launch. Build to learn. And if you can, get paid while you learn.

If you come from client work, you have an advantage. Every project can be an MVP that someone is already paying for.

You just have to look at it that way.

P.S. I wrote more about that moment in the second club is when a project becomes a product.