Het Minimum Viable Product (MVP) in Scrum begrijpen: Outcome vs. Output

Wat is een Minimum Viable Product, hoe leidt het werken ermee tot succes en welke enorme voordelen brengt dit allemaal voor jou, je team en je klanten?

In dit artikel leer je alles over het MVP en ontdek je waarom het verschil tussen Outcome en Output bepaalt of je product een succes of een mislukking wordt.

Verschil tussen Outcome en Output bij het MVP

Wie je een product voor je klanten ontwikkelt, zou zich eerst moeten afvragen welke behoeften deze klanten eigenlijk hebben en welke problemen het product moet oplossen. Zodra deze vragen beantwoord zijn, kan de ontwikkeling van het product beginnen, want pas dan is duidelijk welk resultaat (Outcome) de klanten wensen. Is het gewenste resultaat bijvoorbeeld dat klanten zich sneller van A naar B kunnen verplaatsen, dan zou het product (Output) een auto kunnen zijn. Maar dat hoeft niet, want ook een skateboard zou de gewenste Outcome leveren – en zou ten opzichte van de auto ook nog eens goedkoper en sneller te ontwikkelen zijn.

Interessant genoeg houden de meeste bedrijven zich vóór de productontwikkeling helemaal niet bezig met de Outcome voor de klanten: ze gaan uit van een vast productidee en richten zich uitsluitend op het leveren van precies deze Output met de bijbehorende werkpakketten en features.

De pure focus op output – een ondernemingsrisico

Waarom is deze aanpak zo risicovol en waarom kan de pure focus op output fatale gevolgen hebben voor een organisatie?

Wie volgens een Big-Bang-aanpak werkt, wil het product eerst voor 100% af hebben voordat het aan de klant wordt opgeleverd. Dit kan ertoe leiden dat:

• het bedrijf te veel tijd en geld in de ontwikkeling heeft gestoken,

• klanten het product niet meer nodig hebben, omdat een concurrent tijdens de lange ontwikkeltijd een betere variant op de markt heeft gebracht,

• de markt voor het product niet meer bestaat, omdat omstandigheden en behoeften zijn veranderd,

• niemand het product koopt, omdat het volledig langs de smaak en behoeften van de klanten heen is ontworpen,

• het product zo overdimensioneerd, complex en duur is geworden dat klanten de voorkeur geven aan een eenvoudiger en goedkoper alternatief van de concurrent.

Kort samengevat: het risico is groot dat bedrijven al hun resources gedurende een te lange periode vastleggen aan een star productidee, waarna het product uiteindelijk niet gekocht wordt. Hoe je dit probleem eenvoudig en agile kunt omzeilen? De oplossing heet: Minimum Viable Product.

Welke oplossing biedt het Minimal Viable Product in Scrum?

Als jij en je bedrijf al met Scrum werken, heb je er misschien al van gehoord: Minimum Viable Product (MVP) betekent het kleinste leverbare product. Als je bijvoorbeeld als Product Owner voor je bedrijf werkt, moet je je altijd richten op de outcome op basis van de klantbehoefte – in het bovenstaande voorbeeld is dat sneller van A naar B komen.

Wat precies een kleinst leverbaar product oftewel een Minimum Viable Product in de context van deze klantbehoefte kan zijn, laat de volgende afbeelding uit de blog van Crisp zien:

Natuurlijk staat de auto hier slechts als metafoor voor het product dat de klant oorspronkelijk wilde: zijn behoefte is om sneller van A naar B te komen, en hij denkt dat hij daar een auto voor nodig heeft.

