De kloof tussen product en proces: zo stopt u dit lek in het budget van uw organisatie

Lees het transcript:

We proberen onze podcasts te transcriberen met behulp van een softwareprogramma. Vergeef ons eventuele typefouten, want de bot is niet altijd 100% correct.

Hannah Clark: Een van de prachtige dingen aan Agile-organisaties is dat we voortdurend experimenteren en leren om onze organisaties en de producten die we aanbieden te verbeteren. Elke doorbraak in technologie is het resultaat van een vorm van experimenteren, maar er is ook een keerzijde: experimenten leiden niet altijd tot positieve resultaten. Veel experimenten bevatten zelfs ernstige gebreken — en wanneer honderdduizenden euro's afhangen van de uitkomst van een experiment, willen we als laatste beslissingen nemen op basis van gebrekkige gegevens. En hier komt het beangstigende deel: meestal realiseren we ons pas dat de gegevens gebrekkig zijn wanneer het te laat is.

Mijn gast vandaag is Manuel Da Costa, de oprichter van Effective Experiments. Zoals u waarschijnlijk uit de naam van zijn organisatie kunt afleiden, houdt Manuel zich voornamelijk bezig met het helpen van organisaties om betere experimenten uit te voeren, wat leidt tot betere productbesluitvorming. De juiste hulpmiddelen kunnen ons zeker helpen om experimenten en gegevensanalyse te verbeteren, maar hij heeft ook een fenomeen vastgesteld dat zijn oorsprong vindt in de marges van het organigram: de kloof tussen product en proces — en die kost technologiebedrijven stilletjes miljoenen. Laten we beginnen.

Welkom terug bij de podcast van The CPO Club. Vandaag ben ik hier met Manuel Da Costa.

Manuel, hartelijk dank dat je vandaag bij ons bent.

Manuel Da Costa: Hallo allemaal! Hannah, bedankt voor de uitnodiging.

Hannah Clark: Kun je ons iets vertellen over je achtergrond en hoe je bent gekomen waar je nu bent?

Manuel Da Costa: Zeker. Ik ben de oprichter van Effective Experiments. Wij zijn een bedrijf dat software aanbiedt om bedrijven te helpen beter samen te werken en betere productbeslissingen te nemen. Mijn achtergrond begon lang geleden, in de omgeving van lean startups, waar ik meer leerde over deze test-en-leeraanpak voor validatie. Daarna kwam ik geleidelijk terecht in de wereld van conversie-optimalisatie en uiteindelijk bij mijn eigen product, waarmee we product- en CX-teams helpen beter samen te werken.

En dat brengt me op dit punt in mijn carrière, waarop ik dit verhaal moet vertellen — en daarvoor zijn we hier in deze podcast.

Hannah Clark: Ik kijk ernaar uit om erin te duiken.

Vandaag richten we ons op een fenomeen dat jij de kloof tussen product en proces hebt genoemd. Kun je beginnen met uit te leggen waar dit naar verwijst en welke omstandigheden ermee samenhangen?

Manuel Da Costa: Ja, zeker. McKinsey heeft onlangs onderzoek gedaan naar de kloof tussen goede en slechte productmanagementpraktijken. Uiteindelijk komt het neer op de verwachtingen van het leiderschap over hoe productmanagement moet worden uitgevoerd, tegenover wat er op de werkvloer werkelijk gebeurt met productmanagers die dit uitvoeren. We hebben daar een kloof in ontdekt. Ik heb die de kloof tussen product en proces genoemd, maar in wezen gaat het om de kloof tussen verwachtingen en werkelijkheid.

Er zijn veel redenen waarom dit gebeurt en daar zullen we op ingaan, maar uiteindelijk wil het management betere producten, terwijl productmanagers en producteigenaren dat niet leveren. Daar zijn tal van redenen voor.

Hannah Clark: Laten we daar wat dieper op ingaan. Je zei dat er veel factoren zijn die dit kunnen veroorzaken. Wat is de reis, of de oorsprong, van deze kloof en hoe ontstaat die?

Manuel Da Costa: Zeker. Laten we kijken naar wat er tegenwoordig van productteams wordt gevraagd: elke productbeslissing die ze nemen valideren. Experimenteren is een middel geworden waarmee productteams hun hypothesen kunnen valideren en kunnen nagaan of ze het juiste product op de markt brengen.

