Why Start With The First Usable Version of Your Product, Instead of the Best Version

There are many possible approaches to launch a new product, and just as many obstacles along the way. However, there's a way of assessing the chances of success before diving in full commitment, and that's where the Minimum Viable Product (MVP) comes in.

If you just want to show people the first version of your product or you want to get an understanding of whether your business idea solves a real problem, creating a MVP is the way to go. It allows you to avoid unwanted scenarios such as wasting time and money, and you'll surely save months of effort moving in the wrong direction.

But what is really a MVP? It's a concept so widely used, and yet, so hard to get right. Let's start by stating what it is not. It's not a prototype, nor is it a pre-launch version of a product. It's not a beta version of any sorts, and it doesn't precede the real product. In software development, it's also not the most valuable player, which has the same initialism, but it's used in completely different areas.

A MVP is a software development technique, first used by the American entrepreneur Eric Ries, that assures a first working version of the product, with all the needed requirements to make it fulfil its main goal. It's valuable for users as it is, and has much room for improvement through a set of features that are not considered for the initial version, but can be implemented in a later stage.

But why shouldn't you go straight to the best possible version of your product?

The benefits of building a MVP

The main goal of the MVP is to test the market and get feedback for further product improvement. Knowing that the effort to build a MVP is much less than what would be needed to implement all the initially contemplated features, all outcomes are positive, even in worst case scenarios.

If users adopt the product right away at this stage, you'll create a community around it and get room for further improvement with less pressure. At the same time, those same users will be the ones pointing out what they think the product is lacking, providing valuable input for the next round of improvements. You can then plan accordingly and even scratch a few features that were thought before launching the MVP, in some cases.

In the undesirable scenario in which the product isn't adopted, or fails to serve its purpose, it'll still provide valuable insight to either adapt or drop the product, according to the gathered feedback. Maybe it was a UI or UX issue or maybe the problem that the product was supposed to solve was misjudged. Additionally, there are also external factors that influence the outcome of a product launch. With so much that can possibly go wrong, there's no reason not to play it safe from the start.

In any of the above cases, building a MVP proves to be the best pick. It can always depend on the available budget and on business goals, but nonetheless, the MVP is not a technique that should only be used for short budgets. Small startups do it as much as big corporations, and it's always more a question of strategy than it is of imposed constraints.

But how does one start to build a MVP?

Designing a Minimum Viable Product

It all starts with design. Going directly from the idea to implementation with minimum effort on design usually proves to be a very bad idea, regardless of the project nature. It's not as you can just get someone to paint a nice layer on top of the prototype once it's ready and call that the “design”.

When you work with product designers, you’ll understand that they're more like architects than painters. They need support from engineers in order to design, but the most creative part of their job isn't what the product will look like, but rather what it should do and why. And until actual users use the product, everybody's working with assumptions (some might just have more accurate assumptions than others).

With this in mind, we can try to answer the question: should a MVP be fast and easy to put through a reality check? If you have the team capable of delivering it in three days, why do more? If the idea proves to be welcomed by people, then you'll have confidence and full trust to invest in 3 months of effort and cash.

After that, you need money to continue growing to the full product, each time increasing the user base and not just sitting in your office hypothesising. At the same time, the product designer will be able to observe, analyse and interpret the evidence you gather from the reality check to help you invest your time and money wisely.

If you think that it's impossible to test your idea in 3 days, you are wrong. What you need is not a fully functional product, but simply a proof that your idea will drive some interest, which is something that can be achieved with a fraction of what you think your product should do.

Secondly, no matter how genius your idea is, its implementation needs to be preceded and managed by a real product designer. Good design will help you remove the fat of the idea, understand the core of your value proposition and deliver an elegant solution to test it faster.

Remember: more design means less development, and that's usually the focus of the MVP. It's not about stacking features on top of each other, but concentrating the efforts on what really matters to release a working product that'll fulfil a specific goal.

How to properly plan a MVP

There are many ways to plan a MVP project, but here I'll focus on a specific methodology: Scrum, which is depicted below.

The concept was introduced by Hirotaka Takeuchi and Ikujiro Nonaka in the context of product development in 1986, and it has suffered several mutations in the following decades. Putting it simply, it's a process that aims to deliver small product iterations over time, instead of going through the whole product development in its final version before delivering any value. It is usually related to Agile development practices.

Let's now see how we can adapt it to building a MVP.

The product backlog and the task list, on the left side of the image presented before, represents the various features that you want to implement on your product. Those will be contemplated on several sprints that occur in fixed time frames afterwards. The conclusion of each sprint generates feedback that'll be used as input for the next round, and that'll happen as many times as needed to complete the project plan.

Imagine that the goal of the first sprint is to build a MVP. The product will be shipped as it is, and will get updated following the same process, according to established priorities in the project plan. The main benefit is the regular delivery of value within short time frames, and the chance to respond quickly to change.

Repeating this process will eventually lead to the project's conclusion, with several rounds of feedback in between. This is one the most important characteristics of a MVP. It enables you to have more checkpoints to go back to if anything goes wrong, and at the same time, you'll be rewarding users progressively over time with product improvements based on their needs.

This is just one of many possible routes to build a MVP and work from there, and the one that we take to develop digital products ourselves. It's based on an Agile mindset, in which the aim is to continuously deliver valuable software in increments. Other options are available, but the ideas that support the project will be very similar in every case. It's up to you to pick the one that best suits your needs.

In short

Are you looking forward to build a new product? List your business goals, think about the various strategies that'll enable you to get where you want to be and strongly consider taking the MVP route. The main benefits that come from it are the reduced risk and the feedback gathering, and both will enable you to better plan the following steps. It's not the consequence of having no other option, it's a business strategy by itself, and many successful businesses keep doing it as a way to test the market before going all in.

It all starts in design, as that's the most important step in building a MVP. Product designers will be able to trim the fat and keep the product to its essentials before moving on to development. The project plan doesn't, however, end in the MVP, as that's usually the first step in a much bigger process.

The bottom line is that you can always dream big, but you should start with both feet on the ground. A minimum viable product is a promise of something bigger and better, and dropping the project after its completion would be a mistake as severe as not releasing a MVP at all.

Based on an article written by Nicholas Mandelbaum for Imaginary Cloud.