Möjliggöra experimentering i din organisation: Bestämma din teamstruktur

Att skala upp experimentering är ofta den svåraste utmaningen för organisationer när de börjar se de konkreta resultaten av experimenten. Företagen börjar fokusera på hur de ska göra praktiken till en realitet i alla aspekter av verksamheten. Att fastställa roller, ansvarsområden och arbetsflöden i ett expanderande program för experimentering kan verka som en skrämmande uppgift, men det är viktigt för att göra skala upp till verklighet.

Förhoppningsvis är din organisation också redo för att skala upp sitt program och sin framgång! Som Lead Strategy Consultant på Optimizely har jag sett många olika sätt för organisationer att skapa denna struktur. Det finns typiska strukturer som experimenteringsprogram använder för att säkerställa att de kan operationalisera praxis effektivt, och nedan kommer jag att beskriva vilken som bäst passar din organisation Och jag kommer att gå igenom var och en av dessa strukturer och fördelarna och nackdelarna med var och en nedan:

• Center för spetskompetens
• Testningsråd (utförande)
• Testråd (hybrid)
• Individuellt team
• Hybrid

En sak som jag försöker komma ihåg och dela med mig av till kunderna är att dessa strukturer bara är startpunkter. Varje företag har redan en organisationsstruktur och arbetsflöden för att bygga upp sina upplevelser och produkter inom vilka experimentering måste passa in. De nya strukturerna bör leda till en kommentar av typen "Åh, den strukturen ser bekant ut för det vi försöker göra" i stället för "Vi måste följa den här strukturen till punkt och pricka". Den första identifierade strukturen bör fungera som en ledstjärna, men inte som en universallösning.

En annan sak som jag ofta försöker få fram är att de bästa programmen för experimentering har ett centralt team som leder programmet. Att få till stånd en verklig experimenteringskultur är inte något som åstadkoms bit för bit. Det måste finnas minst en person som är helt dedikerad på daglig basis. Och därifrån helst fler medlemmar i ett centralt team med specifik ämnesexpertis. Den här gruppen kanske inte är helt dedikerad till att börja med, men det är definitivt något att sträva efter.

Här är tre primära strukturer som jag har sett hos de bästa kunderna som jag har haft möjlighet att arbeta med. Var och en av dem kan ha en enorm inverkan på en organisation. Precis som det inte finns två familjer som är lika varandra, finns det inte heller två organisationer som är lika varandra. Den enda vägledande regeln här: du måste göra detta unikt för din organisation om du vill lyckas.

Centrum för spetskompetens

Jag hör den här termen mest när företag vill skala upp och skapa en experimenteringskultur (det är också en metod som används flitigt av organisationens analysteam för att göra analyser av allt digitalt arbete mer lättillgängliga). Men den definition jag använder för Center of Excellence när det gäller program för experimentering är lite snävare än hur de flesta använder den.

De organisationer som använder sig av ett Center of Excellence är decentraliserade i sin produkt- och upplevelseutveckling. Det finns individuella ägare av dessa roadmaps för testning som är anpassade till relevanta produkter och upplevelser. Sällan överlappar dessa ägare varandra. Detta minskar behovet av att varje vecka samordna vilka tester som ska genomföras, hur de ska prioriteras och vilka steg som ska tas.

Ett Center of Excellence är den modell där du behöver ett dedikerat team för experimentering - det är inget snack om saken. Utan ett centralt team som kan driva på införandet och tillämpningen av testning kan programmet misslyckas. Eftersom experimenteringsteamet inte kommer att äga produkten/upplevelsen som de ska testa på själva måste de fokusera på att underlätta experimentering, till exempel genom att dela bästa praxis, lärdomar och mäta resultatet och effekten av programmet som helhet.

Ett Center of Excellence kan vara rätt för dig om:

