Het nut van een Minimal Viable Product

Zijn we op de goede weg?

De term ‘Minimum Viable Product’, ooit bedacht door Frank Robinson en doorontwikkeld door SyncDev, is bekend geworden door de populaire boeken van Eric Ries over Lean Startup. Het idee achter een MVP is dat je een product of een stuk software ontwikkelt dat net genoeg features heeft om bruikbaar te zijn. Niet om daarmee vervolgens direct de markt op te gaan, maar om eens goed tegen het licht te houden en feedback te verzamelen.

Juist met die feedback kun je in een vroeg stadium aanpassingen maken aan het product of software, nog voordat het op de markt komt.Tevens helpt het je te focussen op de sterke onderdelen van het product en schrapt het onnodige delen, waarmee je dus tijd en geld bespaart. Wat je daarmee tegengaat is dat je zomaar in de wilde weg een product ontwikkelt waar niemand op zit te wachten; dat er aanbod wordt gecreëerd zonder vraag. Dat er zogezegd een lepel wordt ontwikkeld terwijl men om een vork verlegen zit.

Laten we alvast rijden, we zien wel waar we uitkomen.

Steeds vaker zien we echter dat het concept MVP in de loop der jaren als excuus gebruikt wordt. Het is een manier verworden om snel bochten af te snijden, niet goed na te denken over wat je nou precies wilt bereiken en daardoor te weinig tijd en energie in voorbereiding stopt. Het is tot een manier verworden om maar snel te beginnen.

Product owners en projectmanagers snijden steeds vaker de bocht af onder het mom van :” Ja maar het is een MVP, dus wat er nu niet aan klopt maken we beter in een volgende iteratie".

Bij veel startups (maar ook bij gewone bedrijven) is er dan ook vaak druk om te starten zonder dat men een heel scherp idee heeft van de richting. Vaak is er een ‘WAT’ we gaan bouwen en ‘HOE’, maar het ‘WAAROM’ en ‘VOOR WIE DAN’ wordt vaak met een MVP-mantel bedekt. Het komt dan ook zeer vaak voor dat startups, met veel tijd en effort een product/app lanceren dat niet aanslaat bij de behoefte van het grote publiek.

De eindbestemming hoeft nog niet helemaal niet in zicht te zijn, maar een globaal idee van de richting kan al een hoop schelen als er naar een product wordt gewerkt dat klaar voor lancering is.Het eindresultaat van deze manier van werken is dus soms totale desinteresse voor het product, maar soms loopt een lancering juist goed. Maar omdat er te kort is nagedacht tijd het MVP-proces is er na lancering vaak geen idee over doorontwikkeling, of wordt men geconfronteerd met de beperkingen van een haastig gekozen softwareplatform, of nog erger.

Wat kom je onderweg tegen?

Een mooi voorbeeld van de waarde van juist gebruik van MVP is bijvoorbeeld de mobiele internetbank Bunq. Nog voordat hun eerste klant een rekening had geopend, hadden ze bij Bunq de durf om zelfs tot drie keer toe alles op de schop te gooien. Honderden uren aan source code werden opnieuw geschreven en soms werd zelfs het hele ontwikkelplatform vervangen voor een ander.

Op een correcte manier gebruikmaken van MVP’s getuigt ook van lef hebben. Het is niet niks om honderden uren (lees=geld) aan source code aan de kant te schuiven, interne discussie en frustraties aan te gaan en voortdurend te schuiven met deadlines nog voordat er 1 euro verdiend is.

Met als resultaat dat ze, toen hun mobiele inter bank live ging, met een product (mobiel bankieren) op de markt kwamen dat nergens mee te vergelijken was en zoveel malen sneller en uitgebreider dan dat van hun huidige concurrenten (zoals ING, Rabobank, Triodos en Knab).

Zijn we er al?

Een MVP-proces volgen is bedoeld om software beter te maken. En om je een visie en basis te geven bij de doorontwikkeling, want dan begint vaak deel II van het proces (daar waar deel I toewerken naar de lancering is).

Mocht je er dus voor kiezen om via de MVP-methode een nieuw product te gaan ontwikkelen, neem dan in ieder geval de volgende punten in overweging:

• besteed meer aandacht aan het visualiseren van het concept/product, de visie;
• denk na over het ‘Waarom’ en het ‘Voor wie dan’;
• introduceer zo vroeg mogelijk een feedbackloop en wacht vooral niet tot de laatste iteraties voor livegang;
• een MVP is geen eindproduct maar een meetinstrument en een canvas;
• en last but not least: denk na over hoe je doorontwikkeling van je nieuwe product gaan inrichten na livegang.