Wat is een MVP? De kleinste versie die een echt probleem oplost, om te leren vóór je uitbouwt. Zo past EIGHTY8 dat toe: eerst één werkstroom.
Een MVP is de kleinste versie van een product die een echt probleem echt oplost. Niet een afgeronde demo, maar iets dat in de praktijk werkt en waarvan je leert hoe het gebruikt wordt. Het doel is bewijs verzamelen vóór het grote geld uitgegeven is. Wat werkt, bouw je uit; wat niet werkt, heb je niet half-af laten liggen.
Het begrip draait om één vraag: wat is het minimaal dat nodig is om het probleem weg te nemen? Niet wat aardig zou zijn, niet wat ooit in het plaatje past, maar het werkende minimum. Een MVP is dus geen halve versie van het uiteindelijke geheel. Het is een hele versie van een klein deel. Dat verschil bepaalt of er iets bruikbaars uit komt of een stripje dat niemand kan gebruiken.
In de bouw betekent het twee keuzes die tegen de intuïtie ingaan. De eerste: niet alles tegelijk. Eén werkstroom van begin tot eind (bijvoorbeeld alleen het intake-proces, van aanvraag tot klaargezette taak) werkt beter dan alle processen half. De tweede: met echte gebruikers en echte gegevens. Een MVP die alleen door het bouwteam met proefdata is aangeraakt, bewijst niets over het dagelijkse gebruik; het leerdoel zit juist in het bewijs dat collega's ermee kunnen werken.
Een voorbeeld: een transportbedrijf wil een volledig klantportaal met planning, facturatie en rapportages. De MVP is alleen de functie waar het meest werd gebeld: de actuele status van een zending, die de klant zelf kan raadplegen. Eén scherm, gekoppeld aan het bestaande planningsysteem. Zodra dat bewezen staat, wordt uitgebreid. En blijkt soms dat de rest van het idee anders uitvalt dan gedacht, omdat het gebruik het anders uitwijst.
De moeite waard is een MVP wanneer het idee kansloos of kansrijk kan zijn en de werkelijkheid dat nog moet uitwijzen. Bij een nieuwe werkstroom, een nieuwe doelgroep of een proces dat niemand ooit in software heeft gegoten. Ook bij een strak budget loont het: je koopt eerst bewijs, daarna uitbouw. En het past bij teams die snel iets bruikbaars willen, want een MVP levert alvast tijdwinst op het huidige handwerk, ook vóór de uitbouw begint.
Het loont niet als het probleem al uitgekristalliseerd is en de oplossing bekend staat: wie een tiende administratiekoppeling bouwt, leert weinig nieuws uit een proefversie. Let ook op de verleiding van de doorgeschoten MVP. Een proefversie die jaren onveranderd draait en waar iedereen omheen werkt. Een MVP zonder moment waarop je besluit om uit te bouwen, stil te leggen of te vervangen, is geen aanpak maar uitstel.
Onze standaardaanpak is een MVP in het klein: in de discovery de werkstroom met de meeste lekkage kiezen, die als eerste bouwen, in productie zetten bij echte collega's, en van daaruit uitbouwen. Wat niet meegenomen wordt, staat expliciet buiten scope. Dat is geen tekortkoming maar de kern van de aanpak. Elke fase wordt vooraf gescopet en op nacalculatie afgerekend, zodat de bewijsstap een bewuste keuze blijft.
Een proof of concept bewijst dat iets technisch kan; een MVP bewijst dat het in het dagelijkse werk waarde oplevert. De PoC staat vaak los van je systemen en wordt door het bouwteam getest; de MVP hangt aan echte gegevens, wordt door echte collega's gebruikt en mag niet stilletjes uitvallen. In de volgorde van een traject gaat de PoC meestal vooraf aan de MVP: eerst kán het, dan werkt het, dan bouw je uit.
De grens ligt bij het probleem zelf: een MVP is te klein zodra hij het probleem dat hij oplost niet meer volledig wegneemt. Een half werkend intakescherm dat collega's toch naast zich neerleggen, heeft geen leerwaarde. Het bewijst alleen dat het half werkend was. Vuistregel: kies één werkstroom en bouw die van begin tot eind, inclusief de controles die het werk in de praktijk vraagt. Liever één hele keten dan drie halve.
Nee, en dat is precies de bedoeling van het begrip: beter falen op kleine schaal dan na een grote bouw. Een MVP die in de praktijk niet gebruikt wordt, levert als bewijs op dat het idee in deze vorm niet werkt. En daarmee een besluit over richting, vóórdat het grote geld uitgegeven is. Wat wel verloren kan gaan is de inzet, maar die is bij de minimum-aanpak bewust klein gehouden. Faal snel, faal klein, en trek de conclusie.
Ja, en niet alleen door minder bouwen. Omdat er één werkstroom wordt uitgewerkt, is er ook minder afstemming nodig: minder schermen om te begrijpen, minder koppelingen om te controleren, minder collega's om te scholen. De eerste versie staat daardoor eerder in productie bij echte gebruikers. Een volledige oplossing blijft daarna gewoon mogelijk. De MVP bepaalt alleen de volgorde van bewijs, niet het plafond van het eindbeeld.
EIGHTY8