The use of a Minimum Viable Product


Are we going in the right direction?

The term 'Minimum Viable Product', once invented by Frank Robinson and developed by SyncDev, has become famous due to the popular books by Eric Ries about Lean Startup. The idea behind an MVP is that you develop a product or a piece of software that has just enough features to be usable. Not to immediately take it to market, but to scrutinise it and gather feedback.

Exactly this feedback can be used to make adjustments to a product or software at an early stage, even before it is published. Additionally, it helps you to focus on the strong components of the product and it eliminates the unnecessary parts, saving you time and money. This effectively prevents you from randomly developing a product no one is asking for; that supply is created without demand. That, so to speak, a spoon is made while people are looking for a fork.

Let's just start driving and see where we end up.

Increasingly often, however, we see that the MVP concept is being used as an excuse. It's become a way to quickly cut corners, not think properly about what it is you want to achieve due to which you don't spend sufficient time and energy on preparation. It has become a way to jump-start the beginning.

Product owners and project managers cut corners increasingly often, under the guise of: " Yes, but it's an MVP, so what's not entirely correct about it now, will be improved in a next iteration".

In many startups (but also at regular companies), there is often a pressure to start without people having a clear idea of the direction to be taken. Often, there is a 'WHAT' are we going to build and 'HOW', but the 'WHY' and 'FOR WHOM' is often covered with the cloak of an MVP. It is often the case that startups, with a lot of time and effort, launch a product/app that doesn't match the needs of the larger public.

The final destination doesn't have to be completely clear, but a global idea of the direction can already make a great deal of difference when working towards a product that is ready to be launched. The end result of this work method is therefore sometimes complete disinterest for the product, but sometimes a launch will go unexpectedly well. However, because the MVP process has received too little thought, after the launch, there is often no idea about continued developments, or people are confronted with limitations of a hastily chosen software platform, or worse.

What will you encounter on the way?

A good example of the value of the correct use of MVP is the mobile Internet bank Bunq. Even before their first customer had opened an account, they had the guts to change course no less than three times at Bunq. Hundreds of hours of source code were rewritten and sometimes, the entire development platform was replaced by something else.

Correctly making use of MVPs takes courage. It's not easy to just put aside hundreds of hours (read: money) worth of source code, enter into internal discussion and frustrations and subsequently move deadlines around before even making so much as 1 Euro.

The result was that, when their mobile Internet bank went live, they marketed a product (mobile banking) that couldn't be compared to any other existing product and was much faster and extensive than that of their current competition (such as ING, Rabobank, Triodos and Knab).

Are we there yet?

An MVP process is intended to improve upon the software. And to give you vision and basis in the continued development, because it often starts with part II of the process (where part I is working towards the launch).

Should you choose to develop a new product via the MVP method, always take the following points into consideration:

  • pay more attention to visualising the concept/product, the vision;
  • think about the 'Why' and 'For whom';
  • introduce a feedback loop as soon as possible and don't wait until the final iterations before going live;
  • an MVP is not a final product, but rather a measurement instrument and a canvas;
  • and last but not least: think about how you are going to design the continued development of your new product after going live.

We get inspired by curious people

Our goal is for people to Get Smarter Every Day. 

John van Beek

Get Smarter Every Day

How can we help you?
May Iquality store your contact information for future use?

Read more about our privacy statement.

Thank you for your message

We will get back to you as soon as possible.

Oops, something went wrong.

Sorry for the inconvenience. Please try again later.