Stopp siloene! Hvordan samle team for å bygge et vellykket eksperimenteringsprogram

Som leder for et eksperimenteringsprogram vil det være nok av øyeblikk der uttrykket "å gjete katter" treffer litt for nært. Eksperimentering er et nytt sett med prosesser og analytisk stringens som krever konsistens, og vi vet at konsistens ikke oppnås over natten. Ikke bli motløse! Dette er normale voksesmerter og den typen øyeblikk der utholdenhet er den viktigste variabelen. Grunnen til at disse øyeblikkene fortsetter å eksistere, er at eksperimentering krever at de aller fleste deltakerne endrer måten de jobber på. I stedet for å gjøre én endring i en komponent på hjemmesiden, må utvikleren nå gjøre to endringer. I stedet for ett analysepunkt må folk lære seg et sekundært system og en sekundær metodikk. Med noen enkle taktikker kan du være sikker på å bruke mindre tid på å gjete og mer tid på å teste.

Vi har sett hos kundene våre at når flere mennesker er involvert, blir det gjennomført flere eksperimenter (og mer effektive eksperimenter)!

Hvordan skal jeg håndtere alle disse menneskene?

En av de positive effektene av eksperimentering er at det kan øke det funksjonelle teamsamarbeidet. Det er mange roller som kan delta i eksperimenter for å øke verdien av dem, og som programleder bør du alltid bestrebe deg på å få med flere folk. Når du har flere personer involvert i programmet, kan du gjennomføre flere eksperimenter, løse mer komplekse problemer og kjøre eksperimenter mer effektivt. Med flere folk betyr det også flere Slack-meldinger som ser ut som "hvor langt har du kommet med dette?" Noen ganger vil det være behov for slike meldinger, men du bør alltid ha disse tre mekanismene på plass for å administrere alle som bidrar til å få et eksperiment fra idé til lansering.

• Et sted for gjennomgang: Jeg er ingen tilhenger av møter. Jeg har tatt til orde for at vi ikke skal ha én-til-én-møter hos Optimizely (til ingen nytte). Jeg må imidlertid innrømme at et møte for eksperimentering er en forutsetning for å drive et effektivt program. Hos Optimizely har vi vår ukentlige eksperimentgjennomgang, der alle som har en hypotese kommer sammen for å dele den med resten av teamet. Jeg er tilhenger av å ha møter annenhver uke, men jeg har kunder som også har ukentlige eller månedlige møter. Agendaen for møtet trenger ikke å være lang eller tidkrevende. Bare be medarbeiderne dine om å møte opp og fortelle om hva de planlegger å lansere, og om resultatene av pågående eller nylig avsluttede eksperimenter. Legg inn noen av de innledende spørsmålene dine, for eksempel "hvilke data underbygger det kundeproblemet?" eller "hvorfor valgte du det som primærmåling?", og la resten av teamet komme med tilbakemeldinger og tanker. Målet ditt som programleder er å legge til rette for og oppmuntre til tilbakemeldinger på tvers av teamene.