Veel van deze productteams die de opdracht hebben gekregen om experimenten uit te voeren, hebben niet de ervaring of de kennis daarvoor. Zelfs als ze die kennis wel hebben, gaat het vaak om oppervlakkige kennis over experimenteren. Daardoor worden beslissingen genomen op basis van experimenten, terwijl het experiment zelf gebrekkig kan zijn. Het is misschien niet rigoureus genoeg. Daarnaast spelen er nog andere factoren.

We hebben het dan over samenwerking tussen teams, bewustzijn van wat er moet gebeuren en hoe er efficiënt geprioriteerd kan worden. Binnen productmanagement zijn er zoveel tegenstrijdige prioriteiten, vooral rond wat er moet worden gedaan. Nu experimenteren aan die mix is toegevoegd, gaat het erom de achterstand effectief te prioriteren voor een maximaal resultaat.

Dit zijn enkele symptomen die we op de werkvloer zien: productteams wordt gevraagd om dingen uit te voeren en experimenteren in hun werkwijze op te nemen, maar ze krijgen niet de ondersteuning die daarvoor nodig is.

Hannah Clark: Wat ontbreekt er in deze vergelijking? Het klinkt alsof er bijna sprake is van een onderontwikkelde vaardighedenset op het gebied van UXR bij productmanagers die in deze positie worden geplaatst. Dat leidt op zijn minst tot een domino-effect van gebrekkige resultaten. Wat zie jij als de belangrijkste oorzaken van het feit dat productmanagers onvoorbereid aan deze taak beginnen?

Manuel Da Costa: Laten we kijken naar het terrein waarop experimenteren wordt ingezet. In veel organisaties werd experimenteren vooral uitgevoerd door een marketingteam, een CRO-team of een conversie-optimalisatieteam.

Misschien ging het om enkele mensen of om een klein expertisecentrum. Geleidelijk kregen zij de opdracht om hun vaardigheden over te dragen aan productteams, zodat die zelfstandig hun eigen experimenten konden uitvoeren. De eerste uitdaging is het gebrek aan kennis. Organisaties organiseren soms trainingsworkshops of begeleide sessies waarin ze laten zien hoe het moet.

Maar daar houdt het op. Mensen krijgen toegang tot hulpmiddelen en een oppervlakkige training, maar er zijn geen middelen om hen echt te helpen begrijpen of ze vooruitgang boeken. Daardoor kijken ze alleen naar de aantallen. Ze zeggen bijvoorbeeld: we hebben een bepaald aantal experimenten uitgevoerd, dat is onze output. Niemand controleert echter of het experiment correct is uitgevoerd, goed is gepland en juist is geanalyseerd.

Die vaardigheid kost behoorlijk wat tijd om te ontwikkelen. Zie het als een spier: je kunt het niet één keer doen en er vervolgens goed in zijn. Er zijn productmanagers die goede experimenten uitvoeren, maar die kunnen te eenvoudig zijn. Ze kunnen ook complexe experimenten uitvoeren, maar die op de verkeerde manier instrumenteren. Wanneer ze vervolgens aan het leiderschap vertellen wat volgens hen de volgende stappen moeten zijn, is dat gebaseerd op onjuiste informatie — of het kan daarop gebaseerd zijn — zonder dat ze dat weten, omdat er geen toezicht op is.

Daarmee kom ik bij het volgende punt: dat toezicht ontbreekt. Vaak krijgen deze teams veel vertrouwen: voer de experimenten maar uit, wij geloven wel wat jullie aan ons terugkoppelen. Door het gebrek aan middelen neemt niemand de tijd om de resultaten te controleren en na te gaan of ze werkelijk juist zijn.

Of die resultaten het gevolg zijn van goede of slechte werkwijzen, is één factor. Een andere factor is het ontbreken van leiderschap op het juiste niveau. Met leiderschap bedoel ik niet de producteigenaar, maar de vicepresident Product en de CPO's. Zij moeten deze teams echt verantwoordelijk houden.

Maar ze moeten hen niet alleen verantwoordelijk houden; ze moeten hun ook ruimte geven om tijd te besteden aan het ontwikkelen van die vaardigheid: beter leren experimenteren, betere beslissingen leren nemen en beter leren prioriteren. Door deze twee factoren ontstaat er een kloof tussen de verwachtingen en de werkelijkheid. Productmanagers en productspecialisten lopen vast omdat ze niet de ruimte hebben om te vertragen en deze zaken op orde te brengen.

