Van idee naar MVP: zo komen wij tot een eerste werkende versie
Bijna elk softwareproject begint met een lijst. Alles wat het product ooit moet kunnen, opgeschreven in een enthousiaste middag. Die lijst is waardevol. Alleen is het geen plan.
Want wie alles tegelijk wil bouwen, zit maanden later nog steeds zonder gebruikers en zonder antwoord op de vraag die er echt toe doet: gaan mensen dit gebruiken? Daarom beginnen wij met een MVP. In dit artikel lees je hoe we van een idee tot een eerste werkende versie komen, en welke keuzes we onderweg maken.
Wat een MVP is, en wat niet
MVP staat voor minimum viable product. De kleinste versie van je product waarmee echte gebruikers iets kunnen doen, en waarmee jij iets leert.
Dat laatste wordt vaak vergeten. Een MVP is geen demo die er mooi uitziet in een presentatie. Het is ook geen eerste fase van een vastgelegd projectplan waarin alles al besloten is. Het is een werkend stuk software dat één belangrijke aanname test. Bijvoorbeeld of klanten hun aanvraag liever zelf invoeren dan bellen, of dat monteurs een planning op hun telefoon echt gebruiken.
Klein betekent overigens niet slordig. Wat erin zit, moet goed werken. Er zit alleen minder in.
01 / Onze aanpak
In vijf stappen naar een eerste werkende versie
Elk product is anders, maar de volgorde is bij ons meestal hetzelfde.
- Stap 1
Het probleem scherp krijgen
Voor wie bouwen we, wat lukt die persoon nu niet, en hoe lost hij dat vandaag op?
- Stap 2
De belangrijkste aanname kiezen
Welke vraag moet de eerste versie beantwoorden? Daar richten we alles op.
- Stap 3
Scope terugbrengen
We schrappen tot alleen overblijft wat nodig is om die vraag te beantwoorden.
- Stap 4
Bouwen in korte rondes (iteraties)
Elke week of twee iets werkends laten zien, zodat bijsturen goedkoop blijft.
- Stap 5
Live met echte gebruikers
Een kleine groep gaat ermee werken. Wat zij doen, bepaalt de volgende stap.
Stap 1: het probleem scherp krijgen
We beginnen niet bij functies, maar bij mensen. Wie gaat dit gebruiken? Wat doen ze nu, en waar loopt het vast? Meestal praten we met een paar toekomstige gebruikers, en kijken we mee met hoe ze nu werken. Spreadsheets, mailtjes en losse briefjes vertellen vaak meer dan een requirementsdocument.
Stap 2: de belangrijkste aanname kiezen
Achter elk idee zitten aannames. Dat klanten willen betalen. Dat medewerkers een nieuwe app openen. Dat de data die je nodig hebt al ergens beschikbaar is. We zoeken de aanname die het meest riskant is: als die niet klopt, heeft de rest weinig zin. Die test de eerste versie.
Stap 3: scope terugbrengen
Hier wordt het lastig, en ook interessant. We lopen de lijst samen door en stellen bij elk onderdeel dezelfde vraag: hebben we dit nodig om de aanname te testen? Een uitgebreid rechten-/rollensysteem, rapportages, een koppeling met de boekhouding: belangrijk, maar vaak niet voor versie één. Wat afvalt, verdwijnt niet. Het gaat naar de roadmap.
Stap 4: bouwen in korte rondes (iteraties)
We bouwen in rondes van [invullen: één of twee] weken. Na elke ronde zie je iets dat werkt, geen voortgangsrapport. Zo merk je vroeg of iets anders uitpakt dan bedacht, en dan is bijsturen nog goedkoop.
Technisch kiezen we voor een basis die kan meegroeien. Een MVP mag klein zijn, maar we bouwen hem niet zo dat je na een half jaar opnieuw moet beginnen.
Stap 5: live met echte gebruikers
Een MVP is pas af als iemand ermee werkt. We zetten de eerste versie bij een kleine groep gebruikers neer en kijken wat er gebeurt. Wat gebruiken ze wel, waar haken ze af, waar vragen ze om? Dat zijn de antwoorden waar het om begon.
02 / Scope
Wat hoort in een eerste versie?
Een greep uit de keuzes die we bij bijna elk MVP maken. Wat rechts staat is niet onbelangrijk, alleen nog niet nodig.
Hoort er meestal in
- de ene taak waar het product om draait, van begin tot het eind werkend;
- inloggen en de basis van beveiliging en privacy;
- een manier om te meten hoe het gebruikt wordt;
- een plek waar gebruikers feedback kwijt kunnen.
Kan meestal wachten
- uitgebreide rollen en rechten;
- rapportages en dashboards;
- koppelingen die je eerst ook handmatig kunt doen;
- instellingen voor elke uitzondering;
- een tweede taal of een app naast de webversie.
En na de eerste versie?
Dan begint het eigenlijke werk. Met echte gebruikers en echte data kies je de volgende stap niet meer op gevoel. Soms blijkt een functie die bovenaan de lijst stond nauwelijks gemist te worden. Soms vragen gebruikers om iets waar niemand aan had gedacht.
Het kan ook gebeuren dat de belangrijkste aanname niet klopt. Dat voelt als een tegenvaller, maar het is precies wat een MVP moet opleveren: een antwoord, voordat het grootste deel van het budget op is.
Veelgestelde vragen over een MVP.
Hoe lang duurt het om een MVP te bouwen?
Dat hangt af van wat de eerste versie moet kunnen. Meestal tussen de 3 tot 6 weken. Na stap 3 weet je het nauwkeuriger, want dan ligt de scope vast.
Wat kost een MVP?
Moeten we opnieuw beginnen als het MVP werkt?
Nee. We bouwen de eerste versie op een basis die kan doorgroeien. Wat je toevoegt, bouwt voort op wat er al staat.
Wat als we niet weten welke aanname het belangrijkst is?
Dan beginnen we daar. In een korte discovery zoeken we samen uit waar het grootste risico zit, voordat er code geschreven wordt.
Een idee dat je wilt toetsen?
Vertel ons wat je wilt bouwen en voor wie. We denken mee over wat er in de eerste versie hoort, en wat nog even kan wachten.