• Din organisation redan arbetar decentraliserat inom andra delar av verksamheten, t.ex. inom analys
• Du inte behöver ha ständig kontakt med enskilda team; de äger sin egen roadmap så det är bättre att inte överbelasta dem med ständig granskning
• Du är mer mogen för testning - du har en stark förståelse för vad experimentering betyder för ditt företag och varje team förstår metodiken
• En hårdare centralisering kan hämma hastighetsmålen

Min utgångspunkt för att identifiera strukturen i en organisation är att skriva ut var ägandet ligger för det centrala teamet/ledarna i motsats till de enskilda teamen. Detta kan göra det tydligt vem som äger utförandet för varje steg i ett experiments livscykel.

Så här ser det ut för ett Center of Excellence (jag har också sådana i var och en av följande strukturer):

Ett bra exempel på ett Center of Excellence är Optimizelys egen produkt-, design- och ingenjörsorganisation. Vår programchef Becca Bruggmanshuvudfokus är att underlätta bästa praxis, lärdomar och utbildning för våra enskilda produktchefer. Hon ansvarar för att fastställa de övergripande KPI:erna och OKR:erna för programmet. Varje kvartal rapporterar hon tillbaka till ledningen om våra framsteg och identifierar var vi kan lägga mer tid under kommande kvartal för att öka programmets mognad.

Rådet för testning (genomförandemodell)

Det jag ser att de flesta företag använder sig av idag är någon form av testråd. Jag ser två olika tillvägagångssätt för detta: Utförande och spridd. Gränsen mellan dessa två är var ägandet ligger när man bygger och lanserar experiment.

Med båda typerna av testråd är ett möte varje vecka eller varannan vecka ett måste för att samordna din prioritering och roadmap för tester. Om du är i en organisation där olika funktioner (t.ex. marknadsföring och produkt) eller till och med enskilda Product Managers har marknadsandelar i upplevelsen som testas, måste du samarbeta löpande.

I vissa Testing Councils ser jag ett helt dedikerat team som hanterar det på samma sätt som det finns ett dedikerat experimenteringsteam i ett Center of Excellence. Det som är unikt är att ett Testing Councils dedikerade team är en aktiv deltagare i alla aspekter av ett experiments livscykel: att hjälpa till med idéer, utformning av test och analys är alla steg som ett Center of Excellence-team sällan deltar i.

Som namnet antyder har Execution-modellen ett centralt team som äger genomförandet (bygga och distribuera) av experimenten. Här är ett scenario: Säg att det är slutet på ert pågående möte och att ni som grupp har bestämt vilka kommande tester ni ska köra och vad ni ska göra med de resultat som just har analyserats. Det är det centrala teamets ansvar att få detta att hända. Du kommer att behöva dedikerade utvecklings- eller ingenjörsresurser. Det är effektfullt eftersom du bara ger resten av organisationen i uppgift att fokusera på det som har högst värde: att ta fram hypoteser och vidta åtgärder utifrån programmets lärdomar.

Ett testråd (Execution Model) kan vara rätt för dig om:

• Du inte har fullt stöd från utveckling eller teknik ännu för att genomföra experiment
• Du har resurser i ditt centrala team för att utveckla experiment; detta kan vara mer troligt om du använder en lösning på klientsidan
• Du vill att alla i din organisation ska fokusera på att bidra med idéer och förstå lärdomar i första hand

Rådet för testning (utspridd modell)

Den omvända varianten av ett testråd, Dispersed, lägger utförandesteget i relevanta utvecklings- och ingenjörshänder. Den här modellen passar när du inte har de resurserna i det centrala teamet. Eller om det är lättare att undvika kollisioner i stil med "vad är det här"-moment om du låter de resurser som redan bygger produkter och upplevelser göra samma sak för tester.

