Wat is een MVP (Minimum Viable Product) en waarom is het belangrijk?

Wat betekent MVP

Wie iets met startups doet of met agile werken komt deze term tegen: Minimum Viable Product (MVP). Maar, wat betekent dit nou precies? Hoe verhoudt een MVP zich tot bijvoorbeeld een “Proof of Concept”? En, wat is de context waarin je een MVP tegenkomt?

In dit artikel zoom ik in op alles dat met minimum viable products te maken heeft. Na het lezen van dit artikel kan je precies uitleggen wat een MVP is en wat niet.

Laten we beginnen!

Een minimum viable product

Kort samengevat is een minimum viable product een strategie waarbij je een nieuwe product of dienst net ver genoeg ontwikkelt om de eerste (betalende) gebruikers of klanten te ondersteunen.  Daarna ga je cyclisch feedback vragen aan je gebruikers en stap voor stap verder ontwikkelen.

Daarmee heeft de MVP een grote overlap met de principes van scrum methode en past erg goed binnen gedachtegoed rond agile werken en het agile manifesto.

Hoe weet je nu of jouw product of dienst een MVP is?

Er zijn een aantal eigenschappen waar een MVP aan zal voldoen

  1. Een MVP moet zo ver ontwikkeld zijn dat gebruikers het overwegen te gebruiken en kopers het overwegen te kopen.
  2. De MVP moet als een ruwe diamant gezien worden door de eerste gebruikers (early adopters). Zij moeten het potentieel erin zien richting de toekomst.
  3. Een MVP is gericht op doorontwikkeling met een terugkerende feedbackloop met de gebruikers of kopers. Heb je geen strategie eromheen? Dan heb je waarschijnlijk gewoon een heel middelmatig uitgewerkt product.

Het concept minimum viable product bestond al in verschillende vormen. Het werd (en wordt) ook wel eens een “compelling product offering” genoemd en je ziet ook behoorlijk veel elementen van het Kano Model (van professor Noriaki Kano) terug in een MVP strategie.

MVP is echter op dit moment veruit het bekendste en meest breed gedragen begrip. Dit komt omdat Eric Reis (serial ondernemer, startte onder andere met Elon Musk Paypal)) het concept van MVP als een belangrijk fundament gebruikte in zijn bestseller “The Lean Startup”.

MVP komt uit het boek "the lean startup"

Dit boek was in mijn tijd in Berlijn iets wat bij nagenoeg iedereen die iets met startups deed op het nachtkastje lag.

Ook de meeste Nederlandse founders die ik spreek hebben het boek gelezen.

Voordelen van het werken met een MVP

Waarom wil je jouw productontwikkeling volgens deze methode invulling geven? Er zijn een aantal concrete voordelen die zorgen voor snelheid en kostenbesparingen.

Het werken met een MVP kent de volgende voordelen:

  • Je ontwikkelt pragmatisch. Je ontwikkelt echt het minimale. Daarna ga je eens rustig kijken met je eerste gebruikers wat er verder nodig is en in welke volgorde.
  • Het scheelt ontwikkel capaciteit en dus geld. Je hebt simpelweg geen groot team nodig dat erg lang aan het bouwen is, maar omdat je het minimale bouwt, kost het je ook maar het minimale.
  • Het zorgt voor betrokkenheid. Je kan met een MVP betrokkenheid van je eerste gebruikers verwachten. Ze geven je feedback en commitment (vaak in ruil voor een korting). Wanneer je geluk hebt kan je ze inzetten als “product advocates”. Dat zijn mensen die jouw product enorm goed vinden en dat graag delen met anderen op eigen initiatief. 
  • Korte time-to-market. In plaats van iets bouwen wat “af” is kun je nu al relatief snel al jouw producten en diensten aanbieden. Zeker in de techwereld zijn er altijd 100 anderen die met hetzelfde idee bezig zijn. Snelheid is daarmee erg belangrijk.
  • Je kunt toetsen of er überhaupt een markt is voor je product. Wanneer je nog geen duidelijke klanten hebt, zie je met je MVP direct of er een markt is en zoja hoe groot naar verwachting.

Veel gemaakte fouten en misvattingen bij MVP’s

MVP lijkt op papier een redelijk recht toe recht aan concept. Toch zijn er een aantal veel voorkomende valkuilen die goed zijn om te benoemen.

Te veel functionaliteiten voor een MVP

Dit zorgt voor een langere time-to-market, meer ontwikkelbudget en je hebt het risico dat je dingen ontwikkelt waar niemand op zit te wachten (en die dus opnieuw moeten). Iemand zei me ooit: “als je je niet schaamt voor je MVP, dan ben je te laat”.

