What is an MVP - Minimum Viable Product?

We have often faced challenges in projects where we have had to balance budget, time and quality. In the projects where it fits, we work according to the model or mindset "MVP".

It then occurred to us that we could share our experiences and try to express them in a simple and accessible way.

MVP - Minimum Viable Product in the project

You have an idea for a new product. It can be a website, an application, a feature or a service that you believe can add value in the form of revenue, efficiency or customer satisfaction. Questions you ask yourself before starting the project are likely about:

• which features should I include (scope)

• how quickly can we be ready (time)

• how much will it cost (resources)
  
  

Does that apply to you? If so, MVP as a project approach can be a smart option.

MVP is an abbreviation of Minimum Viable Product, which in Swedish roughly means “minimum viable product”. It is a working version of a new solution that gives users sufficient value from day 1 when it is launched, even if it is not fully built.

Put simply, you take the core of the product—the part you know it absolutely cannot do without—and build a testable or production-ready product. The aim is to get to market quickly, learn more and make well-founded decisions about how it should be developed to add even more value.

Advantages of an MVP

A clear advantage of an MVP is that you can quickly get to market and receive feedback on the solution you've developed. Since it is a simple, stripped-down product with the minimum number of features required to function, you can be confident that you haven't wasted time and budget. Flip or flop? You get the answer before it's too late to change direction.

The MVP approach also works well when you're not entirely sure what the thing you're going to build should look like or how it should work.

What characterizes an MVP is that it:

• initially provides enough value for users to want to use or buy it.

• demonstrates forthcoming benefits to help retain early users.

• creates a feedback loop that guides the team forward in development.
  
  

By not taking too big a bite of the project, you avoid getting bogged down in details and can instead make the right decisions faster to move forward.

Another advantage of an MVP is that it's easier to change course if it turns out you were mistaken. You could say we get the chance to have the benefit of hindsight right from the start.

Users experience the positive aspects of the product — even though it's stripped down, it has precisely the features that provide utility. They don't have to wait ages for a fully developed product but can enjoy and use it continuously.

To illustrate the difference between an MVP project and a traditional waterfall project, you can compare it to making a baked good. 

What are the benefits for users?

Users experience the positive side of the product - even though it's pared down it has exactly the features that add some value. They don't have to wait ages for a fully fledged product but can like and use it as it evolves To illustrate the difference between an MVP project and a traditional project using the waterfall method, you can compare it to creating a baked good.

What the illustration shows is that customers/users do not see any value in a well-built platform being in place by itself if it is not packaged and usable. The baked good feels lacking if there is only a base.

Users, on the other hand, perceive the product as a real product if it has the most important functions, usability and appearance. The nice thing is that they can also give feedback and input on what they want the final result to be.

When should you work with an MVP?

If you've read this far you might be thinking "but why doesn't everyone always work like that?" The answer is that it should be done more often, but an MVP is not suitable for all types of projects. What matters is the amount of uncertainty when you start the project.

If you know what to build, how to build it and have done similar things before, an MVP can be directly inappropriate. In that case it may be better to reuse and combine well‑proven solutions and lay out a more detailed project plan that focuses more on efficiency than flexibility.

This can be a website with a CMS that we know inside out, which forms the basis of the project. We often have a rough idea of what content should be presented and we will be working against external systems that we usually cannot change much within the scope of the project. We therefore have a relatively low degree of uncertainty regarding the product we are going to build.

If, however, we have a project where we are going to build an entirely new digital service (perhaps the first in its market) with a long wish list of features, an MVP would be an excellent idea.

On the one hand, we need to know more about which of all the features are actually in demand by users; on the other hand, we do not have all the solutions and interfaces worked out from the start because no one has built anything similar before.

MVP projects and an agile way of working – how we balance scope, time and budget

MVP projects are by definition flexible/agile, which means that together with you we will want to experiment with the three project dimensions: scope, time and resources as the project progresses.

One effect of working with an MVP is that it is impossible to deliver a fixed functional specification in advance for a fixed time and a fixed cost. What you do know, however, is that you will get a viable product, on time and within budget - and have money left to take the next step.

If you have worked on an agile project before you will recognize this because it is fundamental to the agile way of working. If you find this scary, or know that you must have certain functionality in place by a certain date, we will probably need to look at other ways to handle uncertainty in the project.

Guess and do or do and test?

The first reaction when people hear about an MVP is often: it feels uncertain, I don’t know what I will get. It’s a very short-sighted way to look at digital projects. The alternative would be to guess, turn the guesses into truths and then base the rest of the project on that without testing. You can certainly do that, but you have no idea whether users will like and use what you have built or not. Thus you also have no idea whether you will reach the project’s goals. That — if anything — is not knowing what you will get.

By reversing the order and doing before we maybe 100% know that it is right, we get feedback faster, have the ability to change course and hopefully generate value considerably faster than a traditional project can. The trick is not to do too much. Do a little at a time, but make sure each part adds value and benefit for the user.

Also read