Je zou kunnen stellen dat minimaal levensvatbare producten (of "MVP's") de best begrepen en tegelijkertijd de meest verkeerd gebruikte hulpmiddelen in het arsenaal van een digitale ondernemer zijn. Bijna iedereen die tegenwoordig een nieuw product bouwt, begint met een MVP. Toch zijn er maar weinig mensen in geslaagd dit hulpmiddel volledig onder de knie te krijgen en er het maximale uit te halen.
Laat me je daarom helpen MVP's te begrijpen, er op de juiste manier een te bouwen en hun volledige potentieel te benutten.
Wat is een minimaal levensvatbaar product (MVP)?
Als je deze vraag aan een groep ondernemers en productmanagers stelt, zullen de meesten antwoorden dat het minimaal levensvatbare product de versie van het product is die de minimale functionaliteit bevat die acceptabel genoeg is om op de markt te brengen.
En ja, technisch gezien hebben ze gelijk. Deze definitie is echter een beetje gebrekkig, omdat ze het kerndoel van de strategie voor productontwikkeling niet echt beschrijft. Dat is precies de reden waarom veel oprichters en productteams MVP's op de verkeerde manier gebruiken of iets een MVP noemen dat eigenlijk geen MVP is.
Sommige mensen denken dat het doel van een MVP is om vroegtijdig geld te verdienen. Hoewel dat mogelijk is, is het ook volkomen acceptabel als een MVP helemaal geen inkomsten oplevert. Dus als mensen je MVP-product niet kopen, moet je het nog niet meteen afschrijven.
Anderen denken dat een MVP bedoeld is om een klantenbestand op te bouwen dat in de ogen van durfkapitalisten die in je product willen investeren, zal bewijzen dat je product werkt.
Ook dat kun je doen, maar het is niet het doel van een MVP.
Dus, wat is een MVP?
Hoewel het concept van “klein beginnen, controleren of het idee levensvatbaar is en vervolgens uitbreiden” al sinds het begin van de geschreven geschiedenis bestaat, werd de formele (en mijn favoriete) definitie van een MVP ontwikkeld door niemand minder dan de grote Eric Ries. In zijn boek De Lean Startup benadrukt Eric het testen van je belangrijkste hypothesen als het voornaamste doel van een MVP.
Binnen de Lean Startup-mentaliteit maakt het eigenlijk niet uit hoe de MVP er precies uitziet, zolang:
Met andere woorden: voorbeelden van MVP's uit de praktijk zijn overal om ons heen te vinden, waaronder voorbeelden die nog niet eens werkende producten zijn. Zo lanceerde de kortingsbeheerdienst Groupon zijn MVP als een kleine WordPress-site die er als volgt uitzag.
Op deze site deelde het Groupon-team simpelweg dagelijks aanbiedingen met zijn doelgroep.
Er zijn nog veel meer voorbeelden van succesvolle producten waarvan de MVP-versie een landingspagina, een groep op sociale media of zelfs een videodemonstratie van een niet-bestaand product was (daarover later meer).
Waarom startups een minimaal levensvatbaar product nodig hebben
Er is een goede reden waarom MVP's zo populair zijn als strategie voor productontwikkeling onder oprichters van startups en productmanagers (ondanks het feit dat velen van hen het concept verkeerd interpreteren). Door een MVP-versie te bouwen kunnen startups in een vroeg stadium enkele van de grootste risico's die met het startupbestaan gepaard gaan, vermijden.
Ik zal er enkele uitlichten en laten zien hoe het bouwen van een MVP helpt om deze risico's te beperken.
1. Ze voorkomen vertraagde lanceringen
De digitale wereld is zo snel als maar mogelijk is. Een product twee kwartalen later lanceren dan alle anderen kan betekenen dat je marktaandeel verliest aan je concurrenten. Geloof me: gebruikers bij iemand anders weghalen is veel moeilijker dan een nieuwe gebruiker uit de open markt aantrekken.
MVP's lossen dit probleem op door gebruikers al vroeg aan je platform te binden. Hoewel je hun misschien niet het eindproduct biedt waar ze van droomden, zal een succesvolle MVP (ervan uitgaande dat deze je belangrijkste hypothesen valideert) gebruikers lang genoeg bij je houden om het uiteindelijke product te kunnen opleveren.
Om te begrijpen hoeveel tijd een MVP precies kan besparen, kun je deze grafiek bekijken, die ik heb samengesteld op basis van gegevens van Atlassian, Shopify en McKinsey.
Afhankelijk van het type product dat je bouwt, kun je negen maanden tot maar liefst twee volledige jaren besparen!
2. Ze beperken verzonken kosten
Het is absoluut geen probleem als de eerste versie van een nieuw product dat je uitbrengt mislukt—
en eerlijk gezegd zal dat waarschijnlijk ook gebeuren.
Het uitvalpercentage van startups is namelijk zo hoog (90%, volgens een rapport van CB Insights) dat je je meer zou moeten richten op het verlagen van de kosten van deze mislukkingen dan op de hoop dat je volgende product een enorm succes wordt.
MVP's zijn een van de beste hulpmiddelen om je daar precies bij te helpen. Ze helpen je om de behoeften van klanten in de markt te valideren aan de hand van je waardepropositie, met zo weinig mogelijk inspanning. Dit betekent dat je je bedrijfsidee kunt testen zonder de volledige levenscyclus van softwareontwikkeling te doorlopen met een langdurig ontwikkelingsproces. Dus voor de kosten van het maken van één volledig product kun je een dozijn MVP's maken en controleren of ze in de markt geliefd zijn.
Have an account? Log In
3. Ze voorkomen dat startups blindelings een product bouwen
Ik gebruik de term "blindelings bouwen" om te verwijzen naar de ontwikkeling van een product zonder veel inzicht in wat je beoogde gebruikers daadwerkelijk willen. Dit is waarschijnlijk de grootste fout die een ondernemer kan maken.
Het probleem met het maken van een volledig product met alle nieuwe functies op je routekaart en een kant-en-klare prijsstrategie is dat je geen idee hebt of mensen het goed zullen vinden totdat je het af hebt en uitbrengt.
Meestal zullen mensen het niet goed vinden en moet je je prijzen en functies opnieuw aanpassen. In sommige gevallen word je zelfs geconfronteerd met de realiteit dat je het product volledig moet schrappen of de prijsstrategie voor het product volledig moet wijzigen.
De beste manier om dit te voorkomen is om vroegtijdig feedback van gebruikers te verzamelen. Hoe doe je dat? Natuurlijk met een MVP!
Een minimaal levensvatbaar product bouwen: belangrijkste stappen
Nu we de theorie achter MVP's hebben behandeld, gaan we verder met de meer praktische onderdelen en bekijken we welke stappen nodig zijn om een MVP-concept te bouwen dat zijn belangrijkste doel goed kan dienen—je productlevensvatbaarheid in de markt laten testen.
Stap 1: identificeer een probleem dat moet worden opgelost
Elk geweldig product begint met een gebruikersprobleem dat moet worden opgelost. Dit proces bestaat uit twee deelstappen:
a) Het probleem identificeren: Dit is waar veel startups de fout in gaan—ze identificeren het verkeerde probleem.
Zo was het belangrijkste probleem in het vervoer aan het begin van de twintigste eeuw niet een gebrek aan snellere paarden of betere infrastructuur om paarden lange afstanden te laten afleggen. Het echte probleem was dat mensen behoefte hadden aan een betrouwbaarder vervoermiddel voor zwaar gebruik. Henry Ford identificeerde en loste dit probleem succesvol op door de auto te introduceren.
Een van de beste manieren om het juiste probleem te identificeren is het raamwerk van Vijf keer waarom.
b) Het probleem begrijpen: Het juiste probleem vinden om op te lossen is het halve werk. De andere helft draait om het begrijpen van de context en werkelijkheid waarin je gebruikers met dat probleem te maken hebben.
De automatisch gegenereerde ondertiteling van TikTok is bijvoorbeeld het resultaat van het inzicht van het productteam dat veel gebruikers TikTok bekijken in omgevingen waarin ze het geluid moeten dempen.
Hiervoor moet je gebruikersinterviews uitvoeren. Er is geen proces effectiever dan met je gebruikers praten om hun context te begrijpen.
Stap 2: bepaal de kernfuncties van de MVP
Je gebruikelijke productbacklog bevat meer functies dan je voor je MVP nodig hebt.
Om te bepalen welke functies binnen de scope van je MVP moeten vallen, raad ik je aan twee fantastische raamwerken voor functieprioritering te gebruiken:
Kanomodel: Hiermee groepeer je je functies in functies die je gebruikers enthousiast maken, lineair waarde aan hen toevoegen en van cruciaal belang zijn.
In het voorbeeld van een hotel is een aantrekkelijke functie de schattig uitziende origamihanddoek, is de prestatiefunctie de kwaliteit van de matras en is de basisvereiste het veilige slot op de deur van de hotelkamer.
Voor je MVP richt je je op de functies die absoluut noodzakelijk zijn.
MoSCoW: Dit is een eenvoudige oefening waarbij je je functies de statussen "Moet hebben", "Zou moeten hebben" en "Zou kunnen hebben" toekent. Functies die je moet hebben, zijn de functies die de belangrijkste gebruikssituatie afdekken.
Aan de hand van Spotify als voorbeeld is Zoeken een onmisbare functie. Afspeellijsten vallen daarentegen onder Zou moeten, en albumhoezen op het scherm weergeven valt onder Zou kunnen.
Voor een MVP richt je je op de functies die absoluut noodzakelijk zijn.
Stap 3: Bouw en test de MVP
Je MVP is geen MVP meer als je te veel tijd besteedt aan het bouwen ervan. Daarom raad ik aan om het volgende te gebruiken om je proces te versnellen:
- Ontwikkeling zonder code: Met Bubble en andere AI-aangedreven appbouwers kun je je eerste versie maken in een fractie van de tijd die nodig is om alles vanaf nul te coderen.
- Klikbare prototypes: Met moderne ontwerptools kun je je wireframes met hoge detaillering interactief maken, waardoor je tijd bespaart bij het coderen van een versie van je product.
- Sjablonen en low-codeframeworks: Vrijwel elke grote cloudprovider heeft kant-en-klare diensten waarmee je je ontwikkelproces aanzienlijk kunt versnellen.
Zodra je MVP is gebouwd, is het tijd om deze aan je gebruikers over te dragen. Je kunt platforms zoals AppSumo en Product Hunt gebruiken om je eerste gebruikers te verzamelen en feedback te verzamelen.
Stap 4: Meet succes en herhaal
Een van de kernconcepten van Lean Startup is het meten van de resultaten van je tests met een MVP en het herhalen ervan.
Door analysetools zoals Mixpanel, Amplitude en PostHog te integreren, kun je je resultaten eenvoudig meten.
Hier zijn enkele van de belangrijkste productstatistieken die je met deze tools kunt meten.
Het herhalen zelf is eenvoudig. Je bekijkt de feedback en kernstatistieken om verbeterpunten te identificeren, voegt deze verbeteringen toe aan de MVP en brengt een nieuwe versie uit om te testen.
Mijn enige advies hierbij is om regelmatig kleine releases uit te brengen. Zo begrijp je of je nieuwe functie de feedback of je statistieken heeft verbeterd.
Veelgemaakte MVP-fouten die je moet vermijden
Het klinkt misschien wat contra-intuïtief, maar ondanks de enorme populariteit van MVP's maken mensen steeds dezelfde fouten. De belangrijkste reden daarvoor is—je raadt het al—dat ze het kerndoel van een MVP verkeerd interpreteren.
Om je te helpen deze valkuilen te vermijden, wil ik de drie meest voorkomende benoemen:
1. Je MVP-versie te complex maken
Veel productteams beschouwen de MVP als de versie die klaar is om te verkopen, waarmee je de aansluiting tussen product en markt kunt testen. Niet echt. Daarvoor bestaat er een andere versie van je product: een MMP (minimum verkoopbaar product).
De MVP-versie is daarentegen veel kleiner en bedoeld om te testen of je idee aanslaat bij echte gebruikers.
2. Feedback negeren
De gebruikersreacties en gedragsanalyses die je krijgt door je MVP te testen, zijn goud waard. Het komt vaak voor dat een deel van deze feedback wordt genegeerd, in de veronderstelling dat gebruikers de definitieve versie toch leuk zullen vinden. Nee, dat zullen ze niet! Waarom zou je überhaupt een MVP-versie bouwen als je weigert de Lean Startup-methodologie van feedbacklussen creëren te gebruiken?
3. Te laat of te vroeg lanceren
Beide zijn problematisch. Als je te laat lanceert, verliest het hele concept van een MVP zijn betekenis. Maar pas ook op dat je niet te vroeg lanceert. Je MVP moet genoeg functies bevatten om je belangrijkste hypothesen te testen. Je testresultaten zijn misleidend als deze functies ontbreken.
4. MVP verwarren met prototypes
Deze twee termen kunnen wat verwarrend lijken. Een prototype is een interactief ontwerp dat je kunt gebruiken voor gebruikerstests. Hoewel het technisch gezien als MVP kan dienen, kun je ook een lichtgewicht versie van je product coderen als MVP.
Zo verschillen MVP's, prototypes en volledige producten van elkaar.
Zoals de bovenstaande infographic laat zien, komt het doel van prototypes overeen met dat van de MVP. Het enige verschil is het fysieke eindproduct van elk ervan.
Voorbeelden uit de praktijk van succesvolle MVP's
Het zou me niet verbazen als je nog steeds niet overtuigd bent van de effectiviteit van een MVP-strategie. Aangezien er talloze populaire tools en frameworks zijn die veel mensen niet bijzonder nuttig vinden, spreekt het idee om een "slecht eerste concept" van je product te bouwen niet iedereen aan.
Maar als senior productmanager die enkele echte treinongelukken in slow motion heeft zien gebeuren, is dit een standpunt waar ik voor zou sterven. Om mijn punt te bewijzen, laat ik je enkele voorbeelden zien van MVP-producten die zijn uitgegroeid tot technologiereuzen.
Dropbox
Weet je nog dat ik zei dat MVP's niet per se gecodeerde producten hoeven te zijn? De MVP-versie van Dropbox was namelijk een videopresentatie!
In deze video toont de oprichter van Dropbox eenvoudigweg het concept voor een product dat nog niet was gecodeerd. Het resultaat van deze presentatie was echter een enorme toestroom van mensen die zich aanmeldden om toegang te krijgen tot het product zodra het klaar was. Dit was voor het Dropbox-team het signaal dat ze op de goede weg waren.
Airbnb
Ons favoriete platform, dat verantwoordelijk is voor het veroorzaken van woningmarktcrises in veel toeristische steden (ja, in Florence, Italië, werd het om die reden zelfs verboden!), begon ook als een niet-traditioneel MVP.
De oprichters van het bedrijf testten de levensvatbaarheid van hun bedrijfsmodel door bedden in hun appartement in San Francisco te verhuren aan verschillende deelnemers aan een conferentie. Ze wilden weten of mensen zich comfortabel zouden voelen bij het huren van een bed of kamer in het appartement van iemand anders.
Het antwoord op die vraag was ja! De markt gaf de oprichters dus groen licht om een platform te gaan bouwen op basis van dat precieze idee.
Zappos
De manier waarop Zappos zijn MVP benaderde, staat in de productwereld bekend als testen volgens het “Tovenaar van Oz”-principe. In dit scenario bouw je een website voor je product, maar wordt alle verwerking aan de achterkant door mensen uitgevoerd in plaats van door machines.
Het Zappos-team lanceerde zijn online schoenenwinkel als een website zonder verwerking aan de achterkant. Wanneer gebruikers schoenen bij hen bestelden, kocht het team die ergens anders en stuurde ze naar de gebruikers. Nadat ze van de markt bevestiging hadden gekregen dat dit model werkte, begonnen ze de achterkant van hun product te bouwen.
Hoewel dit de drie populairste verhalen zijn over MVP's die goed zijn uitgevoerd, zijn er nog veel meer succesvolle MVP's die zijn uitgegroeid tot zeer succesvolle producten.
Tools en hulpmiddelen voor het bouwen van je MVP
Het laatste deel van onze MVP-gids gaat vandaag over de selectie van software voor productontwikkeling en educatief materiaal waarmee je de efficiëntie en effectiviteit van het bouwen van een MVP, het testen van je hypothesen met vroege gebruikers en het verwerken van gebruikersfeedback kunt verbeteren.
Laten we beginnen met de tools.
- Snel prototypen en gebruikerservaring: Figma, InVision, Sketch, Framer en andere alternatieven.
- Workflowbeheer: Kanbanborden zoals Jira, Monday.com en Trello.
- Analyse: Mixpanel, Amplitude en PostHog.
- Identificatie van de doelgroep: Reddit en Similarweb.
- Verwerking van klantfeedback: Typeform, SurveyMonkey en Google Forms.
En als je het nog niet hebt gelezen, raad ik je ten zeerste aan om te beginnen met het boek Lean Startup als de beste bron voor uitleg over de MVP-benadering binnen de algemene structuur van bouw-meet-leercycli.
Vergeet niet je te abonneren op onze nieuwsbrief voor meer bronnen en gidsen over productmanagement, plus de nieuwste podcasts, interviews en andere inzichten van leiders en experts uit de sector.