Pas validatie toe op je hele digitale afdeling

Als CRO-activiteiten in één team worden belegd, wordt dat in andere teams minder snel geadopteerd. Uiteindelijk wil je met de hele afdeling groeien, valideren en de belangrijkste KPI’s halen. Laat ook de teams van online marketing, development en content management meegenieten, en de kans op snelle groei wordt groter. 

In de beginjaren van A/B-testen en conversieoptimalisatie (CRO) moesten we bedrijven nog overtuigen van de waarde van CRO op korte en lange termijn. Gelukkig zijn we die fase voorbij (uitzonderingen daargelaten) en zien veel bedrijven de toegevoegde waarde van conversieoptimalisatie in.

Binnen veel organisaties ligt de verantwoording voor het uitvoeren van A/B-testen bij een specifiek team. Vaak het CRO team genaamd. Erg fijn, deze teams hebben vaak de benodigde disciplines aan boord en kunnen zelfstandig te werk gaan. Als deze ‘machine’ op gang komt worden vaak mooie resultaten geboekt. Voor bedrijven die een vliegende start willen maken en resultaten willen boeken is dit een prima opzet.

Een nadeel van deze opzet is dat dit ‘CRO team’ een apart team is binnen de digitale afdeling. Schematisch zou het er zo uit kunnen zien:

Er zijn naast het CRO-team nog meer teams binnen de digitale afdeling, denk bijvoorbeeld aan online marketing, development en content management. Mijn ervaring is dat door de CRO activiteiten in één team te beleggen, deze manier van werken minder snel in andere teams geadopteerd wordt. Uiteindelijk wil je met de hele afdeling groeien, valideren en de belangrijkste KPI’s halen.

Door de werkzaamheden te valideren binnen alle teams en niet alleen het CRO team is het effect vele malen groter en wordt de kans op een snelle groei vergroot.

Wat leveren veranderingen op?

Het interessante is dat er vrijwel altijd een apart team verantwoordelijk is voor ‘nieuwe ontwikkelingen’. Bijvoorbeeld het scrum of development team. Moet de impact van deze nieuwe ontwikkelingen niet gemeten worden? Uit ervaring, bij Online Dialogue, weten we dat gemiddeld 25 procent van de ideeën significant meer waarde opleveren. Als je in een sprint twaalf nieuwe features oplevert, kan het zomaar zijn dat er maar drie extra waarde opleveren. Die overige negen leveren geen, of erger nog, een negatieve waarde op.  

Zonder te valideren weet je niet welke van de twaalf features een significante meerwaarde opleveren. Hieronder staan een aantal vragen die gevalideerd kunnen worden en waarvan de impact zonder validatie onbekend is.

• Wat leveren onze nieuwe abonnementen/diensten/producten op?
• Wat is de toegevoegde waarde van tool ‘x’?
• Wat levert de nieuwe checkout op?

Methode om te valideren

Er zijn verschillende methodes om te valideren. Denk hierbij aan: usability onderzoek, expert reviews, A/B testen (ook wel controlled experiments genoemd). Belangrijk is wel: deze methodes zijn niet allemaal even valide. De ‘quality of evidence’ en ‘risk of bias’ verschilt per methode. In onderstaande ‘Hierarchy of evidence’ is dit weergegeven in een model.

Om een A/B test of controlled experiment te kunnen uitvoeren heb je een minimaal aantal conversies nodig. Niet elk bedrijf heeft de mogelijkheid om dit te doen, in dat geval adviseer ik ook zeker om andere methodes te gebruiken.

Heb je wel de mogelijkheid om A/B testen toe te passen als methode, dan raad ik je aan om dit te doen. Mogelijk zijn de andere methodes makkelijker of goedkoper, maar weet je wat de gevolgen zijn van het doorvoeren van een feature die in werkelijkheid een negatieve bijdrage heeft?

Wij gebruiken usability onderzoek en surveys als bronnen om ons de juiste richting op te sturen voordat we gaan A/B testen. Om deze input te valideren gebruiken we daarna A/B testen. Dus begrijp mij niet verkeerd, ik pleit er niet voor om geen usability onderzoek of surveys meer te doen. Wel pleit ik ervoor om A/B testen te gebruiken als methode om aan te tonen of iets een daadwerkelijke bijdrage levert aan je business. Uiteraard kan dit alleen met het juiste aantal conversies. 

Nu staan we voor de volgende uitdaging: hoe zetten we de stap van het uitvoeren van A/B testen door specifieke teams naar validatie binnen de hele digitale afdeling?

Cultuur en structuur

Veel bedrijven werken met development sprints van twee weken. Tijdens een sprint hebben de scrum teams dan twee weken de tijd om iets op te leveren. Binnen deze twee weken moet het idee gedesignd, developed en getest worden. Niet zo gek toch dat deze teams geen experimenten uitvoeren? Daar hebben ze namelijk helemaal geen tijd voor. Een experiment loopt veelal tussen de één en vier weken.

Vaak wordt een halve dag ingepland voor een usability-onderzoek, dit past namelijk in de planning. De resultaten hiervan worden verwerkt en ze gaan weer door. Op deze manier wordt de klant ook meegenomen in het project. En feitelijk gezien klopt dit ook zeker. Echter pleit ik hier toch voor het valideren van ideeën op een grote groep bezoekers in een “controlled experiment” oftewel A/B test.

Een prototype voorleggen aan zes mensen in een UX-lab is toch een stuk minder betrouwbaar dan het uitvoeren van een ‘controlled experiment’ op een grote groep websitebezoekers. Daarvoor verwijs ik graag naar bovenstaande ‘Hierarchy of evidence’.

Als maar 25% van de ideeën/activiteiten significant iets bijdraagt en 75% niks bijdraagt of zelfs negatief is, dan betekent dit dat je het grootste deel van je werkzaamheden dingen bedenkt en ontwikkelt die niet direct iets bijdragen. Binnen de cultuur van bedrijven is het belangrijk dat dit ‘falen’ omarmt wordt. Daarom moeten we het niet falen noemen, maar ‘leren’. Dit klinkt makkelijker dan het is, in werkelijkheid is dit een grote verandering binnen de cultuur van een bedrijf en niet van vandaag op morgen gerealiseerd. Maar je kan wel vandaag beginnen met het zetten van de eerste stappen.

Van output naar outcome

Hoe kan je ervoor zorgen dat validatie ook wordt toegepast binnen het team dat bezig is met het ontwikkelen van nieuwe features? De belangrijkste boodschap moet zijn: ga minder doen, maar zorg ervoor dat wat je doet, een grotere kans heeft op een daadwerkelijke bijdrage aan de belangrijkste KPI’s van je bedrijf.

Zo kan nog steeds binnen een sprint van twee weken iets ontwikkelt worden, maar moet er vervolgens tijd en ruimte zijn om dit idee door middel van een experiment te valideren.

Het voordeel van het valideren is dat je te weten komt of je ideeën waarde toevoegen. Zo implementeer je alleen nog ideeën die significant een meerwaarde opleveren. Ik pleit er dan ook voor dat mensen die hun ideeën valideren worden toegejuicht, ongeacht het resultaat.

Zeg nou zelf, welke van de volgende keuzes leg je het liefst voor aan je baas?

1. Ik heb twaalf features bedacht, allemaal door IT laten ontwikkelen en live laten zetten. Nu ze live staan leveren er drie extra waarde op. Maar welke? Dat is niet bekend.
2. Ik heb twaalf features bedacht en vooraf gevalideerd. Drie leverden een significante meerwaarde op. Exact deze drie heb ik door IT laten ontwikkelen en live gezet.

Ik zou het wel weten.