MVP
Vraag het me voordat je een MVP bouwt.
MVP-scopes hebben de neiging om groter te worden. Iedere feature voelt urgent, iedere "ook handig" wordt erbij gezet, en wat begon als een test wordt een product. Het gevolg: maanden bouwwerk, één late lancering en een product dat te groot is om snel bij te sturen. Een korte check brengt de scope terug naar de werkelijke kernvraag.
Toets dit voordat je commit
Wat ik als eerste check.
- 01
Welke ene vraag test deze MVP, herkennen klanten het probleem, of zijn ze bereid te betalen?
- 02
Wat is de kleinste workflow waarin een klant waarde ontvangt?
- 03
Welke features dragen niet bij aan die ene vraag?
- 04
Wat hoort expliciet op een "later"-lijst?
- 05
Hoe meet je het verschil tussen "ze gebruikten het" en "ze kwamen terug"?
Veel voorkomende patronen
Wat ik het vaakst zie gebeuren.
- MVPs worden twee tot drie keer groter dan nodig.
- Features worden toegevoegd om keuzes te vermijden.
- Instellingen, rollen en dashboards worden in v1 gebouwd voor klanten die nog niet bestaan.
- Geloofwaardig wordt verward met compleet.
Wat het gesprek oplevert
Waar je mee weggaat.
- 01
Een afgeslankte MVP-scope, gemarkeerd per kernvraag.
- 02
Een expliciete "niet in v1"-lijst.
- 03
Een werkbare planning voor de eerstvolgende cyclus.
Verder lezen
Artikelen over dit vraagstuk.
- 6 min leestijd
Waarom je MVP waarschijnlijk drie keer te groot is
Founders verwarren een eerste verkoopbare versie met een volledige productvisie. Waarom features veilig voelen, en hoe je terug komt naar één workflow.
- 8 min leestijd
Wat hoort in je MVP en wat kan wachten
Een besliskader om de eerste release compleet, geloofwaardig en veel kleiner te houden.
- 7 min leestijd
Bouw minder: de startupvaardigheid die niemand wil leren
Functies toevoegen voelt productief. Ze schrappen vraagt om een helderder begrip van waarde.
Klaar om te praten?
Moet je dit allemaal bouwen?
De meeste MVP’s zijn groter dan nodig. Hoe sneller je leert, hoe sneller je ontdekt wat echt belangrijk is.