Een deel van de verantwoordelijkheid ligt dus bij het leiderschap. Zij moeten deze teams niet alleen het mandaat geven, maar ook de ruimte om hierin beter te worden.

Hannah Clark: Hoe ziet dat er vanuit leiderschapsperspectief in de praktijk uit? Welke stappen kunnen leiders nemen om te voorkomen dat deze kloof tussen product en proces ontstaat?

Manuel Da Costa: Het eerste is het vaststellen van de juiste KPI's. Het belangrijkste wat we zien, is dat er perverse prikkels worden ingebouwd. Daarmee bedoel ik bijvoorbeeld dat een team een bepaald aantal functies dit kwartaal of dit jaar moet lanceren.

Dan wordt het een kwantiteitsspel, niet een kwestie van kwaliteit. Je kunt één complexe functie lanceren of meerdere eenvoudige functies, zolang je het aantal maar haalt. Het gaat er dus om de juiste KPI's voor deze teams vast te stellen, zodat ze op de juiste manier worden gestimuleerd in plaats van alles te kunnen doen om een mijlpaal te halen.

Het tweede is dat teams en de mensen die toezicht op hen houden voldoende ruimte krijgen om hen te coachen, te monitoren en in de loop van de tijd betere beslissingen te laten nemen. Niemand begint met de kennis om correct te experimenteren. Dat kost tijd; het kan niet zo zijn dat één trainingsworkshop het einde van het proces is.

Deze teams moeten in de loop van de tijd worden gecoacht en begeleid. Het gebrek aan ruimte ontstaat doordat ze bepaalde cijfers moeten halen. Omdat ze geen ruimte hebben, verbeteren ze niet. Zo ontstaat een vicieuze cirkel. Het begint bij leiderschap dat zegt: we willen als organisatie verbeteren en betere productbeslissingen nemen.

Hoe nemen we betere productbeslissingen? Door te experimenteren en onze aannames te valideren. Dat is de eerste stap. Om dat te doen, moeten we onze productteams uitrusten om die aannames te toetsen. We geven hen tijd, ruimte en mandaat, maar ook de veiligheid om het fout te hebben. Het belangrijkste aan experimenteren is immers dat je ongelijk kunt hebben. Als KPI's worden bepaald in termen van aantallen, of als teams experimenten moeten lanceren met een bepaald succespercentage, zullen mensen het systeem manipuleren om dat getal te halen.

Experimenteren gaat erom dat we een idee hebben waarvan we denken dat het kan werken, maar dat pas weten wanneer het in de praktijk wordt gebracht. We weten niet of het zal werken. Wanneer we het uitbrengen, krijgen we feedback van onze klanten en van de markt.

Daarna kunnen we beslissen of we op die weg doorgaan. Die veiligheid is belangrijk, want als producteigenaren en productmanagers die niet krijgen, kiezen ze voor wat volgens hen het veiligst is om hun KPI's te halen. Dan krijg je veilige productbeslissingen, maar nooit innovatieve productbeslissingen.

Hannah Clark: Ik kan me voorstellen dat deze kloof tussen product en proces onder de radar blijft wanneer KPI's worden gehaald, mensen over het algemeen tevreden zijn en het bedrijf overeind blijft, maar er toch iets ontbreekt. Wat zijn symptomen dat een organisatie stilletjes onder deze kloof lijdt en dat er aanzienlijke verbeteringen mogelijk zijn, omdat er ergens in het proces gebrekkige beslissingen worden genomen door gebrekkige experimenten?

Manuel Da Costa: Als er gebrekkige experimenten plaatsvinden, hebben we al gezien dat CPO's en vicepresidenten zeggen: we vertrouwen de resultaten van deze experimenten eigenlijk niet. Dan ontstaan beslissingen op basis van onderbuikgevoel. Mensen nemen beslissingen terwijl er gegevens beschikbaar zijn, maar omdat ze die gegevens niet vertrouwen, negeren ze ze.

