MVPs – Why Developing the Bare Minimum Is the Right Strategy

The founder of LinkedIn, Reid Hoffman once famously said “If you are not embarrassed by the first version of your product, you’ve launched too late”. If you take this philosophy on board, your minimum viable product (MVP) may well be the toughest software release you ever do.

In a nutshell, your MVP includes the absolute minimum functionality you need to get your product in front of your customers.  Consider where LinkedIn is today, and now have a look at their MVP:

(Source: A Brief History of LinkedIn)

There are many reasons why an MVP approach is preferred in modern software development:

Early customer feedback

Feedback from the people that use your software is absolutely critical. Getting it in front of them early allows you to further develop your product around your customer’s actual needs, not just what you think they want. This helps to inform features and future development and lets you start building momentum immediately.

Quicker revenue stream

Nobody’s going to pay for something that they can’t use. The earlier you can get a piece of working software to market, the earlier you can start earning revenue. The process of finding out what people are willing to pay early on for will make your application better in the long-run.

Fail fast

Let’s not forget – most software projects fail in their first few years. If your business simply isn’t going to fly, better to find out earlier rather than later. 

Those are all good things, what about the bad things?

While early feedback is invaluable to businesses, users do like things to be finished. It’s important to remember that your customers don’t know what your overall vision for your product looks like. If you’re releasing a basic version of your vision instead of a half-finished final version then you’re probably on the right track – and your product will feel finished to your customers.

In short – make sure that every product release can stand alone as a complete product.

(Source: Making sense of MVP – and why I prefer Earliest Testable/Usable/Lovable)

But I don’t want to show my competitors what I’m doing

Some clients have told me that releasing an “unfinished” product will give potential competitors a whiff of what they’re trying to do. While I can’t comment on the ruthlessness or perceptiveness of your competitors, I will point out that first-mover advantage is of little use to you if you don’t have the funds to maintain momentum because you’ve blown your budget on your full-featured system and if you take too long you might not be the first to market anyway.

Can’t I just defer launching and include that next big feature that users will love?

People can struggle with this because they feel that a specific feature is a ‘showcase feature’ and sets their product apart. I advise clients to think long and hard about developing these sorts of features early. They are usually expensive to build and often your users will not find them as important or impressive as you expect. My overarching observation is simply this - every piece of functionality costs you money. Don’t build it until you know you need it.

Okay, so how do I get my Taj Mahal down to MVP?

Here are some practical examples that our clients have used in the past:

• Hold off developing complicated permissions models until you’ve got a clear idea of how they will work now and in the future. Better yet, decide whether your users even need to login.
• If your product has a back-end system which you use to populate a database (e.g. registering new products in your e-commerce system), you probably don’t need to build forms to manage it. Just ask your developer to insert the information directly into the database as required (usually a quick and simple job).
• Don’t build a system to serve 100,000 concurrent users if you’ve only got 100 to start with.
• If you’re planning a mobile app, think long and hard about whether your users require a separate iOS or Android app – consider building a web application which can be ported to app stores later.

By focusing on the basics and leaving the fancy features for later, you can get your product to market sooner than you think - and focus future development on what will add the most value for your customers.

Written by Ben Liebert, Icehouse Community Member and Founder of Blackball Software.

About Ben Liebert

Ben is the founder of Blackball Software, a bespoke software house in Auckland, New Zealand. He has been helping start-ups and businesses get their products to market successfully for more than a decade. You can subscribe to his free email series: How to know if your software developer is trying to kill you.