Produkt–process-gapet: Så stoppar du detta läckage i organisationens budget

Läs transkriptet:

Vi testar att transkribera våra poddar med hjälp av ett program. Ha överseende med eventuella stavfel eftersom boten inte har rätt 100 procent av gångerna.

Hannah Clark: En av de fantastiska sakerna med agila organisationer är att vi ständigt experimenterar och lär oss för att förbättra våra organisationer och de produkter vi erbjuder. Varje tekniskt genombrott är resultatet av någon form av experimentering, men här är baksidan: experiment leder inte alltid till positiva resultat. Faktum är att många experiment är kraftigt bristfälliga – och när hundratusentals dollar står på spel beroende på resultatet av ett experiment är det sista vi vill att fatta beslut utifrån felaktiga data. Och här kommer den skrämmande delen: för det mesta inser vi inte ens att datan är felaktig förrän det är för sent.

Min gäst i dag är Manuel Da Costa, grundare av Effective Experiments. Som du säkert kan förstå av namnet på hans organisation är Manuel främst inriktad på att hjälpa organisationer att genomföra bättre experiment, vilket leder till bättre produktbeslut. Även om rätt verktyg definitivt kan hjälpa oss att förbättra experimentering och dataanalys har han också identifierat ett fenomen som uppstår i marginalerna av organisationsschemat och som kallas produkt–process-gapet – och det kostar teknikföretag miljontals kronor i det tysta. Låt oss börja.

Välkommen tillbaka till podden The CPO Club. I dag har jag Manuel Da Costa med mig.

Manuel, stort tack för att du är med oss i dag.

Manuel Da Costa: Hej allihop! Hannah, tack för att du bjöd in mig.

Hannah Clark: Kan du berätta lite om din bakgrund och hur du hamnade där du är i dag?

Manuel Da Costa: Absolut. Jag är grundare av Effective Experiments. Vi är ett företag som tillhandahåller programvara för att hjälpa företag att samarbeta bättre och fatta bättre produktbeslut. Min bakgrund började långt tillbaka, ungefär i miljön kring lean startup, där jag lärde mig om detta test- och lärandebaserade arbetssätt för validering. Sedan tog jag mig in i världen av konverteringsoptimering och gradvis vidare till min egen produkt, där vi verkligen hjälper produkt- och CX-team att arbeta bättre tillsammans.

Och det leder mig till den punkt i karriären där jag nu behöver berätta den här historien, vilket är anledningen till att vi är här i den här podden.

Hannah Clark: Jag ser fram emot att fördjupa mig i det.

Det vi ska fokusera på i dag är ett fenomen som du har kallat produkt–process-gapet. Kan du börja med att ge oss en överblick över vad det syftar på och vilka omständigheter som omger det?

Manuel Da Costa: Ja, absolut. McKinsey har nyligen gjort en del forskning där de tittade på skillnaden mellan goda och dåliga metoder inom produktledning, och i grunden handlar det om ledningens förväntningar på hur produktarbetet ska utföras. Och sedan vad som faktiskt händer på operativ nivå när produktchefer genomför arbetet – det finns en koppling som inte fungerar, och det är den vi har upptäckt. Jag gav detta namnet produkt–process-gapet, men i grunden är det gapet mellan förväntningar och verklighet.

Det finns många orsaker till att detta händer och vi kommer att gå igenom dem, men ytterst vill ledningen ha en bättre produkt, medan produktchefer och produktansvariga inte levererar det. Och det finns en mängd orsaker till varför det blir så.

Hannah Clark: Låt oss gå lite längre in på det. Du sa att det finns många faktorer som kan ligga bakom. Vilken är egentligen resan, eller ursprunget, till att det här gapet uppstår och hur hamnar vi där?

Manuel Da Costa: Absolut. Låt oss titta på vad produktteam förväntas göra i dag, nämligen validera varje produktbeslut de fattar. Experimentering har blivit det verktyg som produktteam i praktiken använder för att validera sina hypoteser och avgöra om de lanserar rätt produkt.

För många av de produktteam som har fått i uppgift att genomföra experiment har de inte haft erfarenheten eller kunskapen. Och även om de har kunskapen är den ofta på en ytlig nivå när det gäller hur man experimenterar. Resultatet blir att beslut fattas genom experimentering, men själva experimenteringen kan vara bristfällig. Den kanske inte är tillräckligt rigorös. Och det finns även ytterligare aspekter kring detta.

