Wat is een MVP? Betekenis van minimum viable product

Een MVP (minimum viable product) is de eenvoudigste versie van een product die echte gebruikers al echt helpt. Je bouwt alleen wat nodig is om één kernprobleem op te lossen, zet dat bij gebruikers neer en leert van hun gedrag wat je daarna bouwt. In het Nederlands: een minimaal levensvatbaar product.

De afkorting MVP kom je in twee werelden tegen. In de sport betekent ze Most Valuable Player, de beste speler van een wedstrijd of seizoen. In het bedrijfsleven en bij softwareontwikkeling betekent MVP altijd minimum viable product. Over die tweede betekenis gaat dit artikel.

Wat betekent minimum viable product precies?

De drie woorden zeggen samen wat een MVP is.

• Minimum: zo klein als het kan. Alles wat niet nodig is om het kernprobleem op te lossen, laat je weg.
• Viable: levensvatbaar. Het product moet werken en waarde leveren. Een gebruiker moet er een echte taak mee kunnen afronden.
• Product: geen tekening, geen presentatie, maar iets wat mensen gebruiken in hun eigen situatie.

Het doel van een MVP is niet om snel iets online te hebben. Het doel is leren. Je wilt met zo weinig mogelijk bouwwerk ontdekken of je aanname klopt: hebben mensen dit probleem, lost jouw oplossing het op en zijn ze bereid ervoor te betalen of hun manier van werken te veranderen?

Waar komt de term MVP vandaan?

De term wordt toegeschreven aan Frank Robinson, die hem rond 2001 gebruikte. Bekend werd hij via de lean-startupbeweging, met Steve Blank en vooral Eric Ries. In zijn boek The Lean Startup (2011) omschrijft Ries de MVP als de versie van een nieuw product waarmee een team met de minste moeite het meeste leert over zijn klanten.

Ries koppelt de MVP aan een vaste cyclus: bouwen, meten, leren. Je bouwt iets kleins, meet hoe mensen het gebruiken, trekt daar een conclusie uit en past het product aan. Een MVP is dus geen eindpunt. Het is de eerste ronde van die cyclus.

Wat een MVP niet is

Rond de term bestaan veel misverstanden. De drie die het vaakst geld kosten:

• Geen half product. Een MVP doet weinig, maar wat hij doet, doet hij goed. Een app met tien halve functies is geen MVP. Een app met één functie die goed werkt wel.
• Geen prototype. Een prototype laat zien hoe iets eruit kan zien of werken. Een MVP wordt echt gebruikt, met echte gegevens en echte gevolgen.
• Geen goedkope versie van het eindproduct. Wie de MVP ziet als budgetvariant van het hele plan, bouwt te veel en leert te weinig.

MVP, prototype, proof of concept en MMP: het verschil

Deze vier begrippen worden vaak door elkaar gebruikt. Ze beantwoorden elk een andere vraag.

• Proof of concept (PoC): kan het technisch? Je test of een idee uitvoerbaar is, bijvoorbeeld of een koppeling of een AI-model doet wat je verwacht. Gebruikers zien het meestal niet.
• Prototype: hoe ziet het eruit en snappen mensen het? Je test de vorm en de bediening, vaak met een klikbaar ontwerp zonder werkende achterkant.
• MVP: willen mensen het echt gebruiken? Je test de waarde, met een werkend product bij echte gebruikers.
• MMP (minimum marketable product): kun je het verkopen aan een bredere markt? Het MMP is de eerste versie die je actief op de markt zet, met alles wat daarbij hoort, zoals betalingen, onboarding en support.

De volgorde is niet altijd PoC, prototype, MVP, MMP. Is de techniek bekend, dan sla je de proof of concept over. Is het gedrag van gebruikers de grote onbekende, dan begin je soms meteen met een MVP.

De voordelen van een MVP

• Je leert eerder. Je ziet wat gebruikers doen voordat het grootste deel van je budget op is.
• Je bouwt minder wat niemand gebruikt. Functies komen er pas bij als blijkt dat ze nodig zijn.
• Je beperkt het risico. Klopt de aanname niet, dan ontdek je dat met een kleine investering en kun je bijsturen of stoppen.
• Je hebt bewijs voor de volgende stap. Gebruiksdata en reacties van echte gebruikers overtuigen een directie of investeerder meer dan een plan.
• Je product groeit op de juiste fundering. Een goed opgezette MVP is het begin van het echte product, niet iets wat je weggooit.

Valkuilen: waar het misgaat

• Te veel erin stoppen. De verleiding is groot om nog één functie toe te voegen. Elke extra functie maakt de bouw langer en de uitkomst minder scherp.
• Te weinig erin stoppen. Een product dat het probleem niet echt oplost, levert geen bruikbare informatie op. Dan weet je niet of het idee slecht is of de uitvoering.
• Geen meetplan. Zonder vooraf vastgelegde vraag en meetpunten weet je achteraf niet wat de MVP heeft bewezen.
• De verkeerde gebruikers. Collega's en vrienden zijn vriendelijk. Je hebt mensen nodig die het probleem echt hebben.
• Een fundering die niet kan groeien. Snel bouwen is iets anders dan slordig bouwen. Wie beveiliging, datamodel en beheer overslaat, bouwt de tweede versie opnieuw.

