Veertien maanden bouwen, en bij de oplevering blijkt dat de afdeling inmiddels anders werkt dan in het oorspronkelijke plan stond. Dat scenario komen we in gesprekken met organisaties nog steeds tegen, en het is precies het probleem waar een MVP voor bedoeld is.
Zoek je op MVP betekenis, dan kom je twee werelden tegen. In de sport staat MVP voor most valuable player, de beste speler van een wedstrijd of seizoen. In dit artikel gaat het over de andere betekenis: minimum viable product, een begrip uit de softwareontwikkeling dat bepaalt hoe je een nieuw product verstandig start.
Een MVP (minimum viable product) is de kleinste werkende versie van een product waarmee je bij echte gebruikers toetst of het idee waarde oplevert. De MVP bevat alleen de functies die nodig zijn om één kernprobleem op te lossen, en levert meetbare feedback op voordat je verder investeert. Het doel is leren met zo min mogelijk bouwwerk.
MVP betekenis: eerst leren, dan bouwen
Het begrip komt uit de startupwereld. Frank Robinson gebruikte de term rond 2001 en Eric Ries maakte hem bekend met zijn boek The Lean Startup. De kern van zijn redenering: elk product is een aanname over wat gebruikers willen, en de goedkoopste manier om die aanname te toetsen is een kleine versie die je zo snel mogelijk aan gebruikers geeft.
Voor organisaties die software laten bouwen betekent dat een omslag in denken. In plaats van een volledig pakket van eisen dat je in één keer laat bouwen, kies je het ene proces waar de meeste pijn zit, bouwt daar een werkende oplossing voor en meet wat er gebeurt. Wat je leert, bepaalt de volgende stap. Wat je niet hoeft te leren, hoef je ook niet te bouwen.
Neem Joris, hoofd bedrijfsbureau bij een installatiebedrijf met 120 monteurs. Zijn planners werken in drie spreadsheets en bellen dagelijks rond om wijzigingen door te geven. Het wensenlijstje voor een nieuwe planningstool telt 40 punten, van urenregistratie tot een koppeling met het boekhoudpakket. De MVP beperkt zich tot één ding: de weekplanning van één regio, zichtbaar op de telefoon van de monteur, met een pushbericht bij elke wijziging. Na zes weken gebruik weet Joris of de telefoontjes afnemen en welke van de overige 39 wensen er nog toe doen.
Dat is de waarde van een MVP in één zin: je bewijst met de kleinste versie dat de richting klopt, en je besteedt je budget daarna aan de dingen waarvan je weet dat ze werken. Op onze pagina over maatwerksoftware laten ontwikkelen lees je hoe zo'n eerste versie uitgroeit tot een volledige applicatie.
MVP, prototype, proof of concept of pilot: de verschillen
De termen worden door elkaar gebruikt, terwijl ze elk een andere vraag beantwoorden. Een prototype laat zien hoe iets eruitziet, een proof of concept laat zien dat iets technisch kan, een MVP laat zien dat iets waarde heeft en een pilot toetst of een afgebouwd product in een bredere groep werkt.
| Vorm | Wat het toetst | Werkende software | Gebruikers | Vervolg |
|---|---|---|---|---|
| Prototype | Of gebruikers het ontwerp begrijpen | Nee, klikbare schermen of schetsen | Testpanel, meestal intern | Wordt weggegooid |
| Proof of concept | Of iets technisch kan, zoals een koppeling met een oud ERP | Deels, vaak wegwerpcode | Ontwikkelaars | Wordt weggegooid of opnieuw gebouwd |
| MVP | Of het kernprobleem is opgelost en mensen het gebruiken | Ja, productieklaar en klein | Een afgebakende groep echte gebruikers | Groeit door tot het volledige product |
| Pilot | Of het volledige product in een bredere groep werkt | Ja, volledig | Een afdeling, vestiging of klantgroep | Bredere uitrol |
Het belangrijkste verschil zit in de laatste kolom. Een prototype en een proof of concept gooi je weg zodra je het antwoord hebt. Een MVP bouw je op een basis die mee kan groeien: dezelfde architectuur, dezelfde beveiliging en dezelfde tests als de uiteindelijke applicatie, alleen met veel minder functies. Wie een MVP behandelt als wegwerpcode, betaalt de bouw later twee keer.
MVP ontwikkelen: zo bepaal je de scope
De scope van een MVP bepalen is het moeilijkste deel, omdat iedereen aan tafel een eigen lijstje heeft. Drie afbakeningen helpen om die lijstjes klein te houden.
Eén kernproces
Kies het proces waar op dit moment de meeste tijd, fouten of frustratie in zit. Alles wat dat proces raakt hoort in de MVP; alles wat ernaast ligt, gaat op de lijst voor later. Voor Joris was dat de weekplanning. De urenregistratie kwam op de lijst voor later, ook al vroeg de financiële afdeling daar het hardst om.
Eén doelgroep
Een MVP die tegelijk voor planners, monteurs, klanten en de directie moet werken, is geen MVP meer. Kies de groep die het proces dagelijks uitvoert en bouw voor hen. Andere gebruikers komen in een volgende versie aan bod, met de feedback van de eerste groep als vertrekpunt.
Eén meetbaar doel
Spreek vooraf af waaraan je succes afmeet en hoe je dat meet. Minder telefoontjes per dag, een kortere doorlooptijd per aanvraag, minder fouten per week: het maakt weinig uit welk getal je kiest, zolang je het vóór de bouw vastlegt en na zes tot acht weken gebruik vergelijkt. Zonder meetplan wordt de evaluatie een meningenstrijd.
Voorbeeld: een intern portaal voor één afdeling
Fatima is IT manager bij een zorgorganisatie met 900 medewerkers. Verlofaanvragen, roosterwissels en declaraties lopen via mail en papieren formulieren, en het wensenlijstje voor een medewerkersportaal past niet op één A4. Ze kiest voor een MVP: alleen roosterwissels, alleen voor de afdeling thuiszorg met 60 medewerkers, met als doel dat een wissel binnen een dag is goedgekeurd in plaats van binnen een week.
Na twee maanden blijkt dat het portaal werkt, en dat medewerkers vooral het inzicht in hun eigen rooster waarderen. Dat inzicht stond op geen enkel lijstje. De volgende versie krijgt daarom eerst een roosteroverzicht, daarna verlof en pas daarna declaraties. Twijfel je welk proces zich leent voor een eerste versie, dan kijken we daar in een onafhankelijk adviesgesprek samen naar, ook als het antwoord is dat je beter bij standaardsoftware kunt blijven.
Van MVP naar volwassen software
Een MVP is een startpunt. De waarde zit in wat je ermee doet nadat de eerste gebruikers ermee gewerkt hebben. Daar gaat het in de praktijk het vaakst mis, om drie herkenbare redenen.
Drie veelgemaakte fouten
- Te veel functies. Elke extra functie maakt de bouw langer en de feedback vager. Heeft de MVP na drie maanden nog geen gebruikers, dan is de scope te groot gekozen.
- Geen meetplan. Zonder afgesproken doel weet niemand na afloop of de MVP geslaagd is, en beslist degene met de hardste stem over het vervolg.
- Een MVP die nooit doorgroeit. Soms blijft de eerste versie jarenlang in gebruik zonder beheer, beveiliging of doorontwikkeling. Zo'n versie groeit dan uit tot een risico in plaats van een product.
Zo groeit een MVP door
De overgang naar volwassen software vraagt om dezelfde discipline als de MVP zelf. Meet wat gebruikers doen, kies elke cyclus van twee tot drie weken de functies met de meeste impact en lever die werkend op. Regel tegelijk de zaken die bij een eerste versie vaak wachten: beheer, monitoring, backups, toegangsbeheer en documentatie.
Bij Isatis bouwen we een MVP daarom van meet af aan op dezelfde technische basis als de latere applicatie. Ons team van 30+ engineers in Nijmegen en Sarajevo werkt volgens ISO 9001 en ISO 27001, ook in de eerste versie, zodat beveiliging en kwaliteit later geen inhaalslag vragen. En omdat de mensen die de MVP bouwen dezelfde mensen zijn die de software daarna draaiend houden, gaat er tussen versie één en versie tien geen kennis verloren. Hoe zo'n traject van eerste versie tot productie eruitziet, lees je bij custom software development.
Kies je een externe partij voor je MVP, let dan vooral op wie de code na de eerste versie beheert en of dat team blijft. In hoe je een softwarebedrijf kiest staan de vragen die je daarvoor stelt.
Veelgestelde vragen
Wat betekent MVP?
MVP staat voor minimum viable product: de kleinste werkende versie van een product die genoeg waarde biedt om bij echte gebruikers te toetsen of het idee klopt. In de sport betekent MVP most valuable player, de beste speler van een wedstrijd of seizoen. Een uitgebreide achtergrond van het begrip vind je op Wikipedia over minimum viable product [CHECK: URL bevestigen].
Wat is het verschil tussen een MVP en een prototype?
Een prototype laat zien hoe iets eruitziet en bestaat meestal uit klikbare schermen of schetsen die je na de test weggooit. Een MVP is werkende software die een afgebakende groep gebruikers in de praktijk gebruikt en die daarna doorgroeit tot het volledige product.
Hoe lang duurt het bouwen van een MVP?
Dat hangt af van het kernproces en het aantal koppelingen. Een goed afgebakende MVP staat vaak binnen enkele weken tot een paar maanden bij de eerste gebruikers. Duurt de bouw langer dan drie maanden zonder dat iemand ermee werkt, dan is de scope meestal te groot gekozen.
Wat kost een MVP?
De kosten hangen af van de omvang van het kernproces, het aantal koppelingen met bestaande systemen en de kwaliteitseisen, zoals beveiliging in de zorg. Een bedrag noemen zonder de opgave te kennen zou een gok zijn. Na een verkennend gesprek geven we een concrete inschatting met heldere aannames; in wat maatwerksoftware kost leggen we uit welke factoren de prijs bepalen.
Samengevat
Een MVP is de kleinste werkende versie van een product waarmee je bewijst dat de richting klopt voordat je verder investeert. De belangrijkste punten op een rij:
- Kies één kernproces, één doelgroep en één meetbaar doel.
- Een MVP is werkende software op een basis die mee kan groeien; een prototype en een proof of concept gooi je weg.
- Zonder meetplan wordt de evaluatie een meningenstrijd.
- De waarde zit in het vervolg: meten, prioriteren en in korte cycli doorbouwen, met hetzelfde team dat de eerste versie bouwde.
De volgende stap is een gesprek over het proces waar bij jou de meeste pijn zit. Wij bouwen al ruim dertig jaar software voor zorg, onderwijs, industrie, overheid en energie, met 100+ projecten als bewijs. Plan een vrijblijvend gesprek en we bepalen samen wat de kleinste versie is die jouw aanname toetst.