Vi talar om samarbete mellan team, medvetenhet om vad som ska göras och även hur man prioriterar effektivt. Det finns så många motstridiga prioriteringar inom produktområdet, särskilt kring vad teamen bör göra, och nu när experimentering blandas in handlar det om hur man prioriterar den backloggen effektivt för maximal effekt.

Det här är några av de symtom vi har sett på operativ nivå, där produktteam, som jag sa, ombeds att genomföra arbetet och dessutom integrera experimentering i sina arbetssätt, men inte får det stöd som krävs för att lyckas.

Hannah Clark: Vad saknas i den här ekvationen? Det låter som att det nästan finns en användarforskningskompetens som är underutvecklad hos produktchefer som placeras i den här situationen. Och det leder åtminstone till en dominoeffekt av bristfälliga resultat. Vad ser du som de viktigaste orsakerna till att produktcheferna är oförberedda?

Manuel Da Costa: Låt oss titta på var experimenteringen kommer in. I många organisationer genomfördes experimentering huvudsakligen av ett marknadsföringsteam eller ett CRO-team, alltså konverteringsoptimeringsteamet.

Kanske var det några få personer, kanske ett litet kompetenscentrum. Gradvis har de sedan fått i uppgift att föra vidare kompetensen till produktteamen så att dessa själva kan genomföra sina experiment. Den första utmaningen är just kunskapsbristen. Man kan se organisationer där de genomför utbildningsworkshoppar eller handledda sessioner där de visar hur man gör.

Men där tar det slut. Det är som om de har fått tillgång till vissa verktyg och en ytlig utbildning. Det finns inga resurser som hjälper dem att verkligen förstå om de förbättras eller inte. Därför går de efter siffrorna. De säger helt enkelt att de har genomfört ett visst antal experiment och ser det som resultatet, men ingen övervakar eller granskar om experimentet genomfördes korrekt, om det planerades korrekt och om det analyserades korrekt.

Den kompetensen tar ganska lång tid att utveckla. Tänk på den som en muskel. Det är inget man bara gör en gång och sedan behärskar. Det finns produktchefer som genomför bra experiment, men de kan vara alltför enkla. De kan genomföra komplexa experiment, men instrumenteringen kan vara felaktig. När de sedan lämnar över informationen till ledningen och säger: ”Det här anser vi bör göras härnäst”, bygger det på felaktig information – eller kan bygga på felaktig information – utan att de vet det, eftersom det saknas tillsyn.

Det leder mig till nästa punkt: tillsynen saknas. Ofta får dessa team ett stort förtroende och uppmanas att genomföra experimenten, varefter ledningen tror på det som rapporteras tillbaka. På grund av resursbristen ägnar ingen faktiskt tid åt att verifiera resultaten och se om de är korrekta.

Om resultaten beror på goda eller dåliga metoder är en faktor. Den andra faktorn är frånvaron av ledarskap på rätt nivå. När jag säger ledarskap menar jag inte produktansvarig. Jag menar produktchefer på vice presidentsnivå och produktdirektörer. Det är de som verkligen måste hålla teamen ansvariga.

Och inte bara hålla dem ansvariga, utan också ge dem utrymme att ägna tid åt att träna upp den här muskeln, lära sig att experimentera bättre, fatta bättre beslut och prioritera bättre. På grund av dessa två faktorer uppstår en klyfta mellan förväntningarna och verkligheten. Produktchefer och produktspecialister kämpar eftersom de inte har utrymme att sakta ner och få dessa saker på plats.

En del av ansvaret ligger därför hos ledningen, eftersom den måste ge teamen mandat men också den kapacitet som krävs för att bli bättre på detta.

Hannah Clark: Hur ser det ut i praktiken ur ett ledningsperspektiv? Vilka steg kan ledare ta för att förhindra att produkt–process-gapet uppstår?

Manuel Da Costa: Det första är att sätta rätt nyckeltal. Det viktigaste vi ser är när felaktiga incitament införs. Med felaktiga incitament menar jag till exempel att man säger att teamet måste lansera ett visst antal funktioner under kvartalet eller året och nå den siffran.

Då blir det en kvantitetsfråga, inte en kvalitetsfråga. Man kan lansera en komplex funktion eller flera enkla funktioner, så länge man når siffran. Därför måste man sätta rätt nyckeltal för teamen så att de får rätt incitament, i stället för att kunna göra vad som helst bara för att nå milstolpen och komma undan med det.

