Gepubliceerd op: 11 maart 2020

In een eerdere blog schreef ik over de waarde van iteratief werken en het combineren van meerdere methodieken om zo razendsnel oplossingen te ontwikkelen, valideren en realiseren. Een belangrijk onderdeel hiervan ging over het werken met een minimum viable product (MVP) en het toetsen van riskante aannames op weg naar een gevalideerde oplossing voor je doelgroep.

Hoewel het werken met een MVP een waardevolle toevoeging vormt binnen een innovatieproces merk ik in de praktijk dat zowel teams en het management binnen organisaties hier vaak moeite mee hebben. Veelgenoemde redenen die ik hierbij tegenkom zijn:

  • Verschillen in interpretatie over wat een MVP nou eigenlijk is en voor wie de MVP bedoeld is
  • Verwachtingen over het minimale volwassenheidsniveau van een MVP of oplossingen waarmee de organisatie naar buiten treedt
  • Complexiteit van het balanceren tussen ‘minimum’ en ‘viable’ en het geven van opvolging aan een MVP

Met als resultaat dat vaak terug wordt gegrepen op de vertrouwde niet-zo-agile werkwijze en het ontwikkelen van een MVP die eigenlijk helemaal geen MVP meer te noemen is. Maar wat is een MVP dan precies en voor wie maak je een MVP? Waarom is het belangrijk om ermee te werken en hoe bepaal je dan je MVP?

Wat is dan een MVP?

De term MVP is eigenlijk helemaal niet zo nieuw als je zou denken. Het idee om te werken met een MVP vindt zijn oorsprong namelijk in invloedrijke denkers waaronder Frank Robinson (2001) en Steve Blank (2005).

MVP

De term heeft echter vooral sinds de komst van het boek de The Lean Startup van Eric Ries (2011) flink aan populariteit gewonnen.

The minimum viable product is that version of a new product which allows a team to collect the maximum amount of validated learning about customers with the least effort. -Eric Ries

Een MVP is daarmee een sterk uitgeklede versie van de uiteindelijke oplossing die als doel heeft om zo veel mogelijk feedback te ontvangen over hetgeen je met de oplossing wil bereiken. Daarmee verschilt deze definitie dus van een gangbare definitie die ik veel tegenkom dat een MVP ook letterlijk de meest minimale set aan functionaliteiten van een product of dienst is die het mogelijk maakt om het in te zetten.

Het grootste argument om te werken met een MVP is dat het je in staat stelt om op een laagdrempelige manier te toetsen of de oplossing die je voor ogen hebt überhaupt gebouwd moet worden. Hierdoor reduceer je de benodigde initiële investering, ben je in staat om iteratief aanpassingen door te voeren en verhoog je de time-to-market.

As you consider building your own minimum viable product, let this simple rule suffice: remove any feature, process, or effort that does not contribute directly to the learning you seek. – Eric Ries

Voor wie maak je een MVP?

Bij het werken met een MVP is het noodzakelijk om de balans tussen ‘minimum’ en ‘viable’ in het oog te houden. Wanneer je je namelijk te veel richt op het minimaliseren van een MVP, bestaat het risico dat je functies die voor de klant van essentieel belang zijn, uitsluit.

MVP

Het is daarom essentieel om een goed beeld te hebben van je doelgroep, wat drijft en wat de achterliggende behoeften en/of problemen zijn. Tegelijkertijd is het belangrijk om je ervan bewust te zijn dat je MVP niet geschikt is voor iedereen. Sterker nog, een MVP zal veel van je doorsnee klanten teleurstellen. Dit komt doordat een MVP slechts de kern bevat van je gehele oplossing. Een MVP zou volgens Steve Blank dan ook vooral gericht moeten zijn op de zogenaamde ‘Earlyvangelist’.

MVP

Dit zijn overwegend juist die klanten die je net wat vergevingsgezinder zijn dan een gemiddelde klant en die als early adopters graag oplossingen uitproberen en meedenken over de richting. Feedback uit deze groep, en de inzichten hieruit, kun je daarmee goed gebruiken om iteratief je oplossing verder te ontwikkelen en/of te besluiten om van strategische richting te veranderen. Hierdoor kun je een nauwe relatie met je initiële gebruikers opbouwen.