Te ver uitgewerkte functionaliteiten voor een MVP

Dit punt lijkt hetzelfde als het bovenstaande, maar dat is het niet. Je kan ook simpelweg te veel tijd besteden en moeite steken in belangrijke functionaliteiten. Dit wil je ook voorkomen. Ook de benodigde features moeten minimaal uitgewerkt zijn.

Een te groot ontwikkelteam

Het kan in sommige gevallen verleidelijk zijn om te starten met een groot team. Begin klein met 2-3 ontwikkelaars en betrek meer mensen wanneer je verder komt.

Te veel feedback

Het klinkt natuurlijk goed om veel feedback te krijgen. Toch is er ook zoiets als teveel feedback. Je kan niet aan iedereens wensen tegemoet komen en het iedereen 100% naar zijn zin maken. Focus daarom op de gelijke noemer in de ontvangen feedback. Als het goed is brengt dit je het dichtste bij een goede product-market fit.

Verkeerde context voor MVP’s

Als laatste, er zijn veel sectoren waar scrum, agile en ook MVP’s totaal niet passen. Deze wijze van productontwikkeling passen uitermate goed bij bijvoorbeeld softwareproducten. Er zijn echter voldoende concepten te verzinnen waar een MVP niet mogelijk is of niet wenselijk is.

In de ontwikkeling binnen de luchtvaart bijvoorbeeld. Daar zal een MVP aan zo veel voorwaarden moeten voldoen dat de features al erg dicht tegen een eindresultaat aan zullen zitten.

Je kan je voorstellen dat het bijvoorbeeld voor Boeing geen optie is om een aantal minimum viable vliegtuigen te verkopen aan een luchtvaartmaatschappij om vervolgens hun feedback te vragen.

En? Vliegt ie lekker?

MVP en een proof of concept (POC)

Een proof of concept (POC) en een MVP lijken op elkaar, maar zijn niet hetzelfde.

In de meeste gevallen zal je een POC uitvoeren voordat je aan je MVP gaat werken.

Het dient als doel om een toepassing van bijvoorbeeld een bepaalde technologie in een bepaalde context te laten zien aan (potentiële) klanten. Daarmee is een POC in principe niet toepasbaar in de praktijk of het dagdagelijkse.

Een MVP is dat nadrukkelijk wel.  Daarmee is een proof of concept kleiner en minder zwaar dan een MVP.

Voorbeelden van bedrijven met een geslaagde MVP-strategie

Airbnb

De oprichters van Airbnb startte met de verhuur van het appartementje van een van de oprichters als test. Zo kwamen ze erachter dat er ongelofelijk veel potentie in hun idee zat.

Amazon

Amazon begon natuurlijk niet zo groot en geavanceerd. Jeff Bezos verkocht boeken online en kocht deze boeken dan zelf in bij een lokale boekwinkel wanneer dit boek besteld was.

Facebook

Facebook startte als “The Facebook” als een online almanak voor studenten van Harvard University waar studenten elkaar konden bevrienden. Je kon er nog niet heel veel meer mee toendertijd. Het gaf het founding team wel voldoende informatie om verder te gaan ontwikkelen.

Goede planningssoftware kan je erg helpen

In veel gevallen zal je met het uitrollen van een MVP geholpen zijn met planningssoftware.

Monday biedt zulke software. Hun tooling helpt je met je projectmanagement (ook als scrum master of product owner) en het komt met een mooi Kanban bord.

Ik raad je aan het te proberen. Het werkt op basis van een freemium model dus het kost je in principe niets.

Een MVP klinkt als een open deur, maar is een krachtige methode

Natuurlijk zijn er veel meer voorbeelden te verzinnen van een geslaagde MVP-strategie. In veel gevallen klinkt een MVP-strategie ook wel een beetje als een open deur intrappen. Toch is het je in erg veel gevallen, zeker als startup, een hele slimme strategie.|

Ik heb er geen getallen bij, maar ik denk dat je zal schrikken van het aantal startende ondernemers dat een heel mooi bedrijf en prachtig product ontwikkeld om erachter te komen dat er nagenoeg niemand op zit te wachten.

Een van mijn favoriete business development strategieën heeft erg veel gelijkenissen met de MVP-strategie.

Heb je vragen of ideeën over jouw MVP-strategie? Laat dan gerust hieronder een berichtje achter!

Geef een antwoord

Het e-mailadres wordt niet gepubliceerd. Vereiste velden zijn gemarkeerd met *