Det andra är att ge teamen och de personer som övervakar dem tillräcklig kapacitet för att coacha, följa upp och förbättra produktteamen så att de fattar bättre beslut över tid. Ingen börjar med att veta hur man experimenterar korrekt. Det tar tid, och det kan inte vara så att man bara genomför en utbildningsworkshop och sedan är det klart.

Teamen behöver coachning och mentorskap över tid. Det vi ser är att kapacitetsbristen uppstår eftersom de måste nå vissa siffror. Eftersom de saknar kapacitet förbättras de inte. Det blir en ond cirkel som fortsätter. Det börjar med att ledningen säger att organisationen vill förbättras och fatta bättre produktbeslut.

Hur fattar vi bättre produktbeslut? Genom att experimentera och validera våra antaganden. Det är det första steget. För att göra det måste vi ge produktteamen förutsättningar att formulera och pröva dessa antaganden. Vi ger dem tid, kapacitet och mandat, men också en trygghet i att få ha fel, eftersom experimentering i grunden innebär att man kan ha fel. Om man sätter nyckeltal utifrån kvantitet, eller kräver att experiment ska ha en viss framgångsgrad, kommer människor att manipulera systemet för att nå siffran.

Experimentering handlar om att vi har en idé om att något kanske fungerar, men vi vet inte förrän vi prövar det i verkligheten. När vi lanserar det får vi återkoppling från kunderna och marknaden som visar hur det faktiskt fungerar.

Därefter kan vi besluta om vi ska fortsätta på den vägen eller inte. Den tryggheten är mycket viktig, för om produktansvariga och produktchefer inte får den kommer de att välja det som känns säkrast för att nå sina nyckeltal. Då får man säkra produktbeslut, men aldrig innovativa produktbeslut.

Hannah Clark: Jag kan föreställa mig en situation där produkt–process-gapet går obemärkt förbi, där nyckeltalen nås, människor i allmänhet är nöjda och verksamheten håller sig flytande, men där något saknas. Vilka symtom visar att en organisation i det tysta lider av det här gapet, att det finns betydande förbättringsmöjligheter och att felaktiga beslut kan fattas på grund av bristfällig experimentering?

Manuel Da Costa: Om bristfällig experimentering pågår har vi redan sett att produktchefer och vice produktchefer säger att de faktiskt inte litar på experimentresultaten. Då börjar man fatta magkänslobaserade beslut. Människor fattar beslut utifrån magkänslan trots att det finns data, men eftersom de inte litar på datan avfärdar de den direkt.

Om ett företag är tryggt just nu – låt oss betona just nu – experimenterar det inte, innoverar inte och spelar säkert. Förr eller senare kommer marknadskrafterna att tvinga det att arbeta hårdare för att förbättras, eller avgöra företagets öde. Bristen på förtroende för experimentresultat och beslutsfattandet är därför något vi först måste förbättra.

En annan sak är att företag kan tala om att de är datadrivna, produktfokuserade och kundfokuserade, men det är bara modeord. Man ser sanningen i arbetssätten, inte i det de säger offentligt.

Man ser funktioner och produktuppdateringar som inte riktigt överensstämmer med vad kunderna vill ha. Det blir helt enkelt en funktionsfabrik. Man lanserar saker för sakens skull i stället för att faktiskt skapa värde för kunden eller verksamheten som helhet.

Hannah Clark: Har du några ramverk som du skulle rekommendera för att genomföra bättre experiment eller för att veta vilka praktiska åtgärder vi bör ta?

Det låter som att det här är ett problem där många faktorer bidrar till sammanbrottet som skapar den här klyftan. Vad är steg ett enligt dig om vi inser att detta fenomen förekommer i vår organisation?

Manuel Da Costa: Absolut. Jag tycker att det första steget är att standardisera. När produktteam får verktyg för att genomföra experiment ser vi ofta att två olika team i samma organisation börjar avvika från varandra i hur de genomför experiment, klassificerar data och samlar in data. Det första steget är därför att förstå hur processen bör se ut.

När man vet hur processen ska se ut standardiserar man den. När jag säger standardisera blir människor ofta upprörda eftersom de tror att de måste vara mycket rigida och att det inte finns utrymme för flexibilitet. Problemet med ett alltför flexibelt arbetssätt är å andra sidan att kaos uppstår över tid och att datan blir nästan oanvändbar för alla som tittar på den senare.

