Waarom je MVP waarschijnlijk drie keer te groot is

Als ik tien founders vraag hun MVP-scope te beschrijven, zijn er negen die uitkomen op iets wat eerder een productvisie is dan een minimum. De tiende is meestal iemand die al een ronde heeft gehad waarin er weer iets bijgevoegd is.

Dat patroon is geen toeval. Iedere keuze in een vroeg product voelt belangrijk, iedere feature voelt urgent, en iedere “we kunnen het er toch ook gewoon in zetten” voelt logisch. Het resultaat is een MVP die twee tot drie keer zo groot is als wat er nodig is om de eigenlijke vraag te toetsen.

Dit artikel staat stil bij wat een MVP eigenlijk moet zijn, waarom features veilig voelen, en hoe je terugkomt op één workflow die de echte beslissing toetst.

MVP als beslissingstest

Een MVP is geen kleinere versie van het uiteindelijke product. Een MVP is een instrument om één beslissing scherp te krijgen.

Welke beslissing? Meestal een van deze:

• Begrijpen klanten waar dit over gaat?
• Vinden ze het probleem echt urgent?
• Zijn ze bereid hun gedrag te veranderen om het te gebruiken?
• Zijn ze bereid ervoor te betalen?

Iedere feature in je MVP-scope hoort één van die vragen scherper te beantwoorden. Features die geen van die vragen helpen beantwoorden, horen niet in je MVP. Ze horen op een lijst voor later, en die lijst moet je expliciet bijhouden, niet wegmoffelen.

Wat absoluut niet in v1 hoort

Een paar dingen die ik in vrijwel iedere te grote MVP-scope tegenkom:

Een instellingenpagina. Klanten weten nog niet of ze het product willen gebruiken. Wat ze willen instellen, weet je nog niet. Bouw voorlopig één opstelling die voor de meeste klanten klopt.

Verschillende gebruikersrollen. Tenzij je product fundamenteel over samenwerking gaat. Anders: één rol, één type gebruiker, één weergave.

Een admin-paneel met statistieken. Bouw in plaats daarvan een rapportje dat je één keer per week handmatig draait. Pas op zijn vroegst bij klant 20 wordt automatisering goedkoper dan handmatig werk.

Meertaligheid. Voor je eerste 50 klanten is dat zelden de bottleneck. Engels of Nederlands, kies één en blijf eraan vasthouden.

Mobile native naast desktop. Een mobielvriendelijke webversie dekt 95% van de gevallen. Lees waarom een mobiele website vaak wint van een app.

Geavanceerde analytics dashboards. In de eerste maanden ken je iedere klant persoonlijk. Belt er iemand, dan weet je waarom. Geen dashboard nodig.

Geen van deze features is fout. Ze horen alleen niet in v1, omdat ze geen van de vier beslissingsvragen scherper maken.

Waarom features veilig voelen

Features bouwen voelt productief. Iedere feature is een concreet ding waar je naar kunt wijzen. Iedere feature kun je uitleggen. Iedere feature heeft een naam, een ticket, een definition of done.

Beslissingen maken voelt anders. Beslissingen zijn ongrijpbaar. Een afgeronde beslissing ziet eruit als een gesprek dat is afgelopen, geen feature die af is. Daarom zijn founders geneigd het beslissingswerk over te slaan en te springen naar features.

Het patroon werkt zo: er is iets onduidelijk. In plaats van die onduidelijkheid op tafel te leggen en uit te praten, voegt het team een feature toe die “voor alle gevallen werkt”. Wat eigenlijk een open vraag was, wordt een productiebeslissing die over zes maanden moet terugkomen om versimpeld te worden.

Iedere veilige feature is een vermijde beslissing. Een groeiend aantal vermijde beslissingen is je groeiende MVP-scope.

Waarom scope groeit

Naast veiligheid zijn er drie krachten die scope vrijwel altijd opdrijven:

Het sympathieke “ja”. Een mede-founder, een investeerder, een klant doet een redelijke suggestie. Het lijkt klein. Het lijkt goedkoop om mee te nemen. Het wordt toegevoegd. Tien suggesties verder is de scope onhandelbaar.

De “as long as we’re at it”. “Als we toch al die schermen aan het bouwen zijn, kunnen we deze ook meteen meenemen.” Dat klinkt efficiënt. Het is meestal het tegenovergestelde, je voegt complexiteit toe aan iets wat juist eenvoudig moest blijven.

De toekomstige klant. Je bouwt voor “ook bedrijven van 50 mensen straks”, “ook in de zorgsector later”, “ook op tablets eventueel”. Het zijn redelijke ambities. Het zijn alleen geen versies van het product die je eerste vijf klanten gebruiken.

Geen van deze krachten is verkeerd. Ze worden alleen niet expliciet besproken. Zonder dat gesprek heeft de scope geen rem.

Hoe je terugbrengt naar één workflow

De oefening: schrijf de drie tot vijf functies op die de eerste klant echt nodig heeft om de centrale vraag voor jou te beantwoorden. Dat is vaak inloggen niet eens. Dat is vaak alleen: “kan iemand één keer een actie uitvoeren en daarna terugkomen?”.

Vraag bij elke geplande feature: helpt deze één van de vier beslissingsvragen beantwoorden? Zo nee, dan op de “later”-lijst. Geen discussie, geen “we doen het er even bij”.

De cynische versie van deze regel: jouw v1 mag er onaf uitzien. Het mag opvallend simpel zijn. Het mag dingen ontbreken waar mensen later om vragen. Het mag dat allemaal, zolang het de centrale vraag van een eerste klant scherp beantwoordt.

Een MVP die er af uitziet maar de vraag niet beantwoordt, is geen MVP. Het is een vroegtijdig productlanceringsdrama.

Verschil tussen geloofwaardig en compleet

Geloofwaardig wil zeggen: een klant kan zien dat dit een serieus product wordt. Het werkt waar het moet werken. De flow die getest wordt, voelt af.

Compleet wil zeggen: alles wat een gebruiker zou kunnen verwachten van een volwassen product is er. Geen losse eindjes, geen ontbrekende schermen, geen “binnenkort”-teksten.

Een MVP moet geloofwaardig zijn. Hij hoeft niet compleet te zijn. Veel founders vermengen die twee en bouwen aan compleetheid, terwijl geloofwaardigheid genoeg is om de eigenlijke beslissing te kunnen toetsen.

Waarom kleiner vaak sneller leert

Een kleinere MVP is sneller te bouwen, sneller live te zetten, sneller aan te passen en sneller weg te gooien als de aanname niet klopt. Iedere week eerder leveren is een week extra leren.

Dat leerritme is het echte voordeel. Niet de financiële besparing op bouwwerk, al is die ook reëel. Het belangrijkste is dat je drie cycli kunt afronden in de tijd dat een te grote MVP er één doet. Drie cycli aan klantfeedback levert vrijwel altijd meer op dan één cyclus aan polish.

Als je twijfelt over scope, kun je het altijd toetsen met een korte onafhankelijke blik, vaak ontdek je dan dat de helft van je MVP-scope eigenlijk een v2-discussie is.

---

Sta je voor deze beslissing?

Stuur me kort de context of plan een gratis gesprek. Dan kijken we samen wat de meest verstandige volgende stap is voor je tijd, geld of focus vastlegt.

Plan een gratis gesprek → · Mail direct: hello@yourstartup.expert