Op deze pagina
Echte gebruikers, de ene taak, zo snel mogelijk
Met een MVP, voluit minimum viable product, leer je of je idee werkt voor je het volledige product bouwt. Geen klikmodel, geen presentatie: software met een login, echte gegevens en de ene taak waar het om draait. Alles wat die taak niet nodig heeft, wacht.
Het woord dat mensen vergeten, is viable: levensvatbaar. Een MVP is klein, maar niet half. De functies die erin zitten, werken goed genoeg dat iemand ze elke dag gebruikt. Pas dan zie je echt gedrag in plaats van beleefde meningen in een vergadering.
Frank Robinson in 2001, Eric Ries in 2011
De term komt van Frank Robinson en zijn adviesbureau SyncDev, dat hem in 2001 voor het eerst gebruikte. Robinson zocht het product dat het rendement op risico het grootst maakt, voor de leverancier en voor de klant: te klein en niemand koopt het, te groot en je bouwt maanden aan wat niemand vroeg. Steve Blank, die over klantontwikkeling schreef, gaf hem later expliciet de eer: Frank bedacht de term.
Bekend werd hij door Eric Ries. Op 3 augustus 2009 schreef Ries op zijn blog dat een MVP de versie van een nieuw product is waarmee een team het meeste leert over zijn klanten met de minste moeite. In zijn boek The Lean Startup, verschenen op 13 september 2011, werd de MVP de eerste stap van een lus: bouwen, meten, leren. Je bouwt het kleinste dat iets kan bewijzen, meet wat gebruikers doen, en beslist dan: doorgaan, bijsturen of stoppen.
Tien wensen, drie functies
Een schoonmaakbedrijf in Mechelen met 25 medewerkers (voorbeeld)
Later, als de eerste versie werkt
- Klantenportaal
- Facturen via Peppol
- Routes op een kaart
- Chat met kantoor
- Maandrapporten
- Beoordelingen door klanten
- Koppeling met de boekhouding
Daarna draait de lus
- Bouwen6 wekenAlleen de drie functies, maar wel echt: login, eigen gegevens, een beheerkant.
- Meten4 weken met 5 medewerkersHoeveel bellen er nog naar kantoor? Hoeveel planningen kloppen niet?
De MVP is niet de goedkoopste versie van het hele plan. Het is de kleinste versie die een echte vraag beantwoordt: werkt dit voor onze mensen?
Tien wensen, drie functies: een schoonmaakbedrijf
Stel: een schoonmaakbedrijf met 25 medewerkers plant alles in Excel en via WhatsApp. De zaakvoerder schrijft een lastenboek met tien wensen, van een weekplanning tot beoordelingen door klanten. Wie alles tegelijk bouwt, wacht maanden op iets dat misschien niet aanslaat bij de mensen die het moeten gebruiken.
De vraag die de scope beslist: welk probleem kost vandaag het meest? Hier is dat de planning. Elke ochtend bellen medewerkers naar kantoor om te vragen waar ze moeten zijn, en een ziekmelding zet de halve dag op zijn kop. De MVP krijgt dus drie functies: een weekplanning per klant en per medewerker, de dagplanning op de telefoon van elke medewerker, en een knop om afwezigheid te melden. Facturen, routes, een klantenportaal en rapporten wachten.
Wat het kost en oplevert, in tijd en geld. Stel dat de offerte voor alle tien functies op 60.000 euro uitkomt; dat is een rekenvoorbeeld, geen prijs van ons. De drie functies van de MVP, met login en beheerkant, zijn dan grofweg een derde van het werk. Ze staan in zes weken bij de eerste gebruikers, in plaats van na een half jaar. Belt de planner daarna zes uur per week minder, dan zie je binnen een maand of de rest van de lijst het geld waard is. Hoe je zo'n offerte leest, staat in wat software laten ontwikkelen kost; of een webapp of een app in de winkels past, in wat een app laten maken kost.
| Vorm | Prototype | Proof of concept | MVP | Volledige versie |
|---|---|---|---|---|
| Doel | Tonen hoe het eruitziet | Bewijzen dat het technisch kan | Leren of mensen het gebruiken | Het hele werk dragen |
| Wie gebruikt het | Jij en een paar testers | Het bouwteam | Echte gebruikers, een kleine groep | Iedereen |
| Met echte gegevens | Nee | Soms | Ja | Ja |
| Typische duur | Dagen | Een tot drie weken | Zes tot twaalf weken | Maanden, in fases |
| Wat je erna weet | Of het idee duidelijk is | Of de koppeling of techniek werkt | Of het idee waarde heeft | Wat de volgende fase moet zijn |
Vijf beslissingen voor de eerste versie
- Schrijf het probleem in een zinNiet de oplossing, het probleem: "medewerkers weten 's ochtends niet waar ze moeten zijn". Elke functie moet dat probleem kleiner maken.
- Kies de kleinste groep gebruikersVijf medewerkers, een team, een vestiging. Een kleine groep die het elke dag gebruikt, leert je meer dan honderd mensen die het een keer openen.
- Schrap tot het pijn doetBij elke wens de vraag: werkt de MVP zonder? Dan gaat hij naar de lijst voor later. Een export naar Excel volstaat vaak in plaats van rapporten.
- Spreek af wat je meetEen of twee getallen die voor de bouw al vastliggen: telefoontjes naar kantoor, fouten in de planning, uren van de planner. Zonder meting wordt elke MVP een mening.
- Plan de beslissingEen datum, vier weken na de start, waarop je beslist: doorgaan, bijsturen of stoppen. Dan pas komt de volgende functie op de lijst.
Klein is niet hetzelfde als slordig
Klein mag, slecht niet. Een MVP met fouten in de planning meet niet of het idee werkt, maar of mensen fouten verdragen. Login, beveiliging en back-ups horen er van dag een in, ook in de kleinste versie.
Waar het misloopt
De MVP wordt een proefproject dat nooit eindigt. Zonder afgesproken meting en beslisdatum blijft de eerste versie hangen. Spreek vooraf af wat goed genoeg is, net zoals je dat met een OKR zou doen, en reken het rendement na met echte uren.
De MVP wordt weggegooid. Wie de eerste versie bouwt met een speelgoedtool, begint na het succes opnieuw. Bouw de MVP op dezelfde basis als het product dat volgt, zodat je verder kan bouwen in plaats van te herbeginnen. Werk daarbij in korte rondes, zoals Scrum dat doet, en hou het gebruik eenvoudig: een goede UX beslist mee of je MVP gebruikt wordt.
De MVP is te groot. De meest gemaakte fout. Twijfel je of een functie erin moet, dan moet ze er niet in.
Een MVP is ook de logische start voor wie een product voor anderen wil verkopen, een SaaS. Moet de eerste versie op de telefoon van je medewerkers, dan is een PWA vaak sneller en goedkoper dan twee apps in de winkels.
Voor je de eerste versie laat bouwen
Hoe lang duurt het om een MVP te bouwen?
Voor een interne tool of een eenvoudige app meestal zes tot twaalf weken, als de scope echt klein blijft. Duurt het langer dan drie maanden, dan is het geen MVP meer maar een eerste versie van het hele plan.
Wat is het verschil tussen een MVP en een prototype?
Een prototype toont hoe iets eruit zal zien, vaak als klikmodel zonder echte gegevens. Een MVP werkt echt: mensen loggen in, voeren gegevens in en doen er hun werk mee. Daarom meet je bij een MVP gedrag, en bij een prototype alleen een eerste indruk.
Is een MVP alleen voor start-ups?
Nee. Een kmo die een interne tool laat bouwen, heeft er evenveel aan: je investeert eerst in het deel dat het meeste oplevert, en je team bepaalt mee wat er volgt. Het risico dat je maanden bouwt aan iets dat niemand gebruikt, wordt veel kleiner.
Wat betekent MVP buiten software?
In sport is het de most valuable player, de beste speler van een wedstrijd of seizoen. In software en ondernemen gaat het altijd over het minimum viable product.