Hoe zet je een MVP op? In zes stappen

1. Begin bij het probleem

Beschrijf voor wie je bouwt en welk probleem je oplost. Niet de oplossing, maar de situatie. Wat doet je gebruiker nu, wat kost dat en waarom is het de moeite waard om te veranderen?

2. Maak je belangrijkste aanname expliciet

Elk productidee rust op aannames. Kies de aanname die het hele idee laat vallen als hij niet klopt. Bijvoorbeeld: klanten willen hun aanvraag zelf online indienen in plaats van te bellen. Die aanname test je met de MVP.

3. Bepaal hoe je het meet

Leg vooraf vast wanneer de MVP geslaagd is. Hoeveel gebruikers ronden de kerntaak af? Komen ze terug? Zijn ze bereid te betalen? Een concreet criterium voorkomt dat je achteraf elke uitkomst als succes uitlegt.

4. Schrap tot alleen de kern overblijft

Zet alle functies op een lijst en vraag bij elke functie: is die nodig om de aanname te testen? Zo niet, dan gaat hij naar later. Wat overblijft, is vaak één route van begin tot eind voor één type gebruiker. Inloggen met een eigen wachtwoordsysteem, uitgebreide instellingen en een beheeromgeving voor alles kunnen meestal wachten.

5. Bouw klein, maar degelijk

Kies techniek die kan meegroeien en regel de basis goed: beveiliging, privacy en een datamodel dat uitbreiding aankan. Wat handwerk mag blijven, mag handwerk blijven. Een mail die een collega nog met de hand verstuurt, is in een MVP prima.

6. Lanceer, meet en beslis

Zet de MVP bij echte gebruikers neer, verzamel data en praat met ze. Daarna volgt één van drie beslissingen: doorbouwen, bijsturen of stoppen. Alle drie zijn een goede uitkomst, zolang je ze baseert op wat je hebt gezien.

Voorbeelden van een MVP

Een MVP hoeft niet eens software te zijn. Een paar vormen die vaak werken:

• Landingspagina: je beschrijft het product en meet hoeveel mensen zich aanmelden voordat er iets gebouwd is. Je test de vraag, niet de oplossing.
• Concierge-MVP: je levert de dienst eerst met de hand, voor een kleine groep klanten. Zo leer je precies welke stappen je later automatiseert.
• Wizard of Oz: voor de gebruiker lijkt het automatisch, maar achter de schermen doet een mens het werk. Handig als de techniek duur is en de vraag nog onzeker.
• Eén-functie-product: een webapplicatie of app die één taak goed doet. Denk aan een klantportaal waarin klanten alleen hun aanvraag indienen en de status volgen, zonder alle andere functies die later komen.
• Intern eerst: een nieuw platform gaat eerst naar één afdeling of één groep klanten voordat je het breed uitrolt.

Wat kost een MVP en hoe lang duurt het?

Daar is geen vast antwoord op, en wie dat wel geeft zonder je plan te kennen, raadt. De kosten en de doorlooptijd hangen af van een paar factoren:

• het aantal gebruikersrollen, zoals klant, medewerker en beheerder;
• het aantal koppelingen met bestaande systemen;
• het platform: alleen web, of ook een app voor iOS en Android;
• de eisen aan beveiliging, privacy en toegankelijkheid;
• hoeveel er al vastligt aan ontwerp en processen.

De grootste kostenpost is bijna altijd de scope. Elke functie die je schrapt, maakt de MVP sneller en goedkoper. Plan in weken, niet in kwartalen: hoe langer de bouw duurt, hoe later je leert. Een uitgebreider overzicht van de kostenposten staat bij wat een online platform laten bouwen kost.

Wanneer is een MVP niet de juiste stap?

Een MVP is bedoeld voor onzekerheid. Weet je al precies wat er nodig is, bijvoorbeeld omdat je een bestaand intern systeem vervangt waarvan het gebruik vastligt, dan helpt een minimale versie je weinig. Dan is de vraag eerder of je iets moet laten bouwen of een standaardpakket kunt kiezen. Die afweging staat in maatwerksoftware of standaardpakket.

Ook in sectoren waar een product vanaf de eerste dag aan strenge eisen moet voldoen, zoals bij medische of financiële toepassingen, is het minimum hoger. Het principe blijft hetzelfde: bouw alleen wat nodig is om te leren, maar dat minimum omvat dan ook de verplichte eisen.

Hoe Your Tech Club helpt bij een MVP

Wij beginnen niet bij de techniek maar bij de vraag wat er beter moet worden, en voor wie. Eerst de kans, dan de technologie. Samen bepalen we welke aanname de MVP moet toetsen, wat erin moet en wat kan wachten.

Daarna bouwen we de eerste versie zo dat hij kan doorgroeien naar het echte product. Dat kan een webapplicatie zijn, een klant- of partnerportaal of het begin van een SaaS-product. Na de lancering meten we wat gebruikers doen en verbeteren we op basis daarvan. Hoe we digitale producten van idee tot platform brengen, staat bij digitale producten en platforms.

Heb je een productidee en wil je weten wat de kleinste versie is die al waarde levert? Plan een kennismaking en neem je idee mee.