Att standardisera innebär att standardisera processen, dataklassificeringen och den terminologi som används, liksom arbetssätten för analys och vem som godkänner vad. Man kan införa saker som en RACI-modell: vem som är ansvarig, vem som har det yttersta ansvaret och vem som behöver kommuniceras med och informeras.

Det kan verka stelt, men i praktiken skapar det skyddsräcken för människor. Det spelar ingen roll om teamet förändras över tid, om nya personer börjar eller om någon lämnar teamet eller företaget. Arbetssättet finns inbyggt i varje experiment som genomförs och varje beslut som fattas utifrån det.

En annan sak är att tydligt koppla besluten till verksamhetens mål, i stället för att bara fatta beslut genom att skjuta brett och hoppas på det bästa. Besluten ska vara kopplade inte bara till nyckeltal utan även till verksamhetens mål och syften. När dessa två saker är på plats har man en mycket bättre grund att utgå från.

Det kommer att gå långsamt i början, eftersom människor behöver vänja sig vid att vara mer uppmärksamma på hur de prioriterar sin backlogg, hur de avgör vad de ska experimentera med, hur de lanserar experiment och sedan bedömer om det ska bli en fullständig funktion som går vidare eller om den ska avslutas. Dessa delar utgör grunden.

Därefter måste man säkerställa att det finns tydlig tillsyn. Med tydlig tillsyn menar jag att vem som helst kan titta tillbaka på ett team eller en person och analysera hur väl de presterar. Det handlar inte om att hitta fel, utan om att förstå var luckorna finns och hur man kan coacha dem bättre.

Det kan till exempel handla om att säga att teamet har lanserat fem experiment under kvartalet, men att vissa saknar en stark hypotes eller att fel mätvärden valdes vid utvärderingen. Här är hur ni kan förbättra er. Det är det enda sättet människor förbättras på: man ger dem återkoppling och följer upp dem, inte för att ge negativ feedback utan för att ge positiv återkoppling som de kan utvecklas utifrån.

Dessa två saker tillsammans kommer att förbättra organisationens grundnivå och bidra till att stänga gapet.

Hannah Clark: Det intressanta är att det verkligen låter som att det krävs emotionell intelligens på ledningsnivå för att vara effektiv när man leder på det här sättet. Mycket bygger på lednings- och produktteamets förmåga att ha en trygg relation där det finns psykologisk trygghet nog att göra misstag och genomföra experiment som inte ger det förväntade resultatet.

Vilka tips skulle du rekommendera för att bygga starkare relationer mellan team och särskilt över organisationsstrukturen? Hur blir vi bättre på att lita på varandra när vi arbetar nära tillsammans, särskilt i en ny process som denna?

Manuel Da Costa: Det är lättare sagt än gjort eftersom människor och egon är inblandade, och människor måste våga vara sårbara. Det är det svåraste. Men återigen handlar det om att ledningen skapar en psykologisk trygghet och även justerar språket något.

Vi säger inte att ett test lyckades eller misslyckades. Vi fokuserar främst på lärdomarna. Man kan ändra samtalet från vinster och förluster till att säga att vi genom att genomföra ett experiment validerade behovet av den här funktionen eller kundens behov, och att det är så vi har hjälpt företaget.

Det här är experimentets potential. Eller: genom detta ogiltigförklarade vi faktiskt antagandet. Vi såg inget behov av att bygga funktionen. På så sätt sparade vi utvecklingsteamet en viss kostnad, och det här är vad vi har lärt oss och nu tar vidare för att lära oss mer.

Det handlar verkligen om att ändra inställningen från att experimentera för sakens skull eller experimentera för att vinna, vilket är varför nyckeltalen och hur man utformar dem är så viktiga.

Produktchefer, produktspecialister och produktansvariga kan lyssna på detta och säga att de gärna skulle göra så, men inte kan eftersom deras nyckeltal ser annorlunda ut. Därför är det så viktigt att ledningen uppmärksammar detta. Om vi inte gör det får vi alla möjliga bieffekter: organisationer blir funktionsfabriker, och även om det kan verka som att saker tar lång tid och att vi får ut saker, är frågan egentligen: i vilken utsträckning?

Hannah Clark: Ja, det är en bra poäng.

Jag är också nyfiken. Medan vi talar om de praktiska delarna på ledningsnivå kommer nyckeltalen naturligtvis att variera mellan team, men även teamstorlekarna varierar. Hur övervakar vi effektivt ett produktteam när vi börjar skala upp, när nya medarbetare tillkommer med en annan kunskapsnivå eller intern kunskap än någon mer senior?

