Naar de inhoud

Zo stel je een experimentenroadmap op

Een experimentenroadmap is een geprioriteerde backlog van de tests die je als volgende draait, gescoord zodat een klein team zijn paar experimentplekken besteedt aan de ideeën met de hoogste verwachte waarde. Hij maakt van een stapel losse ingevingen een gerangschikte rij, legt een ritme voor evaluaties vast en dwingt de moeilijkste beslissing af: wat je schrapt.

Bijgewerkt op 6 min. leestijdDoor fromHello

In het kort

  1. Prioriteren telt het zwaarst als je maar een paar tests kunt draaien – elke plek die naar een zwak idee gaat, is een sterker idee dat je overslaat.

  2. Scoor ideeën met ICE (Impact x Confidence x Ease) om een backlog snel te rangschikken; pak RICE erbij als het bereik sterk verschilt. Beide zijn schattingen, geen waarheid.

  3. Bouw de backlog op vanuit de plekken waar je funnel lekt en vanuit het aha-moment van je activatie, niet vanuit een verlanglijstje.

  4. Evalueer in een vast ritme en schrap verliezers volgens planning – reken erop dat de meeste tests vlak terugkomen.

Waarom prioriteren alles is

Een klein team draait misschien twee of drie experimenten per week; alleen teams met een hoog tempo halen er tien tot twintig – en zelfs dat is krap als het verkeer dun is. Met zo weinig plekken zijn de echte kosten van een middelmatige test niet de test zelf, maar het sterkere idee dat je ervoor oversloeg. Een roadmap bestaat zodat elke plek naar het idee met de hoogste verwachte waarde gaat, niet naar de luidste stem in de stand-up. Die gerangschikte rij beheren is een groot deel van wat een Growth PM doet.

Bouw de backlog op vanuit je funnel en je aha-moment

Begin niet bij een verlanglijstje. Begin waar de funnel lekt. Loop elke stap langs – bezoek, aanmelding, activatie, retentie, omzet – en schrijf de grootste uitval op; elk lek is een toetsbare hypothese. Geef de stappen die het dichtst bij het aha-moment van je activatie liggen veel gewicht, want een gebruiker die nooit activeert, blijft zelden. Behandel elk aha-moment dat je aanwijst als een samenhang om te toetsen, niet als een bewezen oorzaak: een activatiesignaal voorspelt retentie, het bewijst niet dat jij die veroorzaakte. Elk lek wordt een rij in de backlog – de hypothese, de metric die ze moet bewegen en een ruwe schatting van hoeveel.

Scoor ideeën met ICE

ICE, populair gemaakt door Sean Ellis, scoort elk idee op drie assen van 1 tot 10: Impact, hoeveel het de metric kan bewegen; Confidence, hoe zeker je bent dat het werkt; en Ease, hoe weinig moeite het kost. Vermenigvuldig de drie, sorteer van hoog naar laag en werk van boven naar beneden. Het is snel omdat het drie eerlijke gokken zijn. Die snelheid is ook de keerzijde: de score is een schatting, geen feit. Lees een 512 en een 480 als ongeveer gelijk, niet als een definitief oordeel. Het getal zet de lijst op volgorde; het beslist niet voor je.

Zet elk idee uit naar impact en moeite. Snelle winst – grote impact, weinig moeite – krijgt je schaarse plekken als eerste; tijdvreters verdienen zelden een plek.

Verschilt het bereik, gebruik dan RICE

ICE schiet tekort als twee ideeën sterk verschillen in hoeveel gebruikers ze raken. RICE, van Intercom, lost dat op door Reach toe te voegen en te delen door Effort: (Reach x Impact x Confidence) / Effort. Een helptekst die elke bezoeker ziet en een aanpassing die diep in een instellingenpagina zit, worden dan op gelijke voet gescoord. Je ruilt snelheid in voor een schatting van het bereik die je moet onderbouwen. Dezelfde waarschuwing geldt – vier verzonnen getallen vermenigvuldigen kan schijnprecisie opleveren, dus houd de invoer grof en herzie die naarmate je meer leert.

FactorICERICE
FormuleImpact x Confidence x Ease(Reach x Impact x Confidence) / Effort
SnelheidSnel – drie gokken van 1–10Trager – vraagt een getal voor het bereik
Ideaal voorEen grote backlog snel triërenIdeeën waarvan het bereik sterk verschilt
Grootste valkuilEase verbergt de echte moeiteSchijnprecisie door zachte invoer

Evalueer in een vast ritme en schrap verliezers

Kies een vast ritme – een evaluatie per week of per twee weken waarin je resultaten leest, winnaars doorvoert en de rest afvoert. Volgens planning schrappen is de discipline die de rij in beweging houdt; een test die blijft draaien, is een plek die bezet blijft. Wees eerlijk: de meeste tests komen vlak terug, en bij weinig verkeer hebben veel tests al te weinig power voordat ze beginnen – vaak is de juiste keuze om helemaal niet te A/B-testen, maar te lanceren en te monitoren, zoals testen met weinig verkeer uitlegt. Meet je wel, dan heb je voor een zuivere meting meestal een holdoutgroep nodig, die een platform als customer.io of een zelf gehoste engagementstack voor je apart kan houden.

FAQ

Veelgestelde vragen

  • Op hoeveel experimenten moet een klein team rekenen?

    Minder dan je denkt. Twee of drie goed uitgevoerde tests per week is voor de meeste kleine teams een realistisch plafond, en zelfs sterke growthteams komen zelden boven de tien tot twintig. Plan de roadmap rond het aantal plekken dat je echt hebt, niet rond een wensbeeld.

  • Is ICE of RICE beter?

    Geen van beide is “beter” – ze beantwoorden verschillende vragen. Gebruik ICE om een grote backlog snel te triëren als ideeën ongeveer evenveel gebruikers raken. Stap over op RICE als het bereik zo sterk verschilt dat het de rangorde verandert. Beide zijn schattingen; behandel de score als een sorteervolgorde, niet als een oordeel.

  • Hoe vaak moet ik de backlog opnieuw prioriteren?

    In hetzelfde ritme waarin je resultaten evalueert – voor de meeste teams elke week of om de week. Scoor opnieuw als een test afloopt, een metric verschuift of er een nieuw lek opduikt. Scores verschuiven naarmate je leert, dus een roadmap die nooit opnieuw wordt gerangschikt, is al verouderd.

  • Wat als een test niet significant wordt?

    Bij weinig verkeer is dat de normale gang van zaken. Laat hem niet eindeloos doorlopen in de hoop dat de lijn beweegt – bepaal vooraf hoelang je wacht, lanceer dan de versie die je toch al zou lanceren en houd guardrailmetrics in de gaten. Bewaar formele A/B-tests voor wijzigingen die groot genoeg zijn, of pagina’s die druk genoeg zijn, om echt tot een uitkomst te komen.

fromHello is open source marketing automation: berichten die worden getriggerd door wat mensen doen.

fromHello Cloud is in early access via de wachtlijst.

Early access

fromHello Cloud

Je bent niet begonnen om klein te blijven.

Early access tot fromHello Cloud gaat gefaseerd open. De onboarding is persoonlijk: we helpen je met de inrichting en met het overzetten van je contacten.

We mailen je zodra je plek vrijkomt. Geen spam.

Nog niet zover? Bekijk op GitHub