Een minimum viable product (MVP) is de eerste versie van een product met precies genoeg functies om er in de praktijk mee te kunnen werken. Bij software betekent dat één proces van begin tot eind, met inloggen en rechten eromheen, en zonder de functies die pas later nodig zijn.
Hieronder staat wat de term betekent, wat er in een eerste versie hoort, hoe een MVP zich verhoudt tot een prototype en een proof of concept, en waar het in de praktijk op stukloopt.
Minimum viable product: de betekenis in het Nederlands
Minimum viable product wordt in het Nederlands meestal vertaald als minimaal werkbaar product. Beide woorden doen werk. Minimum gaat over de omvang, dus zo klein als het kan. Viable betekent levensvatbaar en gaat over de eis dat iemand er echt mee kan werken.
Een MVP is daarmee af voor het stuk dat hij dekt. Een applicatie die halverwege blijft steken valt erbuiten, ook al is die klein. Het inloggen werkt, de gegevens worden goed opgeslagen en het proces loopt van begin tot eind door.
In gesprekken hoor je ook "basisversie", "fase 1" of "eerste oplevering". Dat is hetzelfde idee met een andere naam.
MVP-software: wat er wel en niet in zit
Bij software gaat de keuze over het aantal schermen, het aantal rollen en het aantal koppelingen. Dit hoort er wel in.
Het proces dat nu het meeste tijd kost, van de eerste stap tot de laatste.
Inloggen, gebruikers en rechten, want die raken later vrijwel elk scherm.
De gegevens die je voor dat proces nodig hebt, met een opzet die kan meegroeien.
Eén koppeling, als het proces afhangt van gegevens uit een ander systeem.
En dit kan wachten.
Rapportages die je nu ook nog in een spreadsheet maakt.
Uitzonderingen die een paar keer per jaar langskomen.
Een tweede taal of een tweede vestiging waar nog niemand mee werkt.
Schermen voor rollen die de applicatie in het begin niet gebruiken.
De grens tussen de twee lijstjes is een gesprek en geen regel. Een uitzondering die twee keer per jaar voorkomt maar wel om een handmatige omweg vraagt, hoort er soms toch in.
Het verschil tussen een MVP, een prototype en een proof of concept
De drie woorden worden door elkaar gebruikt, terwijl ze verschillende vragen beantwoorden.
Een prototype gaat over de vorm. Meestal klikbaar, zonder database erachter, bedoeld om een idee te toetsen bij je team of bij een investeerder. Je gooit het daarna weg.
Een proof of concept gaat over de techniek. Kan die koppeling met het oude systeem de gegevens leveren, is die berekening snel genoeg, werkt die aanpak op deze hoeveelheid data. Je bouwt het kleinste ding dat die vraag beantwoordt.
Een MVP gaat over het gebruik. Er zitten echte gegevens in, mensen werken er dagelijks mee, en er hangt hosting en onderhoud aan. Wat we in een technisch ontwerp vastleggen voordat de bouw begint, is bij een MVP daarom uitgebreider dan bij een prototype.
Hoe je bepaalt wat de eerste versie moet doen
Begin bij het proces dat nu het meeste tijd kost of het vaakst fout gaat. Loop daarna deze vier vragen langs.
Wie doet welke stap, en welke stap kost het meeste tijd?
Welke gegevens gaan van hand tot hand, en waar worden ze overgetypt?
Wat gebeurt er nu als iemand een fout maakt, en hoe merk je dat?
Wat wil je over drie maanden kunnen aflezen om te weten of het werkt?
Soms blijkt bij die vierde vraag dat een stap helemaal kan verdwijnen. Dan hoeft die ook niet in software. Hoe je bedrijfsprocessen automatiseren aanpakt zonder een slecht proces sneller fout te laten gaan, hoort bij dezelfde afweging.
Waar het in de praktijk op stukloopt
Vier dingen zien we vaker terugkomen dan de rest.
De omvang groeit tijdens de bouw. Elke week komt er een functie bij die "er toch ook nog even in moet", en na drie maanden is het geen eerste versie meer.
Kwaliteit inleveren op de basis. Een MVP mag klein zijn, maar niet slordig: inloggen, rechten en de opslag van gegevens bouw je achteraf niet los in.
Niets meten. Zonder afspraak vooraf blijft de vraag of het geslaagd is een kwestie van gevoel.
Te klein om te gebruiken. Wie het proces niet van begin tot eind kan doorlopen, valt terug op de oude manier en dan levert de eerste versie geen informatie op.
Van eerste versie naar tweede versie
Zodra de eerste versie in gebruik is, komen de echte wensen boven. Wij bouwen in sprints en leveren elke twee weken een deel op, ook in die tweede fase. Door de ontwikkeling in fases op te delen houd je zicht op de kosten, en stopt het project op elk moment met een applicatie die werkt.
Bij ons kun je een MVP laten maken vanaf ⬠8.000 exclusief btw, voor één proces met één type gebruiker. Bij maatwerk software met meerdere rollen en koppelingen loopt dat op naar ⬠30.000 en hoger.
Veelgestelde vragen
Wat betekent MVP in het Nederlands?
MVP staat voor minimum viable product. In het Nederlands wordt het meestal vertaald als minimaal werkbaar product: de kleinste versie waarmee iemand het werk echt kan doen.
Het woord viable betekent levensvatbaar. Daar zit de eis in dat de eerste versie in de praktijk bruikbaar is, en dus niet alleen een demo.
Is een MVP hetzelfde als een prototype?
Nee. Een prototype laat zien hoe iets zou kunnen werken en gaat daarna de prullenbak in. Een MVP staat in productie, met echte gegevens en echte gebruikers, en groeit door naar een volgende versie.
Een proof of concept zit er nog voor: die toetst of iets technisch kan, bijvoorbeeld of een koppeling met een oud systeem de gegevens wel levert.
Wat komt er na een MVP?
Een tweede ontwikkelfase, op basis van wat het gebruik heeft opgeleverd. Gebruikers merken binnen een paar weken welke stap nog handmatig gaat en welk overzicht ze missen, en die wensen zijn concreter dan wat je vooraf kunt bedenken.
Wat je in die fase oppakt, is een keuze tussen tijdwinst en risico. Een stap die tien mensen dagelijks doen weegt zwaarder dan een uitzondering die een paar keer per jaar voorkomt.
Hoe weet je of een MVP geslaagd is?
Door voor de bouw af te spreken wat je gaat meten. Bijvoorbeeld hoeveel tijd een order kost, hoeveel fouten er per week uit het proces komen of hoeveel vragen je support binnenkrijgt over de status van een levering.
Zonder zo'n afspraak wordt de vraag na oplevering een kwestie van gevoel, en dan wint degene die het hardst roept dat er functies missen.