Hur standardiserar och säkerställer vi att vi ger rätt tillsynsnivå, särskilt när vi som ledare är betydligt färre än de teammedlemmar som står under vår vägledning?

Manuel Da Costa: I vår värld har vi utvecklat rollen som samordnare. Beroende på antalet team och antalet personer i dessa team skapar man en samordnarroll som övervakar ett mindre antal team eller ett visst antal personer. Den personen kan ansvara för introduktion, coachning och mentorskap och se till att allt inom deras område fortskrider som det ska. Därefter kan de rapportera till nästa ledningsnivå.

I stället för att en ledare övervakar alla vill man ha en person som ansvarar för ett team eller flera team. Den personens särskilda roll är introduktion, coachning och mentorskap, så att människorna under deras ansvar genomför bättre experiment och fattar rätt produktbeslut.

De ska arbeta inom de skyddsräcken som har satts upp i själva processen och strukturen. Det är mycket viktigt när man ser på hur organisationen är uppbyggd. En samordnare kan övervaka flera team, men återigen beror det på teamets storlek.

Hannah Clark: Jag håller verkligen med dig om konceptet med skyddsräcken. Jag tycker att det är en sådan sak som kan låta begränsande. Men i praktiken har jag märkt att tydliga skyddsräcken ofta minskar beslutströtthet och gör människors arbete mycket tydligare. Människor känner inte att de hela tiden måste upprepa och ändra sina processer samtidigt som de bygger produkterna. Därför tycker jag att det finns ett starkt argument för det.

Jag är dock nyfiken, eftersom det vi talar om nu också är behovet av att standardisera tillsynen. Det är lite mer abstrakt: hur standardiserar vi den process vi använder för att övervaka ett team, även om vi har ett mindre team under vårt ansvar?

Vilka rekommendationer har du för att standardisera tillsynen, särskilt om du som ledare inte nödvändigtvis har en mycket stark bakgrund inom experimentering?

Manuel Da Costa: Allt börjar med att skapa ett styrningsramverk. Om man tittar på vad det innebär handlar det om att skapa regler för hur ett experiment ska skapas.

När jag säger hur ett experiment skapas menar jag vilka centrala saker som måste samlas in när man skapar ett experiment. Vissa kan vara ganska grundläggande. Vissa kan vara obligatoriska, som en hypotes – en bra hypotes. Det är skillnad mellan en hypotes och en riktigt stark hypotes.

Det är en aspekt, men vilka andra detaljer samlar man in? Jag tänker på information som är användbar när experimentet skapas, exempelvis tekniska detaljer, målgruppen och liknande. Men även andra aspekter som är relevanta och viktiga för verksamheten. När vi skapar ett styrningsramverk säger vi att det finns vissa fält eller datapunkter som måste samlas in när någon i organisationen skapar ett experiment.

Det finns inga undantag från detta – det måste samlas in. Det är miniminivån. Sedan finns det andra valfria delar. Det är en aspekt som på ett vänligt sätt kan sägas vara tvingande. Men även här finns skyddsräcken som förhindrar att organisationen samlar på sig en hög av oanvändbar data, för det kan också hända.

Om man ger för stor flexibilitet får man variationer där olika team utvecklar egna tolkningar av vad ett experiment är. Därför har man ett styrningsramverk som anger att skapandet av ett experiment kräver att man samlar in verksamhetsrelevant och tekniskt relevant information.

Sedan kommer processen som följer. Ett experiment kan inte utformas, genomföras och analyseras utan att gå igenom vissa steg. Man skulle till exempel inte lansera en funktion utan att kvalitetssäkra den. Samma sak gäller ett experiment. Man skulle inte lansera ett experiment utan kvalitetssäkring. Styrningsramverket bör därför ange att ett experiment inte kan passera vissa stadier utan att exempelvis ha genomgått kvalitetssäkring.

Det är inte förhandlingsbart. Det måste gå igenom den processen. Det innebär att varje experiment följer en väg och inte kan avvika från den. Om det avviker kan man följa upp det och ta reda på varför. Här kommer konceptet med ett hälsokort, som vi har tagit fram, in.

Hälsokortet är en checklista med vissa punkter som ett experiment kan utvärderas utifrån. Skapades exempelvis en hypotes? Ja eller nej? Den andra aspekten är när den skapades. Skapades den när experimentet togs fram, eller senare när man försöker rättfärdiga experimentet?