Bij de werkwijze met het Minimum Viable Product zorg je er als Product Owner voor dat jij en je Scrum-Team in snelle, kleine iteraties de kleinst mogelijke leverbare producten (MVP's) aan de klant opleveren. Belangrijk hierbij is dat je altijd de gewenste outcome in het oog houdt en MVP's oplevert waarmee de klant zijn behoefte in ieder geval in de basis al kan vervullen:

De bovenste rij van de afbeelding laat zien dat het geen zin heeft om de klant simpelweg de eerste losse onderdelen van de auto te verkopen – daar kan hij zich zeker niet sneller mee van A naar B bewegen. De onderste rij laat daarentegen zien dat zowel een skateboard als een step, een fiets en een motor als MVP's aan de klant geleverd kunnen worden, want met elk van deze oplossingen is snellere voortbeweging mogelijk.

Welke voordelen biedt een MVP?

Het opleveren van MVPs aan klanten, testers en early adopters heeft de volgende grote voordelen:

• Je krijgt al heel vroeg in het ontwikkelproces feedback: Voldoet deze eerste productversie al aan de wensen van de klant? Werkt het zoals verwacht? Past het design? Zitten er misschien andere of aanvullende wensen achter de oorspronkelijke klantbehoefte?

• Snel leren zorgt voor grote vooruitgang: Als je na de eerste MVP-feedback al weet wat de klant belangrijk vindt en waar hij zonder kan, zal de tweede iteratie al een flinke verbetering laten zien.

• Aanpassingen zijn altijd mogelijk: De iteratieve ontwikkeling zorgt voor hoge flexibiliteit – in plaats van pas na 3 jaar ontwikkeltijd een afgerond eindproduct moeizaam opnieuw te moeten ontwerpen, kun je na elke iteratie zonder veel moeite wijzigingen doorvoeren.

• Je genereert al vroeg inkomsten: Omdat je al voor je eerste MVP's geld kunt vragen, minimaliseer je het ondernemersrisico aanzienlijk.

• Enthousiaste klanten door verlaging van aankoopprijs en ontwikkeltijd: Blijkt in ons voorbeeldscenario hierboven dat de klant al helemaal tevreden is met de fiets, omdat die in zijn behoefte voorziet, dan stop je als Product Owner de productontwikkeling precies op dat punt. Omdat je de fiets 1. sneller en 2. goedkoper hebt ontwikkeld dan een auto, kun je de klant vroegtijdig een bevredigende oplossing bieden die hem minder kost.

Een typisch Minimum Viable Product voorbeeld

Een goed MVP-voorbeeld is de snelwegtunnel op de A1 in Keulen: in plaats van zich te richten op de behoefte van omwonenden aan geluidsreductie en eerst kleinere, relatief goedkope maatregelen te leveren als Minimum Viable Product – zoals een snelheidslimiet, fluisterasfalt en geluidsschermen – en voort te bouwen op de feedback van omwonenden, hadden de verantwoordelijken alleen hun output voor ogen: een state-of-the-art geluidsbeschermingstunnel!

Na jarenlang bouwen en de bijbehorende verkeershinder is er een zogenaamde geluidsbeschermingstunnel ontstaan die 200 miljoen euro heeft gekost. Zoals de noodgedwongen veel te late feedback van omwonenden nu aantoont, heeft de tunnel het probleem niet opgelost – maar juist de geluidssituatie verergerd.

Waarom loont het om te werken volgens het MVP?

Juist wanneer het daadwerkelijke product nog niet helemaal duidelijk is en empirisch nog niet vaststaat dat klanten het precies zo en niet anders zullen kopen, is het doorslaggevend voor succes om in outcomes en klantbehoeften te denken en daar stap voor stap naartoe te werken met MVP's.

En zelfs bij producten waarvan je het totaalplaatje al kent, zoals bijvoorbeeld een vrachtwagen, kan het incrementeel opleveren van Minimal Viable Products de moeite waard zijn. Want misschien ontdekt je klant dat hij ook met aanzienlijk minder functionaliteiten tevreden is dan oorspronkelijk gedacht. En een klant die zijn oplossing sneller voor minder geld krijgt, is een uiterst tevreden klant.

Wil je meer boeiende feiten over het werken met Scrum en informatie over hoe agile werken je klanten tevredener en je organisatie succesvoller maakt? In onze Scrum Guide vind je alles wat je nodig hebt om de achtergronden te begrijpen. In onze gecertificeerde Scrum-trainingen leer je hoe je Agile in de praktijk toepast.

Wat is een product?

Lees wat een product in Scrum eigenlijk is en hoe je een productdefinitie opstelt.
=> Wat is een product?

Zo maak je van de Refinement een succes!

Bepaal als Product Owner de outcome voor de volgende Sprint en verbeter de resultaten uit het Refinement met deze tips.
=> Product Backlog Refinement

Hoe ontwikkel je een productvisie?

Ontdek hoe je als Product Owner in 3 simpele stappen een productvisie kunt ontwikkelen.
=> Productvisie ontwikkelen