Als een bedrijf nu veilig is, en ik benadruk nu, experimenteert het niet, innoveert het niet en speelt het op veilig. Vroeg of laat zullen marktkrachten het dwingen harder te werken aan verbetering, of zullen ze het lot van het bedrijf bepalen. Het gebrek aan vertrouwen in experimentresultaten en besluitvorming is dus het eerste wat we moeten verbeteren.

Een ander punt is dat bedrijven misschien zeggen dat ze datagedreven, productgericht en klantgericht zijn. Dat zijn echter vaak slechts modewoorden. Je ziet de waarheid in de werkwijzen, niet in wat ze publiekelijk zeggen. Je ziet functies en productupdates die niet echt aansluiten bij wat klanten willen.

Uiteindelijk ontstaat dan een functiefabriek: dingen worden uitgebracht om ze uit te brengen, in plaats van daadwerkelijk waarde te leveren aan de klant of aan het bedrijf als geheel.

Hannah Clark: Zijn er bepaalde raamwerken die je zou voorschrijven om betere experimenten uit te voeren of om heel praktisch te bepalen welke acties we moeten ondernemen?

Het klinkt alsof dit een probleem is waaraan veel factoren bijdragen. Wat is volgens jou stap één wanneer we erkennen dat dit fenomeen zich binnen onze organisatie voordoet?

Manuel Da Costa: Absoluut. Ik denk dat de eerste stap standaardisering is. Wanneer productteams hulpmiddelen krijgen om experimenten uit te voeren, zien we dat twee verschillende teams binnen dezelfde organisatie plotseling afwijken in de manier waarop ze experimenten uitvoeren, gegevens classificeren en gegevens vastleggen. De eerste stap is dus begrijpen hoe het proces eruit hoort te zien.

Als je dat proces kent, standaardiseer je het. Wanneer ik het woord standaardiseren gebruik, raken mensen soms geëmotioneerd omdat ze denken dat ze heel rigide moeten worden en dat er geen ruimte voor flexibiliteit is. Het probleem met een te flexibele aanpak is dat er na verloop van tijd chaos ontstaat en gegevens vrijwel onbruikbaar worden voor iedereen die ze later bekijkt.

Standaardiseren betekent dat je het proces standaardiseert, evenals de classificatie van gegevens en de nomenclatuur die je daarvoor gebruikt. Je standaardiseert ook de analysepraktijken en bepaalt wie goedkeuring geeft. Denk bijvoorbeeld aan een RACI-model: wie is verantwoordelijk, wie is eindverantwoordelijk en wie moet worden geraadpleegd en geïnformeerd?

Dat lijkt rigide, maar in essentie creëert het vangrails voor mensen. Het maakt niet uit of het team in de loop van de tijd verandert, nieuwe mensen erbij komen of iemand naar een ander team of bedrijf vertrekt. De werkwijze wordt ingebed in elk uitgevoerd experiment en elke beslissing die daarop volgt.

Het andere punt is de verbinding tussen die beslissingen en bedrijfsdoelstellingen. Het gaat niet om lukraak beslissingen nemen, maar om beslissingen die niet alleen aansluiten bij KPI's, maar ook bij bedrijfsdoelstellingen en -doelen. Zodra die twee zaken op hun plaats staan, heb je een veel betere basis.

In het begin gaat het langzaam, omdat mensen tijd nodig hebben om eraan te wennen dat ze bewuster moeten omgaan met het prioriteren van hun achterstand, het kiezen van experimenten, het lanceren ervan en het beoordelen of een experiment leidt tot een volledige functie die ze verder ontwikkelen of dat ze ermee stoppen. Die aspecten vormen de basis.

Daarna moet je zorgen voor duidelijk toezicht. Dat betekent dat iedereen kan terugkijken naar een team of persoon en kan analyseren hoe goed die presteert. Het gaat er niet om fouten te zoeken, maar om te begrijpen waar de hiaten zitten en hoe je beter kunt coachen.

Je kunt bijvoorbeeld zeggen: je hebt dit kwartaal vijf experimenten gelanceerd, maar sommige hebben geen sterke hypothese of je hebt niet de juiste meetwaarden gekozen bij de evaluatie. Zo kun je verbeteren. Mensen verbeteren alleen wanneer je feedback geeft en hen monitort — niet om negatieve feedback te geven, maar om positieve feedback te bieden waarmee ze verder kunnen.

