Wat ik vraag voordat ik één regel van je MVP schrijf

De reflex bij een MVP is om alles te bouwen wat het product uiteindelijk nodig heeft, want wie lanceert er nou iets wat niet af is? Die reflex, letterlijk gevolgd, is hoe een MVP van drie maanden er negen wordt zonder dat er één betalende klant is gevonden. Voordat er iets geschreven wordt, zijn er een paar vragen die eerst een antwoord verdienen — niet omdat proces leuk is, maar omdat ze overslaan de beste voorspeller is van een project dat over budget gaat.

“Wat wil je eigenlijk te weten komen?”

Een MVP is geen kleine versie van het eindproduct. Het is het kleinste ding dat één specifieke, nu nog open vraag beantwoordt — meestal “wil iemand hiervoor betalen?” of “werkt dit proces echt zoals ik denk?” Kun je die vraag niet benoemen, dan kun je ook niet weten wat je weg kunt laten, en voelt alles essentieel. Die vraag vooraf benoemen is op zichzelf meestal genoeg om een functielijst ongeveer te halveren.

“Wat als dit mislukt?”

Niet het product — de test. Als tien gebruikers het proberen en het niks vinden, wat doe je dan? Wie daarover heeft nagedacht, bakent strakker af, want je bouwt iets wat je bereid bent weg te gooien. Wie dat niet heeft gedaan, investeert te veel in een MVP alsof het het eindproduct is, want weglopen van een half jaar werk is emotioneel een stuk zwaarder dan weglopen van drie weken.

“Wie is de eerste gebruiker, precies?”

Niet “mkb-bedrijven” — een specifiek iemand, in een specifieke situatie, die je volgende week voor je ziet werken met dit ding. Vage gebruikers leveren vage afbakening op. Eén concrete eerste gebruiker laat de helft van de discussies over functies vanzelf verdwijnen, omdat je simpelweg kunt vragen: heeft diegene dit nodig om er op dag één iets aan te hebben?

“Wat kost het als de techniekkeuze verkeerd is?”

MVP’s worden gebouwd op wat snel gaat, en dat klopt meestal — maar het is de moeite waard om eerlijk te zijn over welke keuzes later goedkoop terug te draaien zijn (hoe de schermen gebouwd zijn) en welke niet (hoe de gegevens zijn opgeslagen, wie de betalingen afhandelt, hoe inloggen werkt). Aan die tweede categorie besteed ik echt tijd, en door de eerste ga ik bewust snel heen.

Hoe dat er in de praktijk uitziet

Voordat er code komt, wil ik één alinea als antwoord op: wat moet deze MVP bewijzen, aan wie, en wanneer. Alles wat die alinea niet dient, krijgt een aantekening voor fase twee in plaats van een plek in de bouw. Het is een minder spannende aftrap dan meteen de functies in duiken — maar het is het verschil tussen een MVP die opgeleverd wordt en een MVP die ongemerkt uitgroeit tot een compleet product dat nog niemand getest heeft.

Heb je een idee en een ruwe vorm voor een MVP, maar wil je er iemand naar laten kijken voordat je budget vastlegt? Laten we het doornemen — dat gesprek is gratis.