Een MVP bouwen: van idee naar eerste werkende versie in weken

In het kort

Een MVP (minimum viable product) is de eerste werkende versie van je software: klein genoeg om in weken te bouwen, compleet genoeg om echte gebruikers er echt werk mee te laten doen. Je bouwt een MVP om te leren wat werkt voordat je de volledige applicatie bouwt. De kunst zit in de scope: één gebruiker, één kernproces, van begin tot eind. Je bouwt in korte sprints, zet de versie zo snel mogelijk bij een kleine groep gebruikers neer en laat hun feedback bepalen wat je daarna bouwt.

Wat een MVP wel en niet is

Het begrip wordt vaak verkeerd gebruikt. Drie misverstanden die we in bijna elk eerste gesprek tegenkomen.

Een MVP is geen prototype

Een klikbaar ontwerp of demo laat zien hoe iets eruit gaat zien, maar doet geen werk. Een MVP verwerkt echte gegevens, van echte gebruikers, in hun echte dagelijkse routine. Alleen dan leer je of je aanname klopt. Een prototype kan wel een nuttige stap ervoor zijn, zeker als je nog niet weet hoe het scherm eruit moet zien.

Een MVP is geen halve applicatie

Wie een MVP ziet als de helft van alle functies, eindigt met een applicatie waarin alles half werkt. De juiste knip is anders: je bouwt honderd procent van één proces en nul procent van de rest. Een intake die van aanvraag tot bevestiging loopt, is een MVP. Een intake plus een half dashboard plus een begin van facturatie is dat niet.

Minimaal betekent niet slordig

De code van een MVP moet net zo goed getest en beveiligd zijn als die van een grote applicatie. Wat je weglaat zijn functies, geen zorgvuldigheid. Een MVP die gegevens kwijtraakt of lek is, kost je het vertrouwen van precies de gebruikers van wie je wilde leren.

De scope kiezen: één gebruiker, één doorloop

De meest bruikbare methode om een scope te kiezen bestaat uit drie vragen.

1. Voor wie bouw je dit als eerste? Kies één type gebruiker. Niet je klanten, je medewerkers en je partners tegelijk, maar bijvoorbeeld de planner die elke ochtend de ritten indeelt.
2. Welke taak moet die persoon volledig kunnen afronden? Beschrijf de doorloop in stappen, van het moment dat het werk begint tot het moment dat het klaar is en de volgende persoon verder kan.
3. Wat is het kleinste dat nodig is om die doorloop te halen? Ga stap voor stap langs de doorloop en vraag bij elke functie: kan de gebruiker zonder deze functie de taak afronden? Zo ja, dan hoort de functie niet in de MVP.

Zet het resultaat in drie kolommen. Dat maakt het gesprek met je bouwer concreet en voorkomt dat het lijstje stiekem groeit.

Het voorbeeld is bewust eenvoudig; het patroon geldt voor elke applicatie. De middelste kolom is geen afwijzing, het is de planning voor sprint drie en verder.

Wat je bijna altijd kunt weglaten

Uit ervaring: dit zijn de onderdelen die in bijna elke eerste versie sneuvelen, en waar bijna niemand achteraf spijt van heeft.

• Rollen en rechten. Eén type gebruiker met dezelfde rechten. Beheerdersfuncties doe je de eerste weken via een simpel scherm dat alleen jij ziet.
• Instellingen. Alles wat instelbaar zou kunnen zijn, zet je vast in de code. Pas als twee gebruikers iets anders willen, wordt het een instelling.
• Rapportages en dashboards. Een export naar een spreadsheet dekt de eerste maanden vrijwel elke rapportagevraag.
• Koppelingen. Handmatig importeren of een bestand uploaden is vaak goed genoeg om te leren. De koppeling bouw je zodra het proces stabiel is; anders koppel je iets dat volgende maand weer verandert.
• Een native mobiele app. Een webapplicatie die goed werkt op de telefoon is in bijna alle gevallen voldoende voor een eerste versie, zonder app-store en zonder installatie.
• Visuele afwerking. Een net, consistent scherm is genoeg. Animaties, huisstijl tot in detail en een eigen illustratiestijl komen later.

Bouwen in sprints van twee weken

Een sprint is een vaste periode, bij ons twee weken, met aan het begin een afspraak over wat er gebouwd wordt en aan het einde een demo van wat er werkt. Het ritme doet drie dingen voor je.

Het dwingt keuzes af. Elke twee weken moet iets af zijn en getoond kunnen worden, dus grote vage onderdelen worden vanzelf opgeknipt in kleine concrete stukken.