Die twee zaken samen zullen het basisniveau van de organisatie verbeteren en de kloof verkleinen.

Hannah Clark: Interessant is dat er op leiderschapsniveau echt emotionele intelligentie nodig lijkt te zijn om op deze manier effectief leiding te geven. Veel hangt af van het vermogen van het leiderschap en het productteam om een veilige relatie op te bouwen, waarin psychologische veiligheid bestaat om fouten te maken en experimenten uit te voeren die niet verlopen zoals verwacht.

Welke tips heb je om sterkere relaties tussen teams te stimuleren, vooral over het organigram heen? Hoe leren we elkaar beter te vertrouwen wanneer we nauw samenwerken, vooral in een nieuw proces als dit?

Manuel Da Costa: Dat is gemakkelijker gezegd dan gedaan, want er zijn mensen en ego's bij betrokken en mensen moeten zich kwetsbaar opstellen. Dat is het moeilijkste. Wat ik opnieuw vanuit leiderschap zie, is dat je psychologische veiligheid moet bieden en ook de taal enigszins moet aanpassen.

We zeggen niet dat een test geslaagd of mislukt is. We richten ons vooral op wat we hebben geleerd. Als je het gesprek verschuift van winst en verlies naar: door dit experiment uit te voeren hebben we de behoefte aan deze functie gevalideerd, of hebben we de behoefte van de klant gevalideerd, en zo hebben we het bedrijf geholpen,

dan verandert de betekenis. Je kunt ook zeggen: dit is het potentieel van dit experiment. Of: door dit te doen hebben we de behoefte aan deze functie juist ontkracht. We zagen geen reden om de functie te bouwen. Daarmee hebben we ontwikkelkosten bespaard en dit geleerd, waarmee we nu verdergaan om meer te leren.

Het gaat om een verschuiving van de mentaliteit: niet experimenteren om het experimenteren, en niet experimenteren om te winnen. Daarom zijn KPI's zo belangrijk en is de manier waarop je ze vormgeeft zo belangrijk.

Productmanagers, productspecialisten en producteigenaren zullen misschien zeggen: we zouden dit graag doen, maar het kan niet omdat onze KPI's anders zijn. Daarom is het zo belangrijk dat leiderschap hier aandacht aan besteedt. Als we dat niet doen, ontstaan allerlei neveneffecten. Organisaties worden functiefabrieken en misschien lijkt het alsof alles lang duurt.

We brengen wel dingen uit, maar in hoeverre leveren ze werkelijk waarde?

Hannah Clark: Dat is een goed punt.

Ik ben ook benieuwd naar enkele praktische elementen op leiderschapsniveau. KPI's verschillen natuurlijk per team, maar ook teamgroottes verschillen. Hoe houden we effectief toezicht op een productteam wanneer we gaan opschalen en nieuwe medewerkers binnenkomen met een ander kennisniveau of andere interne kennis dan iemand met meer ervaring?

Hoe standaardiseren we dit en zorgen we ervoor dat we het juiste toezicht bieden, vooral wanneer we als leiders in de minderheid zijn ten opzichte van de teamleden die onder onze begeleiding vallen?

Manuel Da Costa: In onze wereld hebben we de rol van coördinator bedacht. Afhankelijk van het aantal teams en mensen in die teams creëer je een rol die toezicht houdt op een kleiner of bepaald aantal teams. Deze persoon kan verantwoordelijk zijn voor het inwerken, coachen en begeleiden van die teams, en ervoor zorgen dat alles binnen hun werkgebied verloopt zoals het hoort. Vervolgens kunnen ze rapporteren aan het volgende niveau.

In plaats van één leider die toezicht houdt op iedereen, wil je één persoon die verantwoordelijk is voor een team of meerdere teams. Hun specifieke rol draait om het inwerken, coachen en begeleiden, zodat de mensen onder hen betere experimenten uitvoeren en de juiste productbeslissingen nemen.

Ze functioneren binnen de vangrails die in het proces en de structuren zijn vastgesteld. Dat is belangrijk wanneer je kijkt naar de inrichting van een organisatie. Een coördinator kan toezicht houden op meerdere teams, maar het hangt opnieuw af van de omvang van het team.

