Stoppa åtskildheterna! Hur man för samman team för att bygga upp ett framgångsrikt program för experimentering

Som Experimentation Manager kommer det att finnas många tillfällen då frasen "att valla katter" känns lite för nära inpå. Experimentering är en ny uppsättning processer och analytisk rigor som kräver konsekvens, och vi vet att konsekvens inte sker över en natt. Låt dig inte nedslås! Det här är normala växtvärk och den typ av ögonblick där din uthållighet är den viktigaste variabeln. Anledningen till att dessa stunder fortsätter att existera är att experimentering kräver att de allra flesta deltagare ändrar sitt sätt att arbeta. Istället för att göra en förändring av en komponent på hemsidan måste en utvecklare nu göra två builds. I stället för en enda analyspunkt måste man lära sig ett sekundärt system och en sekundär metodik. Med några enkla taktiker kan du vara säker på att spendera mindre tid på vallning och mer tid på testning.

Vi har sett från våra kunder att när fler människor är involverade, genomförs fler experiment (och mer effektiva experiment)!

Hur ska jag hantera alla dessa människor?!

En av de positiva effekterna av experimentering är att det kan öka samarbetet mellan olika funktioner i teamet. Det finns många roller som kan delta i experimentering för att öka dess värde, och du som programchef bör alltid sträva efter att få in fler människor. När du har fler personer involverade i ditt program kör du fler experiment, löser mer komplexa problem och kör experiment mer effektivt. Med fler människor innebär det också fler Slack-meddelanden som ser ut som "var är du med det här?" De kommer att behövas ibland, men du bör alltid ha dessa tre mekanismer på plats för att hantera alla som hjälper till att få ett experiment från idé till lansering.

• En plats för granskning: Jag är inget fan av möten. Jag har förespråkat att vi inte ska ha några 1-mot-1-möten på Optimizely (till ingen nytta). Jag måste dock medge att ett möte för experimentering är en förutsättning för att driva ett effektivt program. På Optimizely har vi vår veckovisa Experiment Review, där alla med en hypotes samlas för att dela med sig av resten av teamet. Jag är ett fan av kadens varannan vecka, men jag har kunder som också gör det varje vecka eller varje månad. Agendan för ditt möte behöver inte vara lång eller tidskrävande. Be helt enkelt dina lagkamrater att dyka upp redo att dela med sig av vad de planerar att lansera och resultaten av eventuella pågående eller nyligen avslutade experiment. Stryk in några av dina frågor som "vilka data stöder det kundproblemet?" eller "varför valde du det som ditt primära mätvärde?" och låt resten av teamet också ge feedback och tankar. Ditt mål som programchef är att underlätta och uppmuntra återkoppling mellan teamen.

• En plats för konvertering: När du går ut ur "rummet" (Zoom) efter ditt möte bör åtgärdsförslagen vara tydliga. Vet du vem som glömmer bort några av dessa åtgärder? Eller har en ny punkt av förtydligande på den primära mätfrågan? Det är jag. Jag behöver en uppföljningsplats för att kunna fråga min analytiker om varför det måttet faktiskt är en bättre ledande indikator på experimentets framgång. Det här är en annan managementpraxis som du inte behöver övertänka. Faktum är att mycket av det jag arbetar med mina kunder om är en "var gör ni den här typen av saker nu?"-diskussion. Om du hanterar praktikgemenskaper på Slack (Optimizely har till och med en Slack-integration!) Eller Microsoft Teams, gör du detsamma med dina experimenteringspraxis. Om du hanterar din backlog i Optimizely's Program Management kan du använda kommentarsfunktionen mycket enkelt för att samarbeta om öppna objekt. Speciellt när man skapar nya processer är det bra att "piggybacka" på det som redan finns för att minimera förändringshanteringen. På Optimizely har vi två kanaler. En för att hålla människor uppdaterade om experimentets framsteg (#experiment-feed) och en för att låta människor diskutera kommande eller tidigare experiment (#experiment-review). Som programansvarig ska du se till att hålla dina uppdateringar konstanta och konsekventa!

• En plats för utförande: Så du har din hypotes från mötet. Du har rett ut de sista detaljerna. Hur får du nu din utvecklare att hjälpa dig att bygga den? Om ditt utvecklingsteam arbetar i Jira (Optimizely har en integration för Jira också) så bör vi hjälpa dem genom att också arbeta i Jira. Ingen tycker om att lära sig ett nytt projekthanteringsverktyg! När våra hypoteser är redo för den relevanta ingenjören skapar vi en fråga i deras egen Jira-tavla som länkar till programledningen med mer information om vad vi gör och varför. På Optimizely använder vi både Program Management och Jira, eftersom Program Management innehåller all information om konfigurationen av experimentet, till exempel hypotes, mätvärden, bilder, medan Jira kommer att fokusera på vad som behöver byggas av vårt ingenjörsteam. Alla dessa åtgärder som sker i dessa utrymmen skalas upp ännu snabbare om du ger dina lagkamrater konsekvent dokumentation att använda. Denna konsekvens säkerställer att hur experimenten utförs är enligt de standarder som du sätter som programchef!

Hur kan jag använda data för att förstå var min tid behövs mest?

Den mest förbisedda delen av att driva ett program för experimentering är data. Nej, inte data om hur många fler konverteringar eller leads du har genererat. Jag pratar om den data som skapas när du startar ett experiment och hur den informerar om vilka typer av experiment du kör framåt när du lär dig mer om dina kunder. Tänk på hur mycket du vet om det experimentet:

