MVP-validatiestrategie: wat je test en in welke volgorde

De meeste teams beginnen op de verkeerde plek. Ze bouwen een MVP, zetten het live, en gaan dan pas testen of mensen het willen. Maar op dat moment heb je al maanden tijd en budget besteed aan aannames die je nooit hebt getoetst.

Een goede MVP-validatiestrategie draait het om. Je begint met de vraag: welke aanname, als die fout blijkt, maakt het hele idee waardeloos? Die aanname test je als eerste. Niet als laatste.

Bij Livewall werken we regelmatig met organisaties die een digitaal product willen bouwen. Van loyaliteitsplatforms tot community-applicaties. En het patroon dat we steeds zien: teams die snel valideren, bouwen uiteindelijk betere producten. Niet omdat ze slimmer zijn, maar omdat ze vroeg leren welke richting het niet op moet.

De drie categorieën aannames

Elke MVP heeft aannames op drie niveaus:

Wenselijkheid — Willen mensen dit überhaupt? Lossen we een probleem op dat ze écht hebben?

Haalbaarheid — Kunnen we dit technisch en operationeel leveren op de manier die nodig is?

Levensvatbaarheid — Klopt het businessmodel? Verdienen we er genoeg aan om het vol te houden?

De meeste teams testen wenselijkheid als laatste, terwijl dat de aanname is die het vaakst fout blijkt. Test wenselijkheid altijd eerst. Pas als je weet dat mensen het willen, heeft het zin om te investeren in de rest.

Volgorde 1: valideer het probleem voor de oplossing

Voordat je ook maar één scherm bouwt, moet je weten of het probleem dat je oplost groot genoeg is. Dit klinkt voor de hand liggend, maar in de praktijk slaan teams deze stap over omdat ze verliefd zijn op hun oplossing.

Gesprekken met tien tot vijftien potentiële gebruikers zijn voldoende. Geen enquêtes. Geen meerkeuze. Vraag naar gedrag, niet naar meningen. 'Vertel me de laatste keer dat je dit probleem tegenkwam' levert meer op dan 'Zou je dit product gebruiken?'

Als je geen gedragspatroon vindt dat aansluit bij het probleem dat je oplost, stop dan. Of scherp je probleemstelling aan. De oplossing aanpassen is achteraf altijd duurder dan de richting nu bijstellen.

Volgorde 2: test de waardepropositie voor de interface

Als je weet dat het probleem bestaat, test dan of mensen je specifieke aanpak willen. Nog steeds zonder te bouwen.

Een landingspagina met een call-to-action werkt goed. Stuur er verkeer naartoe, meet wie zich aanmeldt of doorklikte. Niet om goedkeuring te krijgen, maar om gedragsintentie te meten. Er is een groot verschil tussen 'klinkt interessant' en 'ik wil dit nu hebben'.

Bij onze KLM Scalable Growth Case was de kernvraag niet 'kunnen we dit bouwen?', maar 'welk deel van dit systeem levert de meeste waarde op voor het minste productie-effort?' Die vraag vroeg om validatie van aannames over het gebruik, niet alleen over de techniek.

Volgorde 3: test het kritieke gebruikspad voor de randgevallen

Je hebt nu een MVP in de maak. Wat test je als eerste? Het kritieke gebruikspad. Dat is de reeks stappen die een gebruiker moet doorlopen om de kernwaarde van je product te ervaren.

Alles erbuiten, de instellingen, de welkomstmail, de helpknop, is randgeval. Randgevallen komen later. Het kritieke pad staat centraal.

Bij Sportvisunie was het kritieke pad eenvoudig te definiëren: een visser moet een vangst kunnen delen met zijn community binnen dertig seconden. Die flow werd als eerste getest. De rest van het platform volgde pas toen die kernactie goed werkte.

Volgorde 4: test met echte gebruikers voor je schaalt

Veel teams gaan live met een uitgerolde versie en meten dan of de KPI's kloppen. Maar 'live gaan' is niet hetzelfde als 'valideren'. Valideren doe je met een kleine groep echte gebruikers in een gecontroleerde omgeving, voordat je opschaalt.

Vijf gebruikers die hardop nadenken terwijl ze je product gebruiken leveren meer bruikbare inzichten op dan duizend sessies in je analytics. Kijk wat ze doen, niet wat ze zeggen. Observeer waar ze stoppen. Dat zijn je knelpunten.

Wat je niet moet doen: alles tegelijk testen

De valkuil van MVP-validatie is dat teams te veel aannames tegelijkertijd willen testen. Ze bouwen een 'snelle' versie die eigenlijk best uitgebreid is, zetten die live, en proberen dan te herleiden waarom het wel of niet werkt.

Als er drie dingen tegelijk veranderen, weet je niet welke aanpassing het verschil heeft gemaakt. Isoleer je variabelen. Test één aanname per keer, of in elk geval zo weinig mogelijk tegelijk.

Dit vereist discipline. Het vereist ook dat je van tevoren opschrijft wat je test, wat succes eruitziet, en wat de grens is waarop je besluit om door te gaan of bij te sturen. Zonder die criteria vooraf zul je na het experiment altijd een reden vinden om door te gaan.

De mindset: disproving, niet proving

Het doel van valideren is niet om gelijk te krijgen. Het is om zo snel mogelijk te weten of je het mis hebt.

Dit is een ongemakkelijke mindset, vooral als je al veel energie in een idee hebt gestopt. Maar de teams die het snelst goede producten bouwen, zijn de teams die het minst gehecht zijn aan hun eerste aanname.

Bij Livewall hanteren we bij MVP-ontwikkeling een eenvoudige vraag aan het begin van elk project: wat zou ons doen besluiten dit niet te bouwen? Als niemand die vraag kan beantwoorden, zijn we nog niet klaar om te beginnen.