Hannah Clark: Ik ben het ook eens met het concept van vangrails. Het klinkt alsof het mensen minder zeggenschap geeft, maar in de praktijk heb ik gemerkt dat duidelijke vangrails beslissingsmoeheid verminderen. Ze maken het werk veel duidelijker, omdat mensen hun processen niet voortdurend opnieuw hoeven uit te vinden naast de producten die ze bouwen. Ik denk dus dat daar veel voor te zeggen is.

Ik ben wel benieuwd, want waar we het nu over hebben is ook de noodzaak om toezicht te standaardiseren. Dat is abstracter: hoe standaardiseren we het proces waarmee we toezicht houden op een team, zelfs als we een kleiner team onder onze hoede hebben?

Welke aanbevelingen heb je voor het standaardiseren van toezicht, vooral wanneer je als leider zelf geen sterke achtergrond in experimenteren hebt?

Manuel Da Costa: Het begint allemaal met het creëren van een governancekader. Als je kijkt naar wat dat inhoudt, gaat het om het vaststellen van de regels voor het creëren van een experiment.

Daarmee bedoel ik: welke belangrijke zaken moet je vastleggen wanneer je een experiment maakt? Sommige daarvan zijn vrij basaal. Sommige zijn verplicht, zoals een hypothese — een goede hypothese. Er is verschil tussen een hypothese en een echt sterke hypothese.

Dat is één aspect, maar welke andere details leg je vast? Ik kijk dan naar informatie die nuttig is voor het opzetten van het experiment, zoals technische details, de doelgroep en dergelijke. Maar ook naar aspecten die relevant en belangrijk zijn voor het bedrijf. Wanneer we een governancekader creëren, zeggen we dat iedereen in de organisatie bij het maken van een experiment bepaalde velden of gegevenspunten moet invullen.

Daar valt niet over te onderhandelen. Dit moet worden vastgelegd. Dat is het absolute minimum. Daarnaast zijn er optionele aspecten. Dat is één onderdeel dat, ik zeg het liever niet te streng, moet worden afgedwongen. Maar opnieuw zijn er vangrails die voorkomen dat de organisatie eindigt met een stapel nutteloze gegevens.

Als je te veel flexibiliteit biedt, gaan verschillende teams hun eigen interpretatie hanteren van wat een experiment is. Je hebt dus een governancekader dat bepaalt dat voor elk experiment zowel bedrijfsrelevante als technisch relevante informatie moet worden vastgelegd.

Daarna volgt het proces. Je kunt een experiment niet ontwerpen, uitvoeren en analyseren zonder bepaalde stappen te doorlopen. Je zou bijvoorbeeld geen functie lanceren zonder kwaliteitscontrole. Hetzelfde geldt voor een experiment. Je lanceert geen experiment zonder kwaliteitscontrole. Een governancekader moet dus bepalen dat een experiment bepaalde fasen niet kan doorlopen zonder bijvoorbeeld eerst kwaliteitscontrole te hebben gehad.

Dat is niet onderhandelbaar. Het moet gebeuren. Elk experiment volgt daardoor een pad en kan daar niet van afwijken. Als het toch afwijkt, kunnen we dat monitoren en onderzoeken waarom dat gebeurt. Hier komt het concept van een gezondheidskaart dat we hebben ontwikkeld van pas.

De gezondheidskaart is een checklist met punten waarop een experiment kan worden beoordeeld. Was er bijvoorbeeld een hypothese? Ja of nee? Het tweede punt is: wanneer is die hypothese gemaakt? Tijdens het bedenken van het experiment, of pas later, toen men het experiment probeerde te rechtvaardigen?

Dat gebeurt namelijk ook. We hebben een trend gezien die we niet zelf hebben bedacht: ‘harking’, oftewel een hypothese formuleren nadat de resultaten bekend zijn. Als je gegevens lang genoeg onder druk zet, vertellen ze je wat je wilt weten. Dat is soms precies wat er gebeurt bij experimenten die niet echt slagen.

Ze winnen niet. Vervolgens kun je de meetwaarden of de hypothese aanpassen. En zie daar: het experiment heeft gewonnen. Governancekaders en vangrails zijn belangrijk omdat ze voorkomen dat dit gebeurt. Ik zeg niet dat mensen dit bewust van plan zijn. Het gaat terug naar het punt dat hun KPI's gericht zijn op het behalen van een bepaald aantal productfuncties, het uitvoeren van een bepaald aantal experimenten of het bereiken van een bepaald succespercentage.