• Hur länge det pågick
• Vilka sidor eller vilken målgruppsinriktning det hade
• Hur många variationer du använde
• Vilken typ av förändring(ar) du gjorde
• Vilka mätvärden det mättes mot
• Vilket eller vilka mätvärden som var statistiskt signifikanta
• Vilket steg i experimentet som tog längst tid att lansera

Du bör använda dessa datapunkter i alla dina experiment för att förstå vilka metoder som hjälper ditt program och vilka som inte gör det. Det här är de mätvärden som jag föreslår att varje kund ska spåra från dag ett för att förbereda sig för den här typen av analys.

Om du visste att mer målgruppsinriktade experiment skulle öka din vinstfrekvens, skulle jag gissa att du skulle köra mer målgruppsinriktade experiment. Om du visste att 50% av din ledtid för exekvering går åt till att få experiment genom QA, skulle jag gissa att du skulle börja utvärdera dina QA-steg och engagera dig för att effektivisera dem. Analysera affärsverksamheten i ditt program!

Vad gör mognare program annorlunda?

När jag får den här frågan talar jag om hur de program som gör hundratals experiment per år använder data om sig själva för att informera om vad de borde göra bättre (nu vet du varför just den specifika delen fick sitt eget avsnitt). Men det finns andra saker att fokusera på också! Dessa kan vara lättare att komma igång med än att skapa en hel uppsättning mätvärden att följa upp, särskilt om du är tidigare i din resa och bara kör några experiment i månaden. Det här är andra fokusområden för mogna program som du kan implementera i ditt eget program idag:

• Executive Buy-In - Det här händer inte över en natt om du inte har tur. Vanligtvis handlar det om en "bevisa det eller förlora det"-historia. Ett starkt program utnyttjar data för att mäta affärseffekterna och knyta en chef till programmet. Den här chefen hjälper till med resurser, att sätta en stadga och övervinna andra vägspärrar på vägen.
• Experiment Policies - Jag skrev lite om detta tidigare i en tidigare blogg, men en utmaning för att nå skala upp på antalet experiment du kör är att många människor bedömer experimentets framgång på olika sätt. Att skapa ett samförstånd, delat perspektiv på hur man analyserar resultat från experiment över alla dina mätvärden kommer att minska tiden till beslutsfattande. En bra policy att börja med är hur du fattar beslut mellan ditt primära och sekundära mätvärde. Om du har en statistiskt signifikant ökning av din klickfrekvens, är det tillräckligt bra om konverteringen till köp inte är statistiskt signifikant? Genom att fastställa dessa riktlinjer kan dina team agera snabbare.
• Utbildningsprogram - Ovanstående punkt är en enda egenskap hos skala upp-utmaningen "alla gör saker på olika sätt". För att få ut mesta möjliga av experimentering måste det finnas några konsekventa metoder i ditt program. Inte bara hur du gör analyser, utan hur skriver du en hypotes? Hur använder du dina data för att informera dem? Hur utnyttjar du tredjepartsdata för målgruppsinriktning? Dessa och så många andra frågor kan besvaras i ett utbildningsprogram. Bra program sträcker sig från några få sessioner till en tvåveckors "kurs" där allt om experimentering ges till deras lagkamrater. Jag skulle vilja göra detta till en del av introduktionen om du kan. Det är lätt att komma igång med detta med Optimizely's Academy också! Se till att dokumentera alla dessa metoder så att de enkelt kan delas i hela organisationen, även om det inte ingår i utbildningsprogrammets läroplan - ditt framtida jag kommer att tacka dig.
• OKRs - När experimentering blir ett fokus för din organisation bör ni mäta varandra mot det. Vår egen programchef skrev om vikten av detta för att uppmuntra våra Product Managers att vara mer aktiva deltagare i experimentering. Den här aspekten av programmet kan smälta väl samman med de mätningar på programnivå som ni infört. Om du mäter ditt program genom antalet startade experiment och antalet variationer som körs, kan du mäta varje personalisera genom dessa metoder också! Se till att spara tid för att dela med er till varandra så att ni kan utvärdera vilka OKR-mått som verkligen påverkar programmets totala framgång.

Så, vad är takeaways?

Jag har sagt en hel del om hur du kan få bort åtskildheter och skapa ett mer samarbetsinriktat program. Men vad kan du egentligen fokusera på i morgon (eller nästa vecka!)?

• Se till att utse en programansvarig och nyckelroller i alla team. Inget program för experimentering lyckas utan någon som gör minst 50% av sin roll om programmet. Det finns för många katter att valla. Ta din RACI för arbetsflödet och ge den till teamen så att de vet hur de ska genomföra ett experiment från början till slut. Börja mäta ROI för programmet om det finns resursgap som du måste kämpa för.
• För samman människor på samma sätt som de gör nu. Du behöver inte återskapa hjulet eller, i det här fallet, nya processer. Om du har Slack och JIRA som dina arbetsflödesverktyg just nu, använd dem bara. Du kommer att behöva det där mötet också!
• Mät ditt program för ineffektivitet så att du vet var du ska spendera tid som programchef. Du behöver inte vidta åtgärder för någonting under den första månaden eller ens det första året. Men det kommer att finnas en punkt där dessa data hjälper dig att svara på en fråga som du inte förväntade dig.