Een MVP bouwen in 2025 — stap voor stap naar je eerste echte gebruikers

Het woord "MVP" is zo breed geworden dat het bijna betekenisloos is. Sommigen bedoelen er een half-afgewerkt prototype mee vol bugs, waarvoor ze zich tegenover vroege gebruikers verontschuldigen. Anderen bedoelen een feature-compleet product waar alleen de mooie animaties nog ontbreken. Geen van beide definities is bruikbaar.

Een minimum viable product is een product dat één probleem volledig oplost — voor een specifieke gebruiker, in een specifieke situatie — en dat snel genoeg is te bouwen om te valideren of de aanname achter het probleem klopt voordat je diep in de kosten zit.

Dat klinkt eenvoudiger dan het is.

Waarom de meeste MVP's al mislukken voor ze worden gebouwd

Het fundamentele probleem bij MVP-trajecten is geen technisch probleem. Het is een definitieprobleem. Oprichters weten wat ze willen bouwen, maar ze zijn niet scherp over wat ze willen bewijzen.

Een MVP is een leerinstrument. De vraag die je erdoor wilt beantwoorden is: betalen echte mensen, in de echte wereld, voor de oplossing die ik bied? Alles in het product dat die vraag niet helpt beantwoorden, is geen investering — het is uitstelgedrag in productiedrag.

De meeste MVP's zijn te groot omdat oprichters de neiging hebben om hun volledige visie voor ogen te houden. Ze bouwen een platform in plaats van een tool. Ze bouwen voor tien gebruikersrollen in plaats van één. Ze bouwen de sociale functie voordat de corefunctie is bewezen. Het resultaat: een product dat acht maanden heeft gekost, €150.000 heeft gekost, en nog steeds niet bewijst wat het moest bewijzen.

Stap 1: Definieer de één core job to be done

De "jobs to be done"-theorie, geïntroduceerd door Clayton Christensen, stelt dat mensen producten niet kopen vanwege wat ze zijn, maar vanwege het werk dat ze daarmee gedaan willen krijgen. Mensen kopen geen boor — ze kopen een gat in de muur. Mensen gebruiken geen rittenapp — ze willen op tijd, zonder stress, op hun bestemming zijn.

Voor jouw MVP is de eerste stap het identificeren van de één kernvraag: welk concreet werk doet jouw gebruiker op dit moment, waarvoor heeft hij of zij geen goed gereedschap, en hoe lost jouw product dat op?

Schrijf dit op in één zin, in de taal van de gebruiker. Niet: "Ons platform ondersteunt workflowoptimalisatie voor HR-professionals." Maar: "Een HR-manager kan nu in vijf minuten zien welke medewerkers hun verplichte trainingen niet hebben afgerond, zonder tien systemen langs te hoeven."

Als je die zin niet kunt schrijven, weet je nog niet wat je bouwt.

Stap 2: Bepaal de minimale feature set

Gegeven de core job, welke functionaliteit is echt nodig om die job volledig te vervullen? Niet grotendeels, niet voor 80% — volledig. Een product dat een probleem half oplost, bewijst niets en wordt niet gebruikt.

Dit is de moeilijkste stap, omdat het discipline vereist om dingen weg te laten. Gebruik de volgende filter: "Als we deze feature weglaten, kunnen gebruikers de core job dan nog volledig doen?" Als het antwoord ja is, laat je de feature weg voor versie 1. Niet voor altijd — voor de eerste versie.

In de praktijk resulteert dit kader in een feature set die kleiner is dan founders verwachten. Dat is prima. Een kleiner, coherent product is beter dan een groter, versnipperd product.

Een concreet voorbeeld: een platform voor het beheer van leverancierscontracten. Core job: "Een inkoopmanager kan in dertig seconden zien welke contracten de komende negentig dagen aflopen en wat de verlengingswaarde is." De minimale feature set: contracten uploaden en opslaan, automatisch einddatum herkennen, een overzichtsscherm met de komende verloopdata. Dat is het. Geen workflowmodule, geen goedkeuringsprocess, geen leveranciersprofiel, geen API-integraties met ERP. Die komen in versie 2 — als versie 1 heeft bewezen dat mensen dit willen gebruiken.

Stap 3: Bouw het goed

Dit is het punt waarop de "minimum" in MVP gevaarlijk wordt. Minimum verwijst naar de scope — niet naar de kwaliteit. Een MVP die traag is, vol bugs zit, of een gebruikerservaring heeft die mensen niet begrijpen, bewijst niets. Als niemand het product gebruikt, weet je niet of het concept niet deugt of dat de uitvoering niet deugt. Je hebt niets geleerd.

UX is niet optioneel. De gebruikerservaring hoeft niet bijzonder te zijn — maar ze moet helder zijn. Gebruikers moeten zonder uitleg begrijpen wat ze moeten doen. Dat vereist een designfase, hoe kort ook.

Betrouwbaarheid is niet optioneel. Als het systeem crasht bij de eerste echte dataset, of als een bekende workflow een foutmelding geeft, dan verlies je het vertrouwen van je vroege gebruikers — de meest waardevolle feedback die je kunt krijgen.

Analytics zijn niet optioneel. Als je niet kunt meten hoe gebruikers het product gebruiken — waar ze afhaken, welke functies ze wel en niet gebruiken, hoe lang ze actief zijn — kun je niet leren. Bouw van dag één basis-analytics in. Gebruik PostHog of Mixpanel. Stel events in voor de acties die tellen.

Stap 4: Zet het snel voor echte gebruikers

Een MVP dat in een la blijft liggen totdat het "klaar" is, is geen MVP — het is een prototype. De waarde van een MVP zit in de feedback van echte gebruikers in een echte context.

"Klaar genoeg om te lanceren" betekent: de core job kan volledig worden vervuld, het product crasht niet bij normaal gebruik, en je kunt meten hoe het wordt gebruikt. Dat is de standaard, niet meer.

Ga actief op zoek naar je eerste tien tot twintig gebruikers. Niet willekeurige mensen — mensen die het probleem herkennen dat jij oplost, die bereid zijn feedback te geven, en van wie je het gebruik kunt observeren. De meest waardevolle eerste gebruikers zijn mensen die het probleem zo acuut voelen dat ze het product willen gebruiken ook al is het imperfect.

Praat met ze. Kijk over hun schouder mee als ze het gebruiken. Luister naar de vragen die ze stellen en de momenten waarop ze aarzelen. Dat is je productbacklog voor versie 2.

Tijdlijn en kosten

Een realistisch MVP-traject neemt acht tot zestien weken in beslag met een capabel team. De grote variabele is de complexiteit van de core job en het aantal integraties dat noodzakelijk is.

Acht weken is haalbaar voor een product met een heldere scope, geen externe integraties, en een opdrachtgever die snel beslissingen kan nemen. Zestien weken is realistischer voor een product dat integraties vereist met bestaande systemen, meerdere gebruikersrollen heeft, of waarbij de requirements in de loop van de discovery-fase nog worden aangescherpt.

Kosten lopen doorgaans tussen €30.000 en €100.000. De onderkant is voor eenvoudige producten met beperkte backend-logica. De bovenkant voor producten met complexere datamodellen, meerdere integraties, of native mobiele ondersteuning naast web.

Goedkoper dan €30.000 is mogelijk, maar dan lever je in op snelheid, kwaliteit of scope op een manier die de leerwaarde van het MVP ondermijnt. Goedkoper dan €20.000 resulteert bijna altijd in een prototype dat je niet kunt gebruiken om echte validatie te halen.

Wanneer is een MVP goed genoeg om te lanceren?

De check bestaat uit vier vragen:

Kan een gebruiker de core job volledig doen zonder hulp van jou? Als je elke gebruiker moet begeleiden, is het product niet af.

Werkt het product betrouwbaar bij normaal gebruik? Niet: werkt het als alles goed gaat. Werkt het ook als iemand een onverwachte invoer doet, een stap overslaat, of via een ander apparaat inlogt.

Heb je analytics die je vertellen wat gebruikers doen? Lanceren zonder meten is verspild leren.

Heb je tien mensen bereid gevonden om het te gebruiken, die het probleem herkennen? Als je dat niet kunt, is het marketingprobleem, niet het productprobleem, dat als eerste aandacht verdient.

Een MVP is het begin van een gesprek met de markt. Het is geen eindproduct en het is geen vrijbrief voor slordig werk. Het is het minimale dat je kunt leveren om te bewijzen dat je op het goede spoor zit — en te ontdekken in welke richting je verder moet bouwen.

De bedrijven die daar succesvol mee zijn, kenmerken zich niet door betere technologie of meer budget. Ze kenmerken zich door discipline: de discipline om te definiëren wat ze willen leren, en om alles te schrappen dat niet bijdraagt aan dat leren.