Bij elk experiment dat je doet is het belangrijk om je af te vragen wat de meest risicovolle aanname is en wat wil ik leren. Maar hoewel de theorie vrij eenvoudig is, is het moeilijk om goede experimenten te bedenken. Experimentontwerp is moeilijk, vooral omdat de meesten van ons ondernemers zijn en geen opgeleide wetenschappers. Dus in plaats van te veel te praten over wat goed experimenteerontwerp is, dat hebben we de laatste keer gedaan, geven we je een paar concrete voorbeelden:
Het probleem te valideren
Probeer je echt een probleem voor echte mensen op te lossen? Wij vertellen ondernemers vaak dat je de persoon wilt vinden die van zijn fiets is gevallen (We zijn tenslotte Nederlands) en zijn arm heeft gebroken. Zijn bot steekt uit en hij schreeuwt van de pijn. Die persoon zal alles doen en betalen om zijn probleem opgelost te krijgen. Je wil een pijnstiller bouwen, geen vitamine. Maar hoe valideer je dat?
Interview met de klant
Het klantinterview is bijna altijd de beste manier om te weten te komen of je een echt probleem oplost. Eerder schreven we al over hoe we effectieve klantinterviews kunnen voeren, dus daar komen we nu verder niet op terug..
De interesse valideren
Zodra je hebt gevalideerd dat er een daadwerkelijk probleem is, is het verstandig om eerst de interesse in een oplossing te testen, voordat je aan de slag gaat en een oplossing bouwt. Meestal doen we eerst nóg een ronde van klantinterviews, maar dan gefocussed op de oplossing in plaats van het probleem.
Daarna zijn er genoeg alternatieven:
Productwebsite (of landings page)
Een productwebsite is ideaal om je waardepropositie te testen en je interesse te valideren. Er zijn honderden kant-en-klare sjablonen beschikbaar en veel diensten om eenvoudig een landingspagina te maken, als zelfs een sjabloon te technisch voor je is. Wat belangrijk is bij het gebruik van een productwebsite is dat je om een soort investering van de klant vraagt. Een e-mailadres of een inschrijving is genoeg, maar mensen moeten je iets ‘betalen’ om echt hun interesse te tonen. Bezoekers en paginaweergaven zijn niet genoeg.
Uitlegvideo
Dropbox werd beroemd met hun uitlegvideo. Wanneer jouw product te complex is om gemakkelijk uit te leggen of te tonen, kan een uitlegvideo ideaal zijn. Het was moeilijk voor de jongens van Dropbox om de magie van Dropbox te tonen, voordat Dropbox bestond. Met een explainer video en opnieuw het vragen om een soort van investering, waren ze in staat om de interesse in Dropbox te valideren. Ze werden overweldigd door bèta-aanmeldingen.
Voorverkoop
Kickstart is het ideale voorbeeld van elk type van voorverkoop. Het wordt het meest gebruikt voor hardware, boeken en muziek. De pre-order is namelijk perfect wanneer het product moeilijk te bouwen is als een eenvoudige eerste versie. Bij het schrijven van een boek is het gemakkelijk om te beginnen met een productpagina en een of twee hoofdstukken weg te geven nadat de bezoeker met zijn of haar e-mailadres heeft ‘betaald’. Verder werkt een voorverkoop goed om te zien hoe gemakkelijk het is om een bepaald aantal boeken te verkopen. Ash Maurya doet dat momenteel met zijn nieuwe boek ‘Scaling Lean’.
Om de oplossing te valideren
Prototype
Wanneer je een ontwikkelaar vraagt om je eerste versie te bouwen, duurt het vaak maanden voordat deze is voltooid. De juiste frameworks moeten worden gebruikt, de juiste keuzes worden gemaakt, zodat het in de toekomst kan schalen. Maar wanneer je een ontwikkelaar om een prototype of proof-of-concept vraagt, kan dit vaak in twee weken wel worden gedaan. We houden ervan om iets in elkaar te hacken, vooral in de vroege fases. Ik ben er 100% zeker van dat de code die je in de eerste paar jaar schrijft later volledig herschreven zal worden, zelfs als je veel tijd en moeite in je (hoofd)lijnen steekt.
Zorg dat het prototype wordt gecreëerd met zo min mogelijk middelen en in zo weinig mogelijk tijd, om zo snel mogelijk je oplossing te testen. Alleen wanneer je klanten en gebruikers jouw product proberen, leer je echt wat ze willen. Als het niet schaalt, is het vaak een goed experiment. Maak gebruik van het conciërge-model van Wizard of Oz (later uitgelegd in deze blogpost) om moeilijk te bouwen componenten te verwijderen, gebruik webservices om alles uit te besteden wat niet jouw core-business is en rond die prototype in twee weken af.
Nep-knoppen / Smoke screens
In plaats van een functie te bouwen en vervolgens te kijken of mensen daadwerkelijk geïnteresseerd zijn, waarom niet enkel de knop aan je product toevoegen en zien hoeveel mensen klikken? Toen we voor het eerst wilden valideren of de gebruikers van ons portfoliostartup Study Credits geïnteresseerd waren in verschillende skins voor hun schoolagenda, hebben we een eenvoudige link toegevoegd met de tekst ‘Skin aanpassen’. We hebben de klik gekoppeld aan Mixpanel en een pagina weergegeven na een klik op de link waarin werd uitgelegd dat we een nieuwe functie aan het testen waren. Een week later hadden we ons antwoord: veel tieners wilden hun skin veranderen. Tijd voor het volgende experiment: kijken of en hoeveel ze bereid zijn te betalen.
Vorige week sprak ik met een startup die de nieuws-app van de volgende generatie aan het bouwen is. Ze hadden net 6 maanden gewerkt aan de ontwikkeling van een ‘breaking news’-sectie, van ontwerp en UX tot real-time pushmeldingen, enkel om erachter te komen dat de feeds die ze via hun platform aanbieden nooit enig breaking news hebben en dat hun gebruikers helemaal niet dit soort nieuws wilden van deze app. Daar gebruikten de gebruikers liever CNN of equivalenten daarvoor. Ze hadden zes maanden werk kunnen voorkomen door een nep knop toe te voegen, door via een Wizard of Oz-model pushmeldingen te sturen of door eerst hun gebruikers te interviewen.
Concierge model
Wat is dat conciërge-model dat ik noemde in het prototype-voorbeeld? Het doet dingen met de hand die een software-ontwikkelaar automatiseren zou. Toen Peerby hun verhuurmodel genaamd Peerby Go wilden testen, bouwden ze geen geheel nieuwe marktplaats en verhuursysteem. Hun oplossing was een eenvoudige landingspagina waar je in kon typen wat je wilde huren en aanvragen. Dat verzoek werd per e-mail doorgestuurd naar een van de medewerkers en die medewerker pakte de telefoon op, vond het juiste item in het oude Peerby-systeem of ergens bij een verhuurbedrijf, onderhandelde een prijs, fietste naar de locatie om het item op te halen en bracht het naar de klant. Het was alsof je een eigen conciërge had!
Je zult merken dat omdat de klant weet dat iemand de klus persoonlijk behandelt, de waardepropositie aanzienlijk hoger is dan het geautomatiseerde product dat je waarschijnlijk op schaal gaat maken. Let daar wel op!
Tovenaar van Oz
Het Tovenaar of Wizard of Oz model is vergelijkbaar met het Conciërge-model. Je gebruikt handenarbeid, van je eigen handen, een stagiair of een random persoon op Fiver, om taken in je backend te ‘automatiseren’ die nu te duur zijn om te bouwen (in tijd of middelen). Voor de klant lijkt het allemaal automatisch te gebeuren, maar je doet het eigenlijk met de hand. Het verschil met het conciërgemodel is dat de klant niet weet dat jouw Wizard of Oz-test handmatig wordt uitgevoerd, terwijl de klant zich bij het conciërgemodel bewust is van het feit dat iemand persoonlijk voor hun behoeften zorgt.
De Wizard of Oz-test probeert de real-world-implementatie van het product zoveel mogelijk te simuleren en heeft daarom dezelfde waardepropositie. Een Wizard of Oz-test is meer bedoeld om een oplossing te valideren dan om de beste manier te bedenken om een oplossing te implementeren, iets wat je beter kan testen met een Concierge-model.
Bij een van onze portfolio bedrijven testen we momenteel een chat-bot die niet echt een chat-bot is, maar een van de stagiairs die de berichten verzendt. Het zou te duur zijn geweest om echt een chat-bot voor de test te bouwen en dan te zien hoe effectief de functie zou zijn. In plaats daarvan reageert een van de stagairs met de hand op de berichten. Maar vertel dit alsjeblieft aan niemand! Net als de echte Wizard of Oz is dit een geheim.
Om omzet te valideren
Dry wallet
In het voorbeeld van de nepknop, schreven wij over de Study Credits test. We wilden zien hoeveel mensen geïnteresseerd waren in een andere skin voor hun digitale schoolagenda. Nadat we de vraag naar die functie hadden gevalideerd, wilden we weten hoeveel ze bereid waren te betalen. We hebben ditmaal een eenvoudig scherm gemaakt met 5 screenshots van verschillende skins en onder elke screenshot stond een koopknop met een prijs. In plaats van het hele betalingssysteem te bouwen, toonden we opnieuw enkel een bericht waarin we uitlegden dat we een functie aan het testen zijn, nadat de gebruiker op de knop ‘kopen’ zou klikken. We hebben drie verschillende prijzen voor verschillende skins toegevoegd om te zien of de prijs van belang was. We volgden de klikken met Mixpanel en twee weken later hadden we geleerd dat waarschijnlijk niet genoeg mensen bereid waren om skins te kopen om er een rendabel verdienmodel van te maken. We hadden er een paar maanden aan kunnen bouwen om te ontdekken dat het niet genoeg inkomsten zou genereren, nu hadden we hetzelfde geleerd na een dag!
Volgende stappen
Je experiment kan nutteloos zijn als je het niet goed ontwerpt. We schreven over het draaien van een goed experiment in onze Continue Experimenteren-blogpost. In de volgende blogpost zullen we ingaan op het documenteren en structureren van je experimenten om een overzicht te krijgen van je lessen in de loop van de tijd. Zonder jouw vooruitgang te documenteren, zodat je de lessen kan presenteren aan de rest van je team of zelfs jouw investeerders, is experimenteren maar half zo effectief. Je wil je NEXT Canvas kunnen bijwerken, zien hoe je experimenten jouw statistieken beïnvloeden en bepalen wanneer het tijd is om de NEXT step te nemen.
Experimenteer, leer, herhaal!
