In mijn eerdere blog Scrum en deadlines; vriend of vijand? refereerde ik naar de term MVP; Minimal Viable Product. Daar heb ik een fout gemaakt die veel gemaakt wordt. Het is namelijk Minimum Viable Product, niet minimal. De afkorting wordt tegenwoordig zoveel gebruikt dat we niet (meer) helder op het netvlies hebben waar een MVP voor staat of wat het precies inhoudt. De toepassing ervan is daarom ook niet altijd meer correct.
In dat blog gaf ik aan dat een MVP in feite bepaald wordt door hoog-over de features te benoemen. Deze features heb je nodig om het doel te realiseren dat je met je product of project wilt bereiken. Maar klopt dat wel?
Nee, dit is feitelijk niet wat een MVP is. Theoretisch is een MVP een product met dé set aan features die minimaal (Minimum) nodig is voor een levensvatbaar (Viable) product. Een versie waarmee je naar de markt kunt. Doel hiervan is om zo snel mogelijk te kunnen toetsen of het product voldoende potentie heeft. Maar zonder dat je direct een hele grote investering nodig hebt voor het gehele (eind)product. Daarnaast kun je op deze manier snel feedback van je klanten vergaren om het product door te ontwikkelen en beter te maken. Vereiste hierbij is wel dat er;
- een markt of groep mensen is die genoeg waarde zien in de eerste versie van het product om het te gaan gebruiken en;
- zij genoeg voordelen zien om het op lange termijn te blijven gebruiken.
Theorie vs. Praktijk
In de praktijk echter passen we het vaak anders toe. Niet alle projecten die wij bij Enrise doen zijn ‘greenfield’-projecten; een nieuw product of idee in de markt lanceren en toetsen. We verzorgen ook het uitfaseren van legacy en vervangen van bestaande systemen en webapplicaties.
Het gaat dan om applicaties die al een grote set aan (bewezen) features bevatten, die men minimaal in de eerste versie van het nieuwe product wil hebben voordat het live kan. “We kunnen toch niet met minder live gaan dan we nu al hebben?”.
Daarnaast zien managers en medewerkers bij het vervangen van bestaande applicaties vaak kans om langgekoesterde wensen door te voeren. Een fijn moment om pijnpunten en frustraties die er al tijden zijn weg te nemen. Dat vergroot de set met features enorm! Features die vaak helemaal niet (direct) nodig zijn of als nice to have bestempeld kunnen worden. Vaak denkt men in die gevallen niet na of het wel meerwaarde levert aan de applicatie en of klanten er wel op zitten te wachten. Maar we hebben wel met een budget en eventueel een deadline te maken.
MVP toepassen bij uitfasering of herbouw?
Op zo’n moment komt de term MVP vaak om de hoek kijken. Niet zuiver zoals de term bedoeld is, maar hiermee dwingen we onze klanten om goed na te denken over de features die echt nodig zijn. Of deze daadwerkelijk waarde leveren aan de applicatie. Eigenlijk gaat het om een eerste versie met alle must-haves erin, waarmee we live kunnen. Een Musthave Viable Product dus eigenlijk!
We voorkomen het opnieuw bouwen van de gehele applicatie. Proberen we daarmee de scope zo klein mogelijk te houden? Nee, het doel is niet om een zo klein mogelijk product te definiëren met een minimale set aan features, maar een product met waardevolle features die waarde (gaan) leveren en wellicht ook bestaande frustraties wegnemen.
Daarnaast voorkomen we de altijd spannende Big Bang bij livegang. Wat we hiermee bereiken is een aantrekkelijke eerste versie van het product. Daarmee kunnen we snel de markt op en feedback ophalen bij de eindgebruiker. Feedback waar je dan ook echt nog wat mee kunt doen in je tweede versie. Zo wordt het eindproduct ook daadwerkelijk beter dan deze voorheen was!
