Gjør det mulig å eksperimentere i organisasjonen din: Bestem teamstrukturen din

Skalering av eksperimentering er ofte den vanskeligste utfordringen for organisasjoner når de begynner å se de konkrete resultatene av eksperimentene. Bedriftene begynner å fokusere på hvordan de kan gjøre praksisen til en realitet i alle deler av virksomheten. Det kan virke som en uoverkommelig oppgave å definere roller, ansvarsområder og arbeidsflyter i et ekspanderende eksperimenteringsprogram, men det er avgjørende for å gjøre skaleringen til en realitet.

Forhåpentligvis er din organisasjon også klar for å skalere programmet og oppnå suksess! Som ledende strategikonsulent i Optimizely har jeg sett mange måter organisasjoner skaper denne strukturen på. Det finnes typiske strukturer som eksperimenteringsprogrammer bruker for å sikre at de kan operasjonalisere praksisen på en effektiv måte, og nedenfor vil jeg skissere hvilken som passer best for din organisasjon. Jeg vil gå gjennom hver av disse strukturene og fordelene og ulempene ved hver av dem nedenfor:

• Senter for fremragende kvalitet
• Test Council (gjennomføring)
• Test-råd (hybrid)
• Individuelt team
• Hybrid

En ting jeg prøver å huske på og dele med kundene, er at disse strukturene bare er utgangspunkt. Alle selskaper har allerede en organisasjonsstruktur og arbeidsflyt for å bygge opplevelser og produkter som eksperimentering må passe inn i. Disse nye strukturene bør utløse en "Å, den strukturen ser kjent ut i forhold til det vi prøver å gjøre"-kommentar i stedet for "Vi må følge denne strukturen til punkt og prikke". Den første strukturen som identifiseres, bør fungere som en rettesnor, men ikke som fasit.

Et annet punkt jeg ofte prøver å få frem, er at de beste eksperimenteringsprogrammene har et sentralt team som leder programmet. Å få til en ekte eksperimenteringskultur er ikke noe man oppnår stykkevis og delt. Det må være minst én person som er fullt og helt dedikert til dette på daglig basis. Og derfra bør det ideelt sett være flere medlemmer av et sentralt team med spesifikk fagekspertise. Det er ikke sikkert at denne gruppen er fullt ut dedikert til å begynne med, men det er definitivt noe å strekke seg etter.

Her er tre hovedstrukturer jeg har sett hos de beste kundene jeg har hatt muligheten til å jobbe med. Hver av dem kan ha stor innvirkning på en organisasjon. Igjen, akkurat som ingen familier er like, er heller ikke to organisasjoner like. Den eneste veiledende regelen her er at du må gjøre dette unikt for din organisasjon hvis du ønsker å lykkes.

Senter for ekspertise

Jeg hører dette begrepet mest når bedrifter ønsker å skalere og skape en kultur for eksperimentering (det er også en praksis som brukes mye av organisasjonens analyseteam for å gjøre analyser av alt digitalt arbeid lettere tilgjengelig). Men definisjonen jeg bruker for Center of Excellence når det gjelder eksperimenteringsprogrammer, er litt strammere enn hvordan de fleste bruker det.

Organisasjonene som benytter seg av et Center of Excellence, er desentraliserte i sin produkt- og opplevelsesutvikling. Det er individuelle eiere av de testplanene som er tilpasset de relevante produktene og opplevelsene. Det er sjelden at eierskapet overlapper. Dette reduserer behovet for å koordinere ukentlig hvilke tester som er på trappene, hvordan de skal prioriteres og hvilke trinn som skal gjennomføres.

Et Center of Excellence er modellen der du trenger et dedikert eksperimenteringsteam - uten tvil. Uten et sentralt team som driver innføring og adopsjon av testing, kan programmet mislykkes. Siden eksperimenteringsteamet ikke har eierskap til produktet/opplevelsen de skal teste på selv, må de fokusere på å legge til rette for eksperimentering, for eksempel ved å dele beste praksis og læring, og måle resultatene og effekten av programmet som helhet.

Et Center of Excellence kan være riktig for deg hvis:

