Minimum Viable Product

The Minimum Viable Product

“Real artists ship.” –Steve Jobs

“If you’re not embarrassed when you ship your first version you waited too long.” –Matt Mullenweg

You’ve probably heard of an MVP, it stands for Minimum Viable Product.
The term was popularized by Eric Ries, It means that you should ship when you reach minimum viability, not a moment before or after that.
You shouldn’t take MVP to mean that you should ship a piece of crap. The emphasis in MVP is on viable, not on minimum.

Don’t spend a year building the next Facebook in a vacuum, you’re going to come out to find that no one wants what you are building. It would be better to build a simple messaging system in 3 months, get people using it, and see where you can take it from there.
Look at all these features I'll never use
Many successful startups started out as something completely different. Instagram started as a social app called Burbn, Groupon started as a crowd-funding platform, and Twitter started as a podcast network called Odeo.
Don’t fall so in love with your idea that you are unwilling to change direction. Build an MVP and be ready to adjust until you reach product/market fit, even if that means killing your original idea.
I’ve found that a 3 month development and release cycle gives you plenty of time to build a core product. This is obviously flexible, but you shouldn’t need a year to release your first version.
The longer you take to release, you burn money without knowing if you are really building something people want.

“Usage is like oxygen for ideas.” –Matt Mullenweg

How do you know when you’ve reached minimum viability?

So what’s the minimum you need to launch? We suggest startups think about what they plan to do, identify a core that’s both (a) useful on its own and (b) something that can be incrementally expanded into the whole project, and then get that done as soon as possible. – Paul Graham

An MVP solves the core customer problem as simply as possible, without anything extra.
It’s hard to say when exactly this happens, and it varies from product to product. If you set a hard release date, say 3 months from inception, then you have your answer. MVP is whatever gets done in 3 months.
If you’ve solved your core problem, then you’re ready to ship. You’ll know pretty quickly after shipping what features people really need, because you’ll hear it multiple times per day. You don’t even need to keep a spreadsheet of feature requests, because you’ll be so sick of hearing about those 3 features your product is missing you won’t be able to think about anything else.

After the MVP

After launching your MVP, you’ll get a lot of feature requests.
If sales are slow, it’s tempting to just build in every little thing, since you have the time. Building features is good, but take your time. Plan out each feature, with future maintainability in mind.
Each feature adds code debt that you have to keep paying interest on later. More features = more code maintenance, more bugs, and more support. Hastily adding a feature just because it’s “easy” right now can be problematic later.
That’s not to say you shouldn’t add features, just plan ahead.

Ship it

The important part about an MVP is that you don’t sit around and think it to death.
Releasing something for people to use is how you find out what you did right, and what you did wrong. You can debate with your team all day long about what will work best, but the only thing that matters is what people who pay you think.
The only way to get that type of feedback is to ship.


Posted

in

by

Tags: