De MVP-mythe: waarom testen slimmer is dan bouwen

De MVP is het meest misbruikte begrip in de startupwereld. Wat ooit bedoeld was als het kleinste experiment om een aanname te testen, is verworden tot een excuus om tóch maandenlang te bouwen: “het is maar een MVP”. Een MVP (minimum viable product, een eerste werkende versie die net genoeg doet om de kernbelofte te testen) is geen mini-versie van je droomproduct. Het is een meetinstrument. En vaak heb je niet eens een instrument nodig, maar gewoon een gesprek.

Dit artikel ontleedt de MVP-mythe: waarom founders te vroeg bouwen, wat je kunt testen zónder te bouwen, en wanneer een MVP wél de juiste stap is.

De mythe: bouwen voelt als vooruitgang

De redenering klinkt logisch: “we weten pas of mensen het willen als ze het kunnen gebruiken, dus we bouwen snel iets.” Maar er zit een denkfout in. De vraag in de vroegste fase is niet of mensen je product willen gebruiken, maar of het probleem groot genoeg is dat ze een oplossing zoeken. Die vraag beantwoord je niet met code, maar met bewijs uit de markt.

Bouwen is bovendien verleidelijk om de verkeerde reden. Code voelt als vooruitgang: je ziet elke dag iets groeien. Praten met twintig potentiële klanten voelt als stilstand, terwijl het je in twee weken meer leert dan drie maanden bouwen. Founders vluchten in de bouw omdat het comfortabel is, niet omdat het slim is.

De rekening komt later. Elke week bouwen aan een onbewezen aanname is een week die je moet afschrijven als de aanname sneuvelt. En de aanname sneuvelt vaak: niet omdat het product slecht is, maar omdat het probleem te klein bleek. Daarom begint alles bij een scherpe probleemstelling; hoe je die schrijft, staat in een scherpe probleemstelling schrijven.

De haas en de schildpad

Er zijn twee soorten founders. De haas sprint meteen naar de bouw: binnen een maand staat er een product, binnen drie maanden een half platform. Indrukwekkend tempo, maar gebouwd op ongeteste aannames. Als na de lancering blijkt dat het probleem anders in elkaar zit, moet de haas terug naar start, met een lege kas en een product dat niemand vroeg.

De schildpad doet het omgekeerde: kleine stapjes, en bij elke stap eerst bewijs. Eerst gesprekken die het probleem bevestigen. Dan een test die betalingsbereidheid aantoont. Dan pas een eerste bouwsel, zo klein mogelijk. Het oogt traag, maar de schildpad hoeft nooit terug naar start, want elke stap staat op bewijs. Over de hele race is de schildpad sneller, omdat de haas zijn tempo verliest aan omwegen.

De les is niet “bouw nooit”, maar “verdien elke bouwstap met bewijs”. Hoe je die bewijsstappen achter elkaar zet, lees je in de validation-driven approach.

Wat je test zonder te bouwen

Vrijwel elke aanname die founders “met een MVP” willen testen, kan eerder, sneller en goedkoper zonder code.

Het probleem: gesprekken. Twintig goede interviews met mensen uit je doelgroep vertellen je of het probleem echt, frequent en pijnlijk is. Hoe je die gesprekken voert zonder jezelf voor de gek te houden, staat in klantonderzoek voor startups.

De interesse: een landingspagina. Eén pagina die je oplossing belooft, met een knop “meld je aan”. Stuur er gericht bezoekers naartoe en meet wie zich aanmeldt. Je test de belofte, zonder dat het product bestaat.

De betalingsbereidheid: een voorverkoop of toezegging. Vraag om een aanbetaling, een ondertekende intentie of een plek op een betaalde wachtlijst. Ongemakkelijk? Juist. Dat ongemak is precies waarom het bewijs zo hard is.

De oplossing: een klikbaar ontwerp. Een Figma-prototype (een aanklikbaar ontwerp dat eruitziet als een echte app, maar niets echts doet) laat zien of mensen je oplossing snappen en willen, voor een fractie van de bouwkosten.

De dienst: de concierge-test. Lever de dienst handmatig aan een paar klanten voordat je iets automatiseert. Jij bent het product. Werkt het handmatig niet, dan gaat software het ook niet redden.

Wanneer een MVP wél de juiste stap is

Een MVP verdient zijn plek zodra de vragen verschuiven van “is het probleem echt” naar “werkt mijn oplossing in de praktijk”. Concreet: je hebt het probleem bevestigd in gesprekken, je hebt signalen van betalingsbereidheid, en de resterende onzekerheid zit in gedrag dat je alleen met een werkend product kunt meten, zoals of mensen terugkomen.

Bouw dan het kleinste ding dat die ene vraag beantwoordt. Eén kernbelofte, geen tien features. De vuistregel: schaam je je een beetje voor hoe kaal het is, dan zit je goed. Een MVP met tien functies test niets, want je weet niet welke functie het verschil maakte.

En houd het doel zuiver: een MVP is er om te leren, niet om te scoren. De vraag na de lancering is niet “vinden mensen het mooi”, maar “doet het gedrag wat de aanname voorspelde”. Zo niet, dan is dat geen mislukking maar een goedkoop gekochte les. Het volledige validatietraject, van eerste gesprek tot bewijs, staat in hoe valideer je een startup-idee.

Veelgemaakte fouten

De MVP als mini-droomproduct. Drie maanden bouwen aan “de basisversie” is geen MVP, dat is gewoon bouwen. Als je MVP een roadmap heeft, is het geen MVP.

Testen wat je al weet. Een MVP die alleen bevestigt wat vrienden al riepen, is theater. Test de aanname waar je het minst zeker van bent, niet de veiligste.

Meten wat gezegd wordt in plaats van wat gedaan wordt. “Zou je dit gebruiken?” levert beleefde antwoorden op. Kijk naar gedrag: aanmeldingen, betalingen, terugkerend gebruik.

Na de test gewoon doorbouwen. Het pijnlijkste patroon: de test zegt nee, en de founder bouwt door omdat er al zoveel in zit. Verzonken kosten zijn geen argument, ze zijn het gevaar.

Testen is geen soloklus

Goed valideren vraagt toegang tot de juiste mensen: potentiële klanten, domeinkennis, iemand die eerlijk tegengas geeft. Dat is precies waar veel founders in hun eentje vastlopen; niet op de wil, maar op het netwerk.

Dit is de kern van hoe wij bouwen. In onze Idea track begint geen enkel traject met code: je sluit aan bij een team en valideert het probleem eerst met ons netwerk, stap voor stap, op de manier van de schildpad. Je ontvangt een salaris tijdens het traject, zodat grondig testen geen luxe is die je je niet kunt veroorloven. Pas als het bewijs er ligt, wordt er gebouwd.

Veelgestelde vragen

Wat is een MVP? Een minimum viable product: de kleinste werkende versie van je product waarmee je een kernbelofte bij echte gebruikers kunt testen. Het doel is leren, niet lanceren; een MVP is een meetinstrument, geen mini-versie van je droomproduct.

Moet ik altijd eerst een MVP bouwen? Nee. De meeste vroege aannames test je sneller en goedkoper zonder te bouwen: met interviews, een landingspagina, een voorverkoop of een klikbaar ontwerp. Een MVP is pas de juiste stap als de resterende onzekerheid in gebruiksgedrag zit.

Hoe klein moet een MVP zijn? Zo klein dat het ongemakkelijk voelt. Eén kernbelofte, scherp getest, leert je meer dan tien features tegelijk. Als je niet kunt aanwijzen welke aanname je MVP test, is hij te groot.

Wat is het verschil tussen een prototype en een MVP? Een prototype laat zien hoe iets eruitziet of werkt, zonder echt te functioneren; je test er begrip en interesse mee. Een MVP functioneert echt en meet gedrag: komen mensen terug, betalen ze, gebruiken ze het zoals bedoeld.

Wil je je idee eerst tot bewijsniveau testen voordat je gaat bouwen? Mail ons op info@achmea-impact.ventures.