• Organisasjonen din allerede opererer desentralisert i andre deler av virksomheten, for eksempel innen analyse
• Du ikke trenger å ha konstant kontakt med de enkelte teamene; de eier sitt eget veikart, så det er bedre å ikke overbelaste dem med konstant gjennomgang
• Du er mer moden for testing - du har en sterk forståelse av hva eksperimentering betyr for bedriften, og hvert team forstår metodikken
• En tettere sentralisering kan hemme hastighetsmålene

Mitt utgangspunkt for å identifisere strukturen i en organisasjon er å skrive ut hvor eierskapet ligger for det sentrale teamet/lederne, i motsetning til de enkelte teamene. Dette kan gjøre det tydelig hvem som eier gjennomføringen for hvert trinn i et eksperiments livssyklus.

Slik ser dette ut for et Center of Excellence (jeg har også slike i hver av de følgende strukturene):

Et godt eksempel på et Center of Excellence er Optimizelys egen produkt-, design- og ingeniørorganisasjon. Vår programleder Becca Bruggmanshovedfokus er å legge til rette for beste praksis, læring og utdanning for de enkelte produktsjefene våre. Hun har ansvaret for å fastsette de overordnede KPI-ene og OKR-ene for programmet. Hvert kvartal rapporterer hun tilbake til ledelsen om fremdriften vår og identifiserer hvor vi kan bruke mer tid i de påfølgende kvartalene for å øke programmets modenhet.

Test Council (gjennomføringsmodell)

Jeg ser at de fleste selskaper i dag bruker en eller annen form for testråd. Jeg ser to ulike tilnærminger til dette: Gjennomføring og spredning. Grensen mellom disse to er hvor eierskapet ligger når man bygger og lanserer eksperimenter.

For begge typer testråd er det et must å møtes ukentlig eller annenhver uke for å koordinere prioriteringen og planen for tester. Hvis du er i en organisasjon der ulike funksjoner (f.eks. markedsføring og produkt) eller til og med individuelle produktsjefer har delt eierskap til opplevelsen som skal testes, må dere samarbeide fortløpende.

I noen Testing Councils ser jeg et dedikert team som administrerer det, på samme måte som det er et dedikert eksperimenteringsteam i et Center of Excellence. Det som er unikt, er at det dedikerte teamet i et Testing Council deltar aktivt i alle aspekter av et eksperiments livssyklus: Å hjelpe til med idéutvikling, design av test og analyse er alle trinn som teamet i et Center of Excellence sjelden deltar i.

Som navnet indikerer, har Execution-modellen et sentralt team som eier gjennomføringen (bygging og distribusjon) av eksperimenter. Her er et scenario: La oss si at det er slutten på det pågående møtet, og at dere som gruppe har bestemt hvilke kommende tester dere skal kjøre, og hva dere skal gjøre med resultatene som nettopp er analysert. Det er det sentrale teamets ansvar å få dette til å skje. Dere kommer til å trenge dedikerte utviklings- eller ingeniørressurser. Det er effektivt fordi du bare gir resten av organisasjonen i oppgave å fokusere på det som har høyest verdi: å komme opp med hypoteser og iverksette tiltak på bakgrunn av det programmet har lært.

Et testråd (gjennomføringsmodell) kan være riktig for deg hvis:

• Du ikke har full støtte fra utviklingsavdelingen eller teknisk avdeling til å gjennomføre eksperimenter ennå
• Du har ressurser i det sentrale teamet til å utvikle eksperimenter; dette kan være mer sannsynlig hvis du bruker en løsning på klientsiden
• Du ønsker at alle i organisasjonen skal fokusere på å bidra med ideer og forstå læring primært

Test-råd (spredt modell)

I den omvendte varianten av et testråd (Dispersed) ligger ansvaret for gjennomføringen i hendene på de relevante utviklings- og ingeniørene. Denne modellen passer når du ikke har disse ressursene i det sentrale teamet. Eller hvis det er lettere å unngå kollisjoner i retning av "hva er dette"-øyeblikk hvis du lar ressursene som allerede bygger produkter og opplevelser, gjøre det samme for tester.

