06 november 2019
We are happy to deliver MVPs: 'Minimal Viable Product', the minimum workable product. In other words a very early version of the end product with minimal functionalities, or actually the foundation of your product. It’s an important part of working agile with sprints which is how we like to work.
An MVP from Uber, for example, was that customers could call taxi drivers and make the payment. Other less important functionalities will be added later. After Uber had gathered enough feedback from users, many more functions were added such as live tracking of drivers, sharing of taxi bills and estimates of the costs of taxi journeys.
That way you already have a tangible product that you can test yourself, and you can certainly give to the users to use. Give the users the opportunity to give feedback and don’t forget to use that feedback too! We then ensure that we regularly add new updates (after a new 'sprint'), so that more functionalities become available.
In the agile project approach, you are very flexible in developing a project. You work with various 'sprints'. This is a short predefined period (usually around 2 weeks) in which we start to develop something. After a number of sprints, there will be an MVP: a Minimal Viable Product. A workable basic product with limited functionalities.
You can test an MVP yourself and launch it directly to (a limited group of) users. Usually, when you see such a first version of such a product you get certain ideas about, which features are important first. With such an MVP you get much more feeling with the product that is being developed. And most importantly you get feedback that you can use to develop a better product.
With non-agile ways of tackling projects, it’s customary that you fully determine in advance what the end product should be. Then you can only use and test it when it’s (almost) finished. Often you will notice that certain things that you had thought about beforehand might not work that well. And maybe everything has to be converted.
When you’ve determined what the next steps are in the following sprints, the developers can continue. After another one or more sprints, you have new features that have been added to the product. In the meantime, you collect the feedback and determine the further timeline and functionalities.
The benefits of an MVP at a glance:
When you have an idea you are often very enthusiastic about all kinds of things that really need to be part of the product. The purpose of an MVP is to look at which things are absolutely essential. Separating the must-haves and the nice-to-haves.
To find out what needs to be in the MVP, it’s wise to start a conversation with the users: which things they need as a minimum to be able and willing to use the product.
It’s important to figure out what problem your product solves for the user. After this, it’s easier to get to the core of what must be in the MVP. Divide the desired features into various groups: things that are absolutely necessary, things that would be nice but do not block use, and things that are fun but can be implemented later on or maybe even left out after all. Make sure that the first list, in particular, is very short, so that you get to the core of your product the quickest.
Try to get a limited group of people to get started with the product. For example, you can filter them on location (Uber first only started in San Francisco, for example) or perhaps you have a loyal group of fans who already provide you with feedback that you would like to help. Collect the feedback and above all: do something with that valuable feedback.