Ett möte varje vecka eller varannan vecka är fortfarande nödvändigt. Även om produkt- eller teknikavdelningen kan behöva bygga tester är det troligt att marknadsförings-, design- och andra funktioner har bra idéer. Och ju fler utövare du har, desto större är möjligheten att utveckla programmet. De kanske redan tar med sig dessa till produkt- och teknikavdelningen som förändringar som inte är tester. Jag ser detta som en möjlighet att lära dem varför en hypotes är användbar för de ändringar de begär. Med tiden kan det konsekventa mötet bli mindre taktiskt och mer handla om vad som är på gång och vilka resultat du har sett från tester.

Jag ser ofta den här modellen när flera produktteam gör experiment på samma toppdomän. Inom detaljhandeln kan detta vara Product Managers som äger enskilda steg mot köp (sök, PDP, kundvagn etc.). Trafikdelning, ömsesidig exklusivitet eller möjligheter till tester på flera sidor kan komma upp.

Ett testråd (Dispersed Model) kan vara rätt för dig om:

• Du inte har fullt stöd från utvecklingsavdelningen eller teknikavdelningen för att genomföra experiment utan deras godkännande
• Det finns många kockar i köket: många människor arbetar med samma produkt och behöver prata mer ingående om vad som ska göras varje vecka
• Prioritering är en kollektiv ansträngning; du kanske har fastställt kriterier när någon skickar in en idé, men det är lite mer "konst" att prioritera varje vecka
• Du vill fortfarande att alla ska samlas för att gå igenom resultaten, även om genomförandet och den inledande analysen görs på ett decentraliserat sätt

Individuellt team

Jag ingick i ett individuellt team när jag drev programmet på American Medical Association. Det var bara jag och min teammedlem från analysteamet som deltog och arbetade i Optimizely. Jag var tvungen att vara stridslysten. Jag kämpade för att få möjlighet att testa. Jag hade inga dedikerade resurser utanför vårt Digital Analytics-team. Jag ägnade mycket tid åt att utbilda folk och hoppades att komma till en brytpunkt där ledningen skulle säga: "Låt oss skala upp det här." Jag ser många företag som fortfarande befinner sig i det här läget, så bli inte orolig om det är där du är. Man måste börja någonstans.

Eftersom du kanske känner dig begränsad när det gäller resurser och var du kan testa bör du vara lite mer kreativ i din prioritering. Det kan innebära att du tar dig an idéer som kanske inte uppfyller några av dina standardkriterier när du kan luta dig mot andra resurser när de blir tillgängliga. Och använd dessa resultat som en bevispunkt (när du samlar in dina resultat och lärdomar) för att få mer dedikerade resurser.

Ett individuellt team kommer att bestå av människor som bara delvis är avsatta för experimentering. Men din kontaktperson bör vara minst 50 % eller mer. Det krävs mycket för att driva experimentering på ett effektivt sätt och du behöver någon som lägger en stor del av sin tid på det.

Ett individuellt team kan vara rätt för dig om:

• Du precis har börjat och har ett ojämnt engagemang från produkt-, utvecklings- eller teknikavdelningen
• Du fortfarande håller på att lära din organisation vad experimentering är och vilket värde det kan ge
• Du vill att andra i din organisation ska fokusera på att komma med idéer
• Var du kan testa är ganska begränsat vid denna tidpunkt

På andra sidan av Optimizelys verksamhet finns vårt marknadsföringsteam som äger optimizely.com och dess experimentering. Idag arbetar de som ett individuellt team som hanterar sin egen roadmap och utför experiment som de kan inom våra bredare initiativ för upplevelsen. Vi arbetar fortfarande med hur vi bäst kan fastställa åtgärder för programutdata och bättre involvera människor i hela vår go-to market-funktion. De har genomfört några lärorika experiment som låg till grund för vår omdesign tidigare i år och har avsatt utvecklingsresurser på grund av dessa framgångar.

Hybrid

För organisationer med flera nivåer och flera produkter kommer det troligen att finnas en kombination av ett Center of Excellence och testråd (och kanske till och med enskilda team). Jag kallar den här modellen för en hybrid. En hybridmodell har alltid ett Center of Excellence som övervakar och stöder alla testteam och mäter programmets framgång. En hybrid kan stödja valfritt antal testråd eller individuella team. Antalet av dessa är inte lika viktigt.

