Een MVP bouwen zonder te veel te bouwen

Elke founder weet dat hij een minimum viable product hoort te bouwen. Bijna niemand is het eens over wat „minimum" betekent, en die verwarring kost geld. Het ene team zet een landingspagina online en noemt dat een MVP; het andere bouwt negen maanden aan een gelikt platform waar niemand om vroeg, en noemt dat net zo goed een MVP.

Het woord waar mensen over struikelen is „viable", levensvatbaar. Een MVP is geen uitgeklede versie van je eindproduct. Het is het kleinste experiment dat de ene vraag beantwoordt waar je hele idee van afhangt. Heb je dat kader scherp, dan win je maanden. Heb je het mis, dan bouw je een beeldschoon antwoord op een vraag die niemand stelde.

In deze gids lees je hoe je een MVP rond één riskante aanname afbakent, hoe je de lichtst mogelijke bouw kiest, en hoe je de valkuil van overbouwen omzeilt, die stilletjes meer eerste producten de das omdoet dan slechte code ooit deed.

Begin bij de aanname, niet bij de functies

Voordat je één regel code of één user story schrijft, beantwoord je één vraag: wat moet er waar zijn om van dit bedrijf iets te maken, en waar ben je nu het minst zeker van? Dat is je riskantste aanname, en je MVP bestaat om die te toetsen. Verder niets.

Bij de meeste vroege ideeën zit het risico in de vraag: gaat iemand dit echt gebruiken, of ervoor betalen? Soms zit het in de haalbaarheid: valt dit überhaupt te bouwen? En soms in een specifiek gedrag: doen gebruikers het ongebruikelijke dingetje dat het product van ze vraagt? Wat het ook is, schrijf het op als een uitspraak die je onderuit kunt halen, met een drempel eraan, net zoals in een validatiesprint van 30 dagen voor je startup-idee. „Minstens 30% van wie op de pagina landt, schrijft zich in voor de wachtlijst" is toetsbaar. „Mensen gaan dit geweldig vinden" niet.

Kies de lichtste bouw die echt bewijs oplevert

Zodra je de vraag kent, kies je de goedkoopste manier om hem eerlijk te beantwoorden. Code is meestal de duurste optie, dus behandel die als laatste redmiddel, niet als startpunt. Het spectrum van MVP's, van lichtst naar zwaarst:

De kunst is de bouw bij de vraag te laten passen. Zit het risico in de vraag, dan beantwoordt een landingspagina met een echte call-to-action dat in een dag, zonder product. Zit het risico in de vraag of mensen een complexe workflow afmaken, dan heb je misschien een werkende versie nodig, maar vaak kun je de achterkant faken (de „Wizard of Oz"-aanpak) en hem met de hand draaien terwijl gebruikers denken dat het automatisch gaat. Beroemde jonge bedrijven draaiden concierge-MVP's waarbij de founders bestellingen met de hand afhandelden, lang voordat er iets geautomatiseerd was.

35%

De valkuil van overbouwen

Overbouwen is de standaardmanier om te falen, en zelden voelt het als een fout terwijl het gebeurt. Elke toegevoegde functie lijkt redelijk. Samen schuiven ze de lancering maanden vooruit en begraven ze het signaal dat je probeerde af te lezen.

Founders overbouwen om drie redenen, en alle drie zijn emotioneel, niet strategisch:

• Angst voor het oordeel. Een kale MVP voelt gênant, dus poets je hem op tot hij „klaar" voelt. Maar of iets klaar is, bepalen gebruikers, niet jouw ongemak.
• Inspanning verwarren met voortgang. Functies opleveren voelt productief. Leren of iemand ze wil, is de enige voortgang die telt.
• De enge vraag ontwijken. Zolang je bouwt, hoef je nooit een echte gebruiker nee te horen zeggen. Bouwen wordt een manier om de waarheid uit te stellen.

Elke functie die je voor de lancering toevoegt, is een weddenschap dat je al weet wat gebruikers willen. En een MVP draait er nu juist om dat je dat niet weet.

De discipline: schrappen tot het pijn doet, en dan opleveren. Voel je je niet een beetje ongemakkelijk bij hoe weinig je MVP doet, dan heb je te veel gebouwd.

Lever niet iets op dat niets toetst

Er bestaat een omgekeerde fout, en die komt net zo vaak voor: de MVP die zo minimaal is dat hij de kernactie niet kan voltooien. Een landingspagina is een prima vraagtest, maar als je echte vraag „gaan mensen de workflow gebruiken?" is, beantwoordt een landingspagina niets. „Minimum" wordt begrensd door „viable": het product moet een echte gebruiker het kerndingetje laten doen en een helder signaal opleveren.

De levensvatbaarheidstest is simpel: kan een vreemde, zonder enige uitleg van jou, de ene actie voltooien waar je bedrijf van afhangt, en je data geven over of hij het nog eens zou doen? Zo ja, dan is het levensvatbaar. Moet je naast hem komen staan om hem op weg te helpen, dan heb je een demo, geen MVP.

Hier bewijst een sterke technische partner zijn waarde. Beslissen wat je faket en wat je echt bouwt, en dat echte deel snel neerzetten, is een kwestie van oordeel. Juist daarom wil je iemand naast je die al eens eerder iets heeft opgeleverd, of dat nu een technische co-founder uit het netwerk is of een vroege engineer die dit dansje kent.

Je MVP in vier stappen

1. Benoem de riskantste aanname

   Schrijf het ene wat waar moet zijn op als een bewering die je onderuit zou kunnen halen, met een getal eraan. Die zin is de complete functieomschrijving van je MVP.

2. Kies de lichtste bouw die hem toetst

   Begin boven aan het MVP-spectrum, bij landingspagina, concierge en no-code, en zak pas richting echte code als een lichtere test de vraag niet beantwoordt.

3. Zet een deadline in weken

   Plak een termijn van een paar weken op de bouw. Die deadline dwingt je scope eerlijk te houden: alles wat de kernvraag niet dient, sneuvelt om hem te halen.

4. Bepaal vooraf wat 'het werkte' betekent

   Leg de drempel vast voordat je lanceert, zodat je het resultaat eerlijk afleest in plaats van het achteraf goed te praten. Zet het dan voor echte gebruikers neer en kijk naar wat ze doen, niet naar wat ze zeggen.

Zodra je MVP je een helder signaal geeft, draait de volgende vraag om: is die vroege tractie echt en herhaalbaar? Daar begint de zoektocht naar product-market fit. Maar die zoektocht start pas nadat je iets echts hebt opgeleverd dat klein genoeg is om van te leren. Bouw het experiment, niet het product. Het product komt na het bewijs.