Het maakt bijsturen goedkoop. Zie je in de demo van sprint twee dat een scherm niet werkt zoals je dacht, dan verandert dat de planning van sprint drie, niet een oplevering na een halfjaar.

Het geeft je grip zonder dat je technisch hoeft te zijn. Je beoordeelt werkende software, geen documenten.

Wat een bouwer van jou nodig heeft

• Iemand die beslissingen kan nemen, bereikbaar is en de demo bijwoont. Zonder die persoon vertraagt elk klein vraagstuk een week.
• Echte voorbeelddata en echte documenten, geen verzonnen testgevallen.
• Eerlijke feedback in de demo. Een scherm dat niet klopt, wil je in week twee horen, niet in week tien.

Een eerste werkende versie staat op deze manier vaak binnen enkele weken. Hoeveel weken precies hangt af van het aantal stappen in de doorloop en van hoeveel er gekoppeld moet worden. Lees ook wat maatwerksoftware kost voor de factoren die de omvang bepalen.

Feedback verzamelen: de reden dat je een MVP bouwt

Een MVP zonder gebruikers is een dure oefening. Regel daarom vóór de eerste sprint wie de eerste gebruikers zijn en wanneer ze beginnen. Een kleine groep die het echt gebruikt, leert je meer dan een grote groep die het even bekijkt.

Wat je meet en vraagt

• Gebruik. Loggen mensen in, en ronden ze de doorloop af? Als ze halverwege afhaken, zit daar je eerste verbeterpunt.
• Omwegen. Welke stappen doen gebruikers nog buiten de applicatie, in mail of een spreadsheet? Dat zijn kandidaten voor de volgende sprint.
• Tijd. Vergelijk hoe lang de taak vóór en met de MVP duurt. Een simpele meting bij een paar gebruikers is genoeg om te weten of je op de goede weg zit.
• Vragen. Welke vragen stellen gebruikers aan jou of aan elkaar? Elke terugkerende vraag is een ontwerpfout of een ontbrekende functie.

Ga niet af op wat mensen zeggen dat ze willen, maar op wat ze doen. Een gebruiker die om tien extra functies vraagt maar de basis niet gebruikt, vertelt je iets anders dan hij denkt.

Wanneer is de MVP klaar?

Als de eerste groep de taak zonder jouw hulp afrondt en niet meer terugvalt op de oude manier. Dat is het moment om te beslissen: uitbreiden, bijsturen of stoppen. Alle drie zijn goede uitkomsten. Een MVP die aantoont dat een idee niet werkt, heeft je een veel duurdere fout bespaard.

Na de MVP: doorontwikkelen zonder het fundament kwijt te raken

Na een geslaagde MVP is de verleiding groot om meteen alles uit de backlog te bouwen. Doe eerst drie dingen.

1. Ruim op. In een MVP zitten bewuste kortere routes: een vaste instelling, een handmatige stap, een scherm zonder validatie. Maak een lijst en los de punten op die in de weg gaan zitten bij de volgende functies.
2. Kijk naar het datamodel. Als de eerste gebruikers gegevens anders bleken te gebruiken dan verwacht, pas dan nu de structuur aan, nu er nog weinig data en weinig gebruikers zijn.
3. Regel beheer en monitoring. Vanaf nu draait er software waar mensen op vertrouwen. Back-ups, foutmeldingen die bij iemand terechtkomen en een afspraak over onderhoud horen erbij.

Daarna bouw je verder in hetzelfde ritme: sprint, demo, feedback. Het verschil met de MVP-fase is dat de vragen preciezer worden en dat de koppelingen en rollen die je eerder wegliet nu aan de beurt zijn. Voor een klantgerichte applicatie is een klantportaal in fases bouwen een goed voorbeeld van hoe dat eruitziet.

Zo begin je

1. Kies de ene gebruiker en de ene taak waarvoor je bouwt.
2. Schrijf de doorloop uit in stappen, van begin tot eind, en markeer welke stap nu de meeste tijd of fouten kost.
3. Vul de tabel met moet, later en niet. Wees streng in de eerste kolom.
4. Bepaal wie de eerste gebruikers zijn en wanneer zij beginnen.
5. Spreek met je bouwer af wat in sprint één staat, wie de demo bijwoont en waar de code en data komen te staan.
6. Plan het moment waarop je beslist: uitbreiden, bijsturen of stoppen.

Met deze zes stappen op één A4 heb je een opdracht waarmee een bouwer van maatwerksoftware direct aan de slag kan, en een meetlat waarlangs je na een paar weken kunt beoordelen of het werkt.