Most customers will not want a product with a minimal feature set. In fact, the majority of customers will hate it. So why do it? Because you are selling the first version of your product to Earlyvangelists. -Steve Blank

Werken met een MVP als gevestigde organisatie

De keuze om met een sterk uitgeklede versie van de uiteindelijke oplossing naar buiten te treden biedt veel voordelen. Helaas staat dit echter vaak haaks op de verwachtingen van een gevestigde organisatie over het minimale kwaliteitsniveau van een oplossing. Dit komt veelal door zorgen over de perceptie van de oplossing door de doorsnee klanten en de mogelijke reputatieschade van een MVP die niet aan deze verwachtingen voldoet.

Het resultaat hiervan is dat MVP’s regelmatig dusdanig compleet worden ontwikkeld dat ze eigenlijk helemaal geen MVP’s meer te noemen zijn. Deze risicoaversie staat dan ook haaks op de redenen om juist voor een MVP te kiezen.

MVP

De realiteit is dat het werken met MVP’s in gevestigde organisaties lastig is. Als middenweg kun je er daarom voor kiezen om de MVP als een tussenstap te gebruiken op weg naar de lancering van een exceptional viable product (EVP), bedacht door Rand Fishkin (2018).

My proposal is that we embrace the reality that MVPs are ideal for some circumstances but harmful in others, and that organizations of all sizes should consider their market, their competition, and their reach before deciding what is “viable” to launch. I believe it’s often the right choice to bias to the EVP, the “exceptional viable product,” for your initial, public release. – Rand Fishkin

Hierbij gebruik je nog steeds een MVP voor het valideren, leren en itereren van je oplossing maar doe je dit initieel voor een kleinere groep gebruikers die ook weten dat ze meehelpen om de oplossing beter te maken. Door niet gelijk publiekelijk te lanceren voorkom je namelijk veel van de fricties die anders kunnen ontstaan. Pas wanneer je MVP echt uitzonderlijk is, lanceer je deze voor een breder publiek.

Key takeaways

Om terug te komen op mijn originele vraag hoe je een waardevolle MVP bepaalt is het antwoord dat dit dus per situatie verschilt. Tegelijkertijd zijn er zeker wel een aantal best practices die je voor iedere situatie kan inzetten. Om je hierbij een beetje op weg te helpen hierbij mijn takeaways voor het werken met een MVP:

  • Vorm allereerst een helder beeld over je doelgroep, wat hen drijft en wat de achterliggende behoeften en/of problemen zijn
  • Bepaal vooraf welke riskante aannames je wil valideren
  • Maak een MVP niet te groot (maar vooral ook niet te klein), het is balanceren tussen ‘minimum’ en ‘viable’
  • Wees je ervan bewust dat een MVP niet voor iedereen geschikt is en vooral bedoeld is voor je vergevingsgezinde ‘Earlyvangelists’
  • Maak waar mogelijk gebruik van simpele prototypes voordat je aan een complexere MVP begint
  • Maak een afweging of je binnen de context van jouw organisatie met een MVP live kan gaan of toch liever voor een EVP kiest
  • Maak bij het lanceren van je MVP optimaal gebruik van de feedback die je ontvangt om iteratief je oplossing verder te ontwikkelen en/of te besluiten om van strategische richting te veranderen
  • Wees je ervan bewust dat je na het lanceren van een MVP niet klaar bent maar juist net begonnen bent

Afsluitend wil ik je als lezer toch graag uitdagen om vooral ook zelf het werken met een MVP uit te proberen en te kijken wat het voor jou en je organisatie oplevert. Of zoals mijn zoon van vier jaar zou zeggen: “proberen is leren”!

Meer weten over Lean Startup en MVP’s?

Wil je meer weten over Lean Startup, MVP’s, EVP’s en hoe ik dit toepas voor mijn opdrachtgevers? Neem dan eens een kijkje op onze site of neem contact met mij op. Ik vertel je graag meer over mijn ervaringen.

Visuele beelden door Paul Stellingwerf.