Allt du har läst ovan om de andra modellerna måste tillämpas på hierarkin nedan. Du tar bara bitarna från var och en och passar in dem i ditt pussel. Inom hierarkin kan du behöva unika Owner för att driva de enskilda råden om du inte vill belasta Center of Excellence med ett team som ska driva dem. Men det kan vara bäst att låta Center of Excellence göra just det. Eftersom de fokuserar på att dela med sig av bästa praxis och lärdomar finns det inget bättre sätt än att leva det med undermodellerna varje vecka.

En hybrid kan vara rätt för dig om:

• Du har många unika produkt- och upplevelseteam som testar
• Men det finns en (eller kanske flera!) produkt eller upplevelser som behöver samarbetet med ett testråd
• Ditt centrala team kan både vara en intern facilitator av bästa praxis och lärdomar, och samtidigt se till att Testing Council fungerar smidigt
• Du har nått en högre mognadsgrad och har haft en historia av framgångsrik testning av ett fåtal produkter eller upplevelser

Vikten av viss centralisering

Som nämndes i början måste du utse en central ägare av programmet för att göra dessa modeller till verklighet. När du etablerar ditt centrala team bör du fokusera på vilka roller och ansvarsområden teamet kommer att ha för det dagliga arbetet med programmet. Detta centrala team kommer att vara ledare för experimentering och bör ges ansvar som matchar precis som alla andra av dina tvärfunktionella initiativ.

De ideala rollerna som bör finnas representerade i ditt centrala team finns nedan. Det är ovanligt att ha ett helt dedikerat centralt team för experimentering med alla de roller som anges nedan. Dessa kan fyllas genom att redan etablerade ämnesexperter lånar ut tid för att stödja programmets tillväxt. Andra roller kan också införas beroende på vilka ytterligare behov din programstruktur kräver.

Ett nödvändigt första steg är att ta reda på var ägandet ligger för var och en av det centrala teamets roller. Och var de andra behövs för att ge input. Du kan använda RASCI (eller en liknande modell) för att fastställa dessa punkter. En sak att tänka på är att nedanstående bara är hur Optimizely One ser på var ägandet behövs. Du bör göra dessa unika för ditt företag och hur experimentering kommer att fungera.

När det centrala teamet börjar skapa styrningsplaner bör det fokusera på de punkter som är grönmarkerade nedan för att säkerställa att de andra deltagarna fokuserar på de mest värdefulla punkterna i experimentering: idé, utformning av test och analys.

Jag hoppas att det står helt klart att de flesta organisationer inte har den här detaljnivån från början. Och det är ännu mer sällsynt att resurserna finns där för att matcha. Men att skissera en RASCI för det du har är ändå en användbar övning och kan hjälpa dig att identifiera de resursluckor som du behöver fylla.

Vad du bör tänka på när du utvecklar ditt program

Tänk på att din struktur kan komma att utvecklas över tid. På kort sikt kanske du behöver inrätta en variant av ett råd för att se till att alla förstår metoden för experimentering och hur man bygger upp experiment på rätt sätt. Men med tiden vill du lägga mer av ägandet i händerna på det enskilda teamet och utveckla ett mer traditionellt Center of Excellence.

Vi ser ofta detta hos våra största kunder. Vi vill att alla ska förstå grunderna i experimentering, så i början håller vi det på en lite högre nivå. Parallellt kan vi erbjuda mer utbildning för att höja nivån på de team som är nyare inom experimentering. Det som vi anser vara den bästa utbildningen är dock att

-------

Är du redo att komma igång med experimentering? Hör av dig till oss idag.

Vilka teamstrukturer har du sett vara mest effektiva i experimenteringsprogram som du har varit en del av? Vilka är några av utmaningarna med att få till en mer decentraliserad struktur? Lämna en kommentar nedan!