Vervolgens verschuiven ze alles om dat getal te halen. Daarom kunnen deze governancekaders en de gezondheidskaart zulke zaken bijhouden. Is het vastgestelde proces gevolgd? Zijn er wijzigingen aangebracht in cruciale informatie over het experiment toen het werd afgerond?

Zo kunnen we beginnen met monitoren. De gezondheidsscore geeft een beeld van de vraag of het experiment correct is uitgevoerd. Uiteindelijk kun je dan zeggen: we vertrouwen dit experiment, de uitkomsten en de beslissingen die we op basis daarvan hebben genomen — of: we vertrouwen het experiment niet, en dit zijn de redenen. Maar ook dan is het een kans om te coachen.

Het is een kans om de organisatie betere productbeslissingen te laten nemen en betere experimenten uit te laten voeren om daar te komen.

Hannah Clark: Ik waardeer de raamwerken die je hebt aangereikt enorm. Dit is erg nuttig.

Heb je succesverhalen paraat van een organisatie die haar resultaten heeft kunnen transformeren door de kloof tussen product en proces weg te nemen?

Manuel Da Costa: Ik kan de naam van het bedrijf niet noemen, maar we hebben precies hetzelfde gedaan bij een bedrijf dat overstapte van een expertisecentrum naar teams die zowel productteams als marktteams waren. Het was een wereldwijd e-commercebedrijf met veel markt- en productteams die pas in een vroeg stadium met testen waren begonnen.

Daarbij was het belangrijk dat we niet elk productteam en elk marktteam meteen aan experimenteren lieten deelnemen. We maakten eerst een SWOT-analyse van elk team en gaven punten voor hun kennis van experimenteren. De andere factor was hoe enthousiast en bereid ze waren om eraan mee te doen.

Vervolgens begonnen we met de teams die daarop hoog scoorden en gebruikten we hen geleidelijk als sociaal bewijs. Toen enkele teams waren ingestapt en goed presteerden — bijvoorbeeld binnen drie maanden — noemden we dat sprints van drie maanden. Elke sprint had een plan om de teams te coachen en in te werken, zodat ze aan het einde van het programma zelfstandig konden werken.

We gebruikten die teams vervolgens als sociaal bewijs om de volgende groep mensen mee te krijgen en boden ondersteuning vanuit de gemeenschap tussen de teams. We hebben dit gedurende een periode van twee jaar geconsolideerd. Het was een lang proces. Het gebeurde niet van de ene op de andere dag, zeker niet bij een groter bedrijf.

Cultuurverandering gebeurt niet van de ene op de andere dag. Dit was het proces dat we hebben doorlopen. Aan het einde van die twee jaar hadden we productteams die veel beter wisten hoe ze deze experimenten moesten uitvoeren. Zelfs bij personeelsverloop, wanneer mensen vertrokken en nieuwe medewerkers kwamen, duurde het minder dan een maand voordat een nieuwe medewerker in het proces was opgenomen, omdat alle raamwerken aanwezig waren.

De systemen waren aanwezig en iedereen wist precies hoe het moest. Alles was zo ingericht dat er weinig fout kon gaan. Het was veel gemakkelijker om de bestaande werkwijze te volgen dan om er een eigen draai aan te geven.

Hannah Clark: Ik waardeer de voorbeelden die je hebt gedeeld en dit was zeer informatief.

Heel erg bedankt dat je bij ons was, Manuel. Waar kunnen mensen je online volgen als ze meer willen leren over je werk en Effective Experiments?

Manuel Da Costa: Je kunt me vinden op LinkedIn. Ik ben daar behoorlijk actief. Je kunt ook EffectiveExperiments.com bezoeken om meer te lezen over wat we doen. Daarnaast publiceer ik veel inhoud op onze blog. Volg me gerust via deze twee kanalen.

Hannah Clark: Geweldig. Heel erg bedankt.

Bedankt voor het luisteren. Abonneer je voor meer geweldige inzichten, praktische handleidingen en beoordelingen van hulpmiddelen op onze nieuwsbrief via theproductmanager.com/subscribe. Je kunt meer gesprekken zoals dit beluisteren door je te abonneren op The CPO Club, waar je je podcasts ook beluistert.