• Et sted for samtale: Når du går ut av "rommet" (Zoom) etter møtet, bør det være klart hva du skal gjøre. Vet du hvem som glemmer noen av disse aksjonspunktene? Eller har et nytt punkt å avklare når det gjelder den primære måleparameteren? Det er meg. Jeg trenger et sted der jeg kan følge opp og spørre analytikeren min om hvorfor den målingen faktisk er en bedre ledende indikator på eksperimentets suksess. Dette er en annen ledelsespraksis du ikke trenger å tenke for mye over. Faktisk er mye av det jeg jobber med kundene mine om, en "hvor gjør du slike ting nå?"-diskusjon. Hvis du administrerer praksisfellesskap på Slack (Optimizely har til og med en Slack-integrasjon!) eller Microsoft Teams, kan du gjøre det samme med eksperimenteringsrutinene dine. Hvis du administrerer backloggen din i Optimizelys Program Management, kan du enkelt bruke kommentarfunksjonen til å samarbeide om åpne punkter. Spesielt når du oppretter nye prosesser, er det nyttig å "piggyback" på det som allerede eksisterer for å minimere endringshåndteringen. Hos Optimizely har vi to kanaler. Én for å holde folk oppdatert om fremdriften i eksperimenter (#experiment-feed) og én for å la folk diskutere kommende eller tidligere eksperimenter (#experiment-review). Som programansvarlig må du sørge for å holde oppdateringene dine konstante og konsekvente!

• Et sted for utførelse: Du har altså hypotesen fra møtet. Du har fått på plass de siste detaljene. Hvordan får du utviklerne dine til å hjelpe deg med å bygge den? Hvis utviklingsteamet ditt jobber i Jira (Optimizely har også en integrasjon for Jira), bør vi hjelpe dem ved å jobbe i Jira også. Ingen liker å lære seg et nytt prosjektstyringsverktøy! Når hypotesene våre er klare for den aktuelle ingeniøren, oppretter vi en sak i deres egen Jira-tavle som lenker til programledelsen med flere detaljer om hva vi gjør og hvorfor. I Optimizely bruker vi både Program Management og Jira, ettersom Program Management inneholder all informasjon om eksperimentkonfigurasjonen, for eksempel hypoteser, beregninger og visualiseringer, mens Jira fokuserer på det som må bygges av ingeniørteamet vårt. Alle disse handlingene som skjer i disse områdene, skaleres enda raskere hvis du gir teammedlemmene dine konsistent dokumentasjon som de kan bruke. Denne konsistensen sikrer at eksperimentene utføres i henhold til de standardene du som programleder har satt!

Hvordan kan jeg bruke data til å forstå hvor jeg trenger mest tid?

Den mest oversette delen av å drive et eksperimentprogram er dataene. Nei, ikke dataene om hvor mange flere konverteringer eller leads du har generert. Jeg snakker om dataene som skapes når du setter i gang et eksperiment, og hvordan de kan brukes til å finne ut hvilke typer eksperimenter du skal kjøre fremover, etter hvert som du lærer mer om kundene dine. Tenk på hvor mye du vet om det eksperimentet:

• Hvor lenge det pågikk
• Hvilke sider eller målgrupper det var rettet mot
• Hvor mange variasjoner du brukte
• Hvilken type endring(er) du gjorde
• Hvilke metrikker det ble målt mot
• Hvilke(n) måling(er) som var statistisk signifikante
• Hvilken fase av eksperimentet som tok lengst tid å lansere

Du bør bruke disse datapunktene på tvers av alle eksperimentene dine for å forstå hvilke fremgangsmåter som hjelper programmet ditt, og hvilke som ikke gjør det. Dette er de måleparameterne jeg foreslår at alle kunder sporer fra dag én for å legge til rette for denne typen analyser.

Hvis du visste at det å kjøre mer målrettede eksperimenter ville øke gevinstprosenten din, ville du nok kjørt mer målrettede eksperimenter. Hvis du visste at 50 % av gjennomføringstiden din går med til å få eksperimenter gjennom kvalitetssikring, ville du nok begynt å evaluere kvalitetssikringstrinnene dine og involvert deg for å effektivisere dem. Analyser forretningsdriften i programmet ditt!

Hva gjør modne programmer annerledes?

Når jeg får dette spørsmålet, snakker jeg om hvordan de programmene som gjennomfører hundrevis av eksperimenter i året, bruker data om seg selv til å finne ut hva de bør gjøre bedre (nå vet du hvorfor akkurat den delen har fått sin egen seksjon). Men det finnes andre ting å fokusere på også! Disse kan være enklere å komme i gang med enn å lage et helt sett med måleparametere, spesielt hvis du er i en tidlig fase og bare kjører noen få eksperimenter i måneden. Dette er andre fokusområder for modne programmer som du kan implementere i ditt eget program i dag:

• Ledelsens oppslutning - Dette skjer ikke over natten, med mindre du er heldig. Vanligvis krever dette en "bevis det, eller mist det"-historie. Et godt program utnytter data for å måle effekten på virksomheten og knytte en leder til programmet. Denne lederen hjelper til med å skaffe ressurser, sette et charter og overvinne andre hindringer underveis.
• Retningslinjer for eksperimenter - Jeg har skrevet litt om dette i en tidligere blogg, men en utfordring når det gjelder å nå et stort antall eksperimenter, er at mange mennesker vurderer eksperimentets suksess ulikt. Ved å skape et felles perspektiv på hvordan eksperimentresultatene skal analyseres på tvers av alle måleparameterne, kan du redusere tiden det tar å ta beslutninger. En god policy til å begynne med er hvordan du tar beslutninger mellom den primære og den sekundære målingen. Hvis du har en statistisk signifikant økning i klikkfrekvensen, er det godt nok hvis kjøpskonverteringen ikke er statistisk signifikant? Ved å sette disse retningslinjene kan teamene dine handle raskere.
• Utdanningsprogram - Punktet ovenfor er et enkelt kjennetegn på utfordringen med at "alle gjør ting på forskjellige måter". For å få mest mulig ut av eksperimentering må det være noen konsistente fremgangsmåter i programmet ditt. Ikke bare hvordan man analyserer, men også hvordan man skriver en hypotese. Hvordan bruker du dataene dine til å utarbeide dem? Hvordan utnytter du tredjepartsdata for målretting? Disse og mange andre spørsmål kan besvares i et utdanningsprogram. Gode programmer kan bestå av alt fra noen få økter til et to ukers "kurs" der medarbeiderne får alt de trenger å vite om eksperimentering. Jeg ville gjort dette til en del av introduksjonen hvis du kan. Det er enkelt å komme i gang med dette med Optimizelys Academy også! Sørg for å dokumentere alle disse fremgangsmåtene slik at de enkelt kan deles i hele organisasjonen, selv om det ikke er en del av læreplanen for utdanningsprogrammet ditt - ditt fremtidige jeg vil takke deg.
• OKR-er - Når eksperimentering blir et fokus for organisasjonen, bør dere måle hverandre opp mot det. Vår egen programsjef skrev om viktigheten av dette for å oppmuntre produktsjefene våre til å delta mer aktivt i eksperimentering. Dette aspektet av programmet kan smelte godt sammen med den målingen du har innført på programnivå. Hvis du måler programmet etter antall eksperimenter som er satt i gang, og antall varianter som er kjørt, kan du også måle hver enkelt person etter disse metodene! Husk å sette av tid til å dele resultatene med hverandre, slik at dere kan evaluere hvilke OKR-mål som virkelig påvirker programmets totale suksess.

Så, hva kan vi ta med oss?

Jeg har sagt mye om hvordan du kan fjerne siloene og skape et mer samarbeidsorientert program. Men hva kan du egentlig fokusere på i morgen (eller neste uke!)?

• Sørg for å utnevne en programleder og nøkkelroller på tvers av teamene. Ingen eksperimenteringsprogram lykkes uten noen som har minst 50 % av sin rolle knyttet til programmet. Det er for mange katter å gjete. Ta arbeidsflyt-RACI-en din og gi den til teamene, slik at de vet hvordan de skal gjennomføre et eksperiment fra start til slutt. Begynn å måle avkastningen på investeringen i programmet hvis det er ressursgap du må kjempe for.
• Samle folk på samme måte som de gjør nå. Du trenger ikke å gjenskape hjulet eller, i dette tilfellet, nye prosesser. Hvis du har Slack og JIRA som arbeidsflytverktøy akkurat nå, er det bare å bruke dem. Du kommer til å trenge det møtet også!
• Mål programmet for å avdekke ineffektivitet, slik at du vet hvor du skal bruke tiden din som programleder. Du trenger ikke å gjøre noe den første måneden eller det første året. Men på et eller annet tidspunkt vil dataene hjelpe deg med å besvare et spørsmål du ikke hadde forventet.