Et møte hver eller annenhver uke er fortsatt nødvendig. Selv om produkt- eller utviklingsavdelingen kanskje trenger å bygge tester, er det sannsynlig at markedsføring, design og andre funksjoner vil ha gode ideer. Og jo flere utøvere du har, desto større er muligheten til å utvide programmet. De tar kanskje allerede med seg disse til produkt- og utviklingsavdelingen som endringer som ikke er tester. Jeg ser på dette som en mulighet til å lære dem hvorfor en hypotese er nyttig for de endringene de ber om. Over tid kan det konsekvente møtet bli mindre taktisk og mer om hva som er på trappene og hvilke resultater du har sett fra tester.

Jeg ser ofte denne modellen når flere produktteam eksperimenterer med det samme toppdomenet. I detaljhandelen kan dette være produktsjefer som eier individuelle trinn mot kjøp (søk, PDP, handlekurv osv.). Trafikkdeling, gjensidig eksklusivitet eller muligheter for tester på flere sider kan dukke opp.

Et testråd (Dispersed Model) kan være riktig for deg hvis:

• Du har full støtte fra utviklingsavdelingen eller teknisk avdeling til å utføre eksperimenter uten deres godkjenning
• Det er mange kokker på kjøkkenet: Mange jobber med det samme produktet og har behov for å snakke tettere sammen om hva som skal gjøres hver uke
• Prioritering er et kollektivt arbeid; du har kanskje fastsatte kriterier når noen sender inn en idé, men det er litt mer "kunst" å prioritere ukentlig
• Du ønsker fortsatt at alle skal komme sammen for å gå gjennom resultatene, selv om gjennomføringen og den innledende analysen gjøres på en desentralisert måte

Individuelt team

Jeg var med i et individuelt team da jeg ledet programmet i American Medical Association. Det var bare meg og teammedlemmet mitt fra analyseteamet som deltok og jobbet i Optimizely. Jeg måtte være rask. Jeg kjempet for å få muligheter til å teste. Jeg hadde ikke dedikerte ressurser utenfor vårt digitale analyseteam. Jeg brukte mye tid på å lære opp folk og håpet å komme til et punkt der ledelsen ville si: "La oss skalere dette." Jeg ser mange selskaper som fortsatt er i denne modusen, så ikke bli skremt hvis det er her du befinner deg. Et sted må man begynne.

Siden du kanskje føler at det er begrenset med ressurser og hvor du kan teste, bør du være litt mer kreativ når du prioriterer. Det kan bety at du må ta i bruk ideer som kanskje ikke oppfyller noen av standardkriteriene dine, når du kan lene deg på andre ressurser etter hvert som de blir tilgjengelige. Og bruk disse funnene som et bevis (når dere samler inn resultatene og erfaringene) for å få mer dedikerte ressurser.

Et Individual Team kommer til å bestå av folk som bare delvis er allokert til eksperimentering. Men kontaktpersonen din bør være minst 50 % eller mer. Det er mye som skal til for å drive effektiv eksperimentering, og du trenger noen som bruker en god del av tiden sin på det.

Et individuelt team kan være riktig for deg hvis:

• Du er i startfasen og har inkonsekvent involvering fra produkt-, utviklings- eller ingeniøravdelingen
• Du fortsatt holder på å lære organisasjonen din hva eksperimentering er og hvilken verdi det kan gi
• Du ønsker at andre i organisasjonen skal fokusere på å komme med ideer
• Hvor du kan teste er ganske begrenset på dette tidspunktet

På den andre siden av Optimizelys virksomhet er det markedsføringsteamet vårt som eier optimizely.com og eksperimentering. I dag opererer de som et individuelt team som administrerer sitt eget veikart og gjennomfører eksperimenter som de kan innenfor våre bredere initiativer for opplevelsen. Vi jobber fortsatt med å finne ut hvordan vi best kan sette mål for programresultater og involvere folk på tvers av go-to market-funksjonen vår. De har kjørt noen svært lærerike eksperimenter som bidro til redesignet vårt tidligere i år, og de har dedikerte utviklingsressurser på grunn av disse suksessene.

Hybrid

For organisasjoner med flere nivåer og flere produkter vil det mest sannsynlig være en kombinasjon av et Center of Excellence og Test Councils (og kanskje til og med individuelle team). Jeg kaller denne modellen en hybrid. En hybrid vil alltid ha et Center of Excellence som fører tilsyn med og støtter alle testteamene og måler programmets suksess. En hybrid kan støtte et hvilket som helst antall testråd eller individuelle team. Antallet av disse er ikke like viktig.

Alt du har lest ovenfor om de andre modellene, må brukes på hierarkiet nedenfor. Du tar bare bitene fra hver av dem og setter dem inn i puslespillet ditt. Innenfor hierarkiet kan det hende du trenger unike eiere til å lede de enkelte rådene hvis du ikke ønsker å belaste Center of Excellence med et team som skal lede dem. Men det kan være best å la Center of Excellence gjøre nettopp det. Siden de fokuserer på å dele beste praksis og erfaringer, finnes det ingen bedre måte å gjøre det på enn å gjøre det sammen med undermodellene hver uke.

En hybridmodell kan være riktig for deg hvis:

• Du har mange unike produkt- og opplevelsesteam som tester.
• Men det er ett (eller kanskje flere!) produkt eller opplevelser som trenger samarbeid med et testråd
• Det sentrale teamet ditt kan både være en intern tilrettelegger for beste praksis og læring, og samtidig sørge for at testrådet fungerer som det skal
• Dere har nådd et høyere modenhetsnivå og har tidligere gjennomført vellykkede tester på noen få produkter eller opplevelser

Betydningen av en viss sentralisering

Som nevnt innledningsvis, må du ha en sentral eier av programmet for å gjøre disse modellene til virkelighet. Når du etablerer det sentrale teamet, bør du fokusere på hvilke roller og ansvarsområder teamet skal ha i den daglige driften av programmet. Dette sentrale teamet vil være lederne for eksperimenteringen og bør få ansvarsområder som samsvarer med alle andre tverrfunksjonelle initiativer.

Nedenfor ser du de ideelle rollene som bør være representert i det sentrale teamet. Det er sjelden man har et helt dedikert sentralt eksperimenteringsteam med alle rollene som er oppført nedenfor. Disse kan fylles ved at allerede etablerte fageksperter bruker tid på å støtte programmets vekst. Andre roller kan også introduseres, avhengig av hvilke ytterligere behov programstrukturen din krever.

Et nødvendig første skritt er å finne ut hvor eierskapet ligger for hver av rollene i det sentrale teamet. Og hvor de andre skal bidra med innspill. Du kan bruke en RASCI-modell (eller en lignende modell) for å finne disse punktene. En ting å tenke på er at det nedenfor bare er hvordan Optimizely ser på hvor det er behov for eierskap. Du bør tilpasse disse til din bedrift og hvordan eksperimentering skal foregå.

Når det sentrale teamet begynner å lage styringsplaner, bør det fokusere på disse punktene som er uthevet i grønt nedenfor, for å sikre at de andre deltakerne fokuserer på de mest verdifulle elementene i eksperimentering: idéutvikling, utforming av tester og analyse.

Jeg håper det er helt klart at de fleste organisasjoner ikke har dette detaljnivået i utgangspunktet. Og det er enda sjeldnere at ressursene er der for å matche det. Men det er likevel nyttig å skissere en RASCI for det du har, og det kan bidra til å identifisere de ressurshullene du trenger å fylle.

Hva du bør tenke på når du utvider programmet

Husk at strukturen kan utvikle seg over tid. På kort sikt må du kanskje etablere en variant av et råd for å sikre at alle forstår eksperimenteringsmetodikken og hvordan man bygger opp eksperimenter på riktig måte. Men over tid vil du kanskje legge mer av eierskapet over på det enkelte teamet og utvikle et mer tradisjonelt Center of Excellence.

Dette ser vi ofte hos de største kundene våre. Vi trenger at alle forstår grunnlaget for eksperimentering, så vi holder det litt mer overordnet i starten. Parallelt kan vi gi mer opplæring for å heve nivået til de teamene som er nyere innen eksperimentering. Det vi mener er den beste opplæringen, er imidlertid å

-------

Er du klar til å komme i gang med eksperimentering? Ta kontakt med oss i dag.

Hvilke teamstrukturer har du sett som mest effektive i eksperimenteringsprogrammer du har vært en del av? Hva er noen av utfordringene med å få til en mer desentralisert struktur? Legg igjen en kommentar nedenfor!