Det händer också. Vi har sett ett fenomen som inte är ett ord vi har hittat på själva. Det kallas harking, alltså att formulera hypotesen efter att resultaten är kända. Det är som att säga att om man pressar data tillräckligt länge kommer den att berätta det man vill veta. Det är i stort sett vad som ibland händer när experiment inte riktigt lyckas.

De vinner inte. Men man kan ändra mätvärdena eller hypotesen. Och plötsligt har experimentet vunnit. Styrningsramverk och skyddsräcken är viktiga eftersom de förhindrar att detta händer. Jag säger inte att människor medvetet försöker göra så. Men det går tillbaka till att deras nyckeltal handlar om att nå ett visst antal produktfunktioner, genomföra ett visst antal experiment eller nå en viss framgångsgrad.

Då ändrar de allt för att nå siffran. Därför kan styrningsramverket och hälsokortet hålla reda på dessa saker. Följde experimentet den process vi satte upp? Gjordes några ändringar i den kritiska informationen om experimentet när det slutfördes?

Då kan vi börja följa upp. Hälsopoängen kan ge en bild av om experimentet genomfördes korrekt eller inte. Till slut kan man säga att man litar på experimentet, resultaten och besluten som fattades utifrån det – eller att man inte litar på experimentet och kan förklara varför. Men även då är det en möjlighet att coacha.

Det är en möjlighet att få organisationen att i slutändan fatta bättre produktbeslut och samtidigt genomföra bättre experiment för att nå dit.

Hannah Clark: Jag uppskattar verkligen de ramverk du har presenterat. Det här är mycket hjälpsamt.

Har du några framgångshistorier i åtanke om en organisation som kunde förändra sina resultat genom att eliminera produkt–process-gapet?

Manuel Da Costa: Jag kan inte nämna företagets namn, men vi gjorde precis detta med ett företag som gick från ett kompetenscentrum till team som både var produktteam och marknadsteam. Det var ett globalt e-handelsföretag med många marknadsteam och produktteam som nyligen hade introducerats till testning.

Det viktiga var att vi inte omedelbart introducerade alla produkt- och marknadsteam till experimentering. I stället skapade vi en SWOT-analys av varje team och bedömde deras kunskapsnivå inom experimentering. Den andra faktorn var hur engagerade och villiga de var att delta.

Sedan började vi introducera de team som fick höga poäng och använde dem gradvis som socialt bevis. När några team hade kommit igång och fungerade bra, vilket skedde efter ungefär tre månader, kallade vi det tremånaderssprintar. Varje sprint hade en plan för att coacha och introducera teamen tills de var självgående i slutet av tremånadersprogrammet.

Därefter använde vi dem som socialt bevis för att få med nästa grupp, samtidigt som vi skapade ett ömsesidigt stöd mellan teamen. Vi konsoliderade arbetssättet under en tvåårsperiod. Det var en ganska lång process. Det var inte något som skulle hända över en natt, särskilt inte i ett större företag.

Kulturförändring sker inte över en natt. Detta var en process vi genomförde. Efter två år hade vi produktteam som var betydligt mer kunniga i hur man genomför dessa experiment. Även när personalomsättningen kom, människor lämnade företaget och nya började, tog det mindre än en månad för en nyanställd att komma in i processen eftersom alla ramverk fanns på plats.

De hade systemen på plats och visste exakt hur de skulle göra. Allt var ordnat så att de knappt kunde göra fel. Så kan man uttrycka det, eftersom det var mycket enklare att följa arbetssätten än att försöka göra på sitt eget sätt.

Hannah Clark: Jag uppskattar verkligen exemplen du har delat med dig av, och det här har varit mycket informativt.

Stort tack för att du var med oss, Manuel. Var kan människor följa dig på nätet om de vill lära sig mer om ditt arbete och Effective Experiments?

Manuel Da Costa: Du hittar mig på LinkedIn. Jag är ganska aktiv där. Du kan också besöka EffectiveExperiments.com och läsa mer om vad vi gör. Jag publicerar också mycket innehåll på vår blogg. Följ mig gärna via dessa två kanaler.

Hannah Clark: Utmärkt. Stort tack.

Tack för att du lyssnade. För fler bra insikter, praktiska guider och verktygsrecensioner kan du prenumerera på vårt nyhetsbrev på theproductmanager.com/subscribe. Du kan höra fler samtal som detta genom att prenumerera på The CPO Club, oavsett var du lyssnar på poddar.