Muliggjøre eksperimentering i organisasjonen din: Bestemme teamstrukturen din

Skalering eksperimentering er ofte den tøffeste utfordringen for organisasjoner når de begynner å se konkrete resultater av eksperimenter. Bedrifter begynner å fokusere på hvordan de kan gjøre praksisen til virkelighet i alle aspekter av virksomheten. Å bestemme roller, ansvar og arbeidsflyter i et voksende eksperimenteringsprogram kan virke som en skremmende oppgave, men det er viktig for å gjøre skalering til virkelighet.

Forhåpentligvis er organisasjonen din klar for å skalere programmet og suksessen også! Som ledende strategikonsulent hos Optimizely har jeg sett mange måter organisasjoner lager denne strukturen på. Det finnes typiske strukturer eksperimenteringsprogrammer bruker for å sikre at de kan operasjonalisere praksisen effektivt, og nedenfor vil jeg skissere hvilken som passer best for din organisasjon. Og jeg vil... Gå gjennom hver av disse strukturene og fordelene og ulempene med hver av dem nedenfor:

• Senter for fremragende forskning
• Testingsråd (utførelse)
• Testingsråd (hybrid)
• Individuelt team
• Hybrid

Én ting jeg prøver å Det viktigste å huske på og dele med kundene er at disse strukturene bare er utgangspunkt. Alle selskaper har allerede en organisasjonsstruktur og arbeidsflyter for å bygge sine opplevelser og produkter som eksperimentering må passe inn i. Disse nye strukturene bør fremkalle en kommentar som sier: «Åh, den strukturen ser kjent ut for det vi prøver å gjøre», kontra en kommentar som sier: «Vi må følge denne strukturen til punkt og prikke.» Den identifiserte strukturen bør tjene som en veiledende lyskilde, men ikke som alt-i-en.

Et annet punkt jeg ofte prøver å få frem, er at de beste eksperimenteringsprogrammene har et sentralt team som leder programmet. Å oppnå en ekte eksperimenteringskultur oppnås ikke stykkevis. Det må være minst én person som er fullt dedikert på daglig basis. Og derfra ideelt sett flere medlemmer av et sentralt team med spesifikk fagekspertise. Denne kohorten er kanskje ikke fullt dedikert til å starte med, men det er definitivt noe å strebe etter.

Her er tre primære strukturer jeg har sett hos ledende kunder jeg har hatt muligheten til å jobbe med. Hver av dem kan ha en enorm innvirkning på en organisasjon. Igjen, akkurat som ingen familier er like, er heller ingen organisasjoner like. Den eneste veiledende regelen her: du må gjøre dette unikt for organisasjonen din hvis du vil lykkes.

Senter for fremragende utvikling

Jeg hører dette begrepet oftest når bedrifter ønsker å skalere og skape en eksperimenteringskultur (det er også en praksis som brukes mye av organisasjoners analyseteam for å gjøre analyser av alt digitalt arbeid lettere tilgjengelige). Men definisjonen jeg bruker for et kompetansesenter når det gjelder eksperimenteringsprogrammer er litt strammere enn hvordan de fleste bruker det.

Organisasjonene som bruker et kompetansesenter er desentraliserte i sin produkt- og opplevelsesutvikling. Det finnes individuelle eiere av disse testplanene som er tilpasset de relevante produktene og opplevelsene. Disse overlapper sjelden i eierskap. Dette reduserer behovet for å koordinere ukentlig om hvilken testing som er kommende, prioritering og trinn som skal utføres.

Et kompetansesenter er modellen der du trenger et dedikert eksperimenteringsteam – ingen tvil om det. Uten et sentralt team for å drive onboarding og adopsjon av testing, kan programmet mislykkes. Siden eksperimenteringsteamet ikke vil ha eierskap til produktet/erfaringen de kan teste på seg selv, må de fokusere på å være tilrettelegger for eksperimentering, for eksempel ved å dele beste praksis, lærdom og måle resultatet og effekten av programmet som helhet.

Et kompetansesenter kan være riktig for deg hvis:

• Organisasjonen din opererer allerede desentralisert i andre deler av virksomheten, for eksempel analyse
• Du trenger ikke at individuelle team er i konstant kontakt; De eier sin egen veikart, så det er bedre å ikke overbelaste dem med konstant gjennomgang.
• Du er mer moden til testing – du har en sterk forståelse av hva eksperimentering betyr for bedriften din, og hvert team forstår metodologier.
• Stretere sentralisering kan hemme hastighetsmål.

Mitt utgangspunkt for å identifisere strukturen i en organisasjon er å skrive ut hvor eierskapet ligger hos det sentrale teamet/lederne i motsetning til individuelle team. Dette kan gjøre det tydelig hvem som eier utførelsen for hvert trinn i et eksperiments livssyklus.

Slik ser dette ut for et kompetansesenter (jeg har disse også i hver av de følgende strukturene):

Et godt eksempel på et kompetansesenter er Optimizelys egen produkt-, design- og ingeniørorganisasjon. Programlederen vår Becca Bruggman har som hovedfokus å legge til rette for beste praksis, læring og opplæring til våre individuelle produktledere. Hun har ansvaret for å sette 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 påfølgende kvartaler for å øke programmodenheten vår.

Testingsråd (utførelsesmodell)

Det jeg ser at de fleste selskaper bruker i dag, er en slags form for et testingsråd. Jeg ser to forskjellige tilnærminger til dette: Utførelse og Dispersed. Grensen mellom disse to er hvor eierskapet ligger når man bygger og lanserer eksperimenter.

Med begge typer testråd er et ukentlig eller annenhver uke et must for å koordinere prioritering og veikart 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 testes på, må du samarbeide kontinuerlig.

Med noen testråd ser jeg et fullt dedikert team som administrerer det omtrent som det er et dedikert eksperimenteringsteam i et kompetansesenter. Det unike er at et dedikert team i et testråd er en aktiv deltaker i alle aspekter av et eksperiments livssyklus: hjelp med idéutvikling, testdesign og analyse er alle trinn et team fra et kompetansesenter sjelden deltar i.

Som navnet indikerer, har utførelsesmodellen et sentralt team som eier utførelsen (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å det til å skje. Dere trenger dedikerte utviklings- eller ingeniørressurser. Det er effektivt fordi dere bare gir resten av organisasjonen i oppgave å fokusere på de viktigste elementene: å komme opp med hypoteser og iverksette tiltak basert på programmets lærdommer.

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

• Du ikke har full støtte fra utviklings- eller ingeniøravdelingen ennå til å utføre eksperimenter
• Du har ressurser i ditt sentrale team til å utvikle eksperimenter; Dette kan være mer sannsynlig hvis du bruker en klientsideløsning
• Du vil at alle i organisasjonen din skal fokusere på å bidra med ideer og forstå lærdom primært

Testingsråd (spredt modell)

På motsatt side legger den spredte smaken av et testingsråd utførelsestrinnet i de relevante hendene innen utvikling og ingeniørfag. 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 ukentlig eller annenhver uke er fortsatt nødvendig. Selv om produkt- eller ingeniøravdelingen 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 å utvikle programmet. De kan allerede bringe disse inn i produkt- og ingeniøravdelingen som endringer som ikke er tester. Jeg ser dette som en mulighet til å lære dem hvorfor en hypotese er nyttig for endringene de ber om. Over tid kan det jevnlige møtet bli mindre taktisk og mer rettet mot hva som kommer og hvilke resultater du har sett fra testene.

Jeg ser ofte denne modellen når flere produktteam eksperimenterer på samme toppnivådomene. 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 flersidede tester kan dukke opp.

Et testråd (spredt modell) kan være riktig for deg hvis:

• Du HAR! full støtte fra utviklings- eller ingeniøravdelingen til å utføre eksperimenter uten deres godkjenning
• Det er mange kokker på kjøkkenet: mange jobber med det samme produktet og trenger å snakke tettere om hva som skal gjøres ukentlig
• Prioritering er en kollektiv innsats; Du har kanskje satt kriterier når noen sender inn en idé, men det er litt mer «kunst» med den ukentlige prioriteringen.
• Du vil fortsatt at alle skal komme sammen for å gjennomgå resultater, selv om utførelse og innledende analyse gjøres på en desentralisert måte.

Individuelt team

Jeg var i et individuelt team da jeg drev programmet hos American Medical Association. Det var bare jeg og teammedlemmet mitt fra analyseteamet som deltok og jobbet i Optimizely. Jeg måtte være forsiktig. Jeg kjempet for 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 vippepunkt der ledelsen ville si: «La oss skalere dette.» Jeg ser at mange selskaper fortsatt er i denne modusen, så ikke bli skremt hvis det er her du er. Du må starte et sted.

Siden du kanskje føler begrensninger på ressurser og hvor du kan teste, bør du være litt mer kreativ med prioriteringen din. Dette kan bety å ta på seg ideer som kanskje hopper over noen av standard poengkriterier når du kan lene deg inn i andre ressurser etter hvert som de blir tilgjengelige. Og bruk disse funnene som et bevispunkt (når du samler inn resultatene og lærdommene dine) for å få mer dedikerte ressurser.

Et individuelt team vil være en samling av folk som bare delvis er allokert til eksperimentering. Men kontaktpersonen din bør være minst 50 % eller over. Mye går med til å drive eksperimentering effektivt, 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 akkurat i gang og har inkonsekvent involvering fra produkt, utvikling eller ingeniørvirksomhet
• Du lærer fortsatt organisasjonen din hva eksperimentering er og verdien det kan drive
• Du vil at andre i organisasjonen din skal fokusere på å komme med ideer
• Hvor du kan teste er ganske begrenset på dette tidspunktet poeng

På den andre siden av Optimizelys virksomhet finner vi markedsføringsteamet vårt som eier optimizely.com og eksperimenteringen. I dag opererer de som et individuelt team som administrerer sin egen plan og utfører eksperimenter så godt de kan innenfor våre bredere initiativer for opplevelsen. Vi jobber fortsatt med hvordan vi best kan sette mål for programutbytte og bedre involvere folk på tvers av vår markedsfunksjon. Til deres ære har de kjørt noen læringseksperimenter som informerte redesignet vårt tidligere i år, og har dedikert utviklingsressurser på grunn av disse suksessene.

Hybrid

For flerlagsorganisasjoner med flere produkter vil det mest sannsynlig være en kombinasjon av et kompetansesenter og testråd (og kanskje til og med individuelle team). Jeg kaller denne modellen en hybrid. En hybrid vil alltid ha et kompetansesenter som fører tilsyn med og støtter alle testteam 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 brikkene i hver og setter dem inn i puslespillet ditt. Innenfor hierarkiet kan det hende du trenger unike eiere til å drive de individuelle rådene hvis du ikke vil belaste kompetansesenteret med team for å drive disse. Men det kan være best å la kompetansesenteret gjøre nettopp det. Siden de fokuserer på å dele beste praksis og lærdom, finnes det ingen bedre måte enn å leve det med delmodellene hver uke.

En hybrid 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 fra et testråd
• Det sentrale teamet ditt kan støtte både å være en intern tilrettelegger for beste praksis og lærdom, samtidig som de sørger for at testrådet går knirkefritt
• Du er mer moden og har hatt en historie med vellykket testing av noen få produkter eller erfaring

Viktigheten av noe sentralisering

Som nevnt i starten, må du utnevne en sentral eier av programmet for å gjøre disse modellene til virkelighet. Når du etablerer det sentrale teamet ditt, bør du fokusere på hva rollene og ansvaret til teamet vil være for den daglige driften av programmet. Dette sentrale teamet vil være ledere av eksperimenteringen og bør gis ansvar som samsvarer akkurat som alle andre av dine tverrfaglige initiativer.

De ideelle rollene som bør være representert i det sentrale teamet ditt er nedenfor. Det er sjelden å ha et fullstendig dedikert sentralt eksperimenteringsteam med alle rollene som er oppført nedenfor. Disse kan fylles ved å la allerede etablerte fageksperter låne tid til å støtte programmets vekst. Andre roller kan også introduseres avhengig av hvilke tilleggsbehov programstrukturen din krever.

Et nødvendig første skritt er å finne ut hvor eierskapet ligger for hver av rollene i sentralteamet ditt. Og hvor de andre trengs for å gi innspill. Du kan bruke en RASCI (eller lignende modell) for å bestemme disse punktene. En ting å vurdere er at det følgende viser hvordan Optimizely ser på kategoriene med hvor eierskap er nødvendig. Du bør gjøre disse unike for din bedrift og hvordan eksperimenteringen vil fungere.

Når det sentrale teamet begynner å lage styringsplaner, bør det fokusere på disse elementene som er uthevet i grønt nedenfor for å sikre at de andre deltakerne fokuserer på elementene med høyest verdi i eksperimenteringen: idéutvikling, testdesign og analyse.

Jeg håper det er helt klart at de fleste organisasjoner ikke har dette detaljnivået i starten. Og enda sjeldnere er det at ressursene matcher. Men å skissere en RASCI for det du har er fortsatt en nyttig øvelse og kan bidra til å identifisere de ressurshullene du må fylle.

Hva du bør tenke på når du utvikler programmet ditt

Husk at strukturen din kan utvikle seg over tid. Kanskje du på kort sikt må etablere en variant av et råd for å sikre at alle forstår eksperimenteringsmetodikken og hvordan man bygger eksperimenter riktig. Men over tid ønsker du å legge mer av dette eierskapet i hendene til det enkelte teamet og utvikle et mer tradisjonelt kompetansesenter.

Vi ser dette ofte med våre største kunder. Vi trenger at alle forstår grunnlaget for eksperimentering, så vi holder det litt høyere i starten. Parallelt kan vi gi mer opplæring for å heve nivået på de teamene som er nyere innen eksperimentering. Det vi ser på som den beste opplæringen er imidlertid å

——————–

Klar til å komme i gang med eksperimentering?Kontakt oss i dag.

Hvilke teamstrukturer har du sett være 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!