Så lyckas du i en funktionsfabrik som produktchef (med Aakash Gupta, mannen bakom Product Growth)

Läs transkriberingen:

Vi testar att transkribera våra poddar med hjälp av ett datorprogram. Ursäkta eventuella stavfel, eftersom boten inte är korrekt till 100 procent hela tiden.

Hannah Clark: Funktionsfabrik: substantiv. Definition: ett mjukvaruföretag som fokuserar på att ständigt bygga och lansera nya funktioner i stället för att bygga en produkt som användarna faktiskt vill ha. Använt i en mening: “Jag trodde att jag hade anställts för att leda produktteamet i en djärv, ny riktning, men i stället arbetar jag bara på i en funktionsfabrik.”

Säg mig: skulle din bild finnas bredvid den ordboksdefinitionen? Du och tusentals andra produktchefer, min vän. Så om det helt enkelt är så det fungerar, vad kan du göra åt saken?

Min gäst i dag är Aakash Gupta, som skriver det välkända nyhetsbrevet Product Growth. Innan Aakash började arbeta heltid med nyhetsbrevet tillbringade han de senaste tolv åren i seniora produktroller och ledande produktroller på företag som Epic Games, Affirm och Apollo. Det betyder att han har upplevt i stort sett alla nivåer av inflytande som en produktchef kan ha.

Och som du kan föreställa dig är Aakash mycket väl bekant med de omständigheter som skapar funktionsfabriker, och hans handlingsplan för att arbeta som produktchef i dessa organisationer är både extremt praktisk och uppfriskande realistisk. Det här är ett avsnitt som du kommer att vilja lyssna noga på hela vägen, så låt oss börja.

Välkommen tillbaka till podden The CPO Club.

Aakash, tack så mycket för att du tog dig tid att prata med oss i dag.

Aakash Gupta: Absolut. Det är roligt att vara här. Och tack för att ni bjöd in mig.

Hannah Clark: Nöjet är vårt. Kan du berätta lite om din yrkesbakgrund och hur du hamnade där du är i dag?

Aakash Gupta: När jag började arbeta med produktledning omkring 2008 tycker jag att disciplinen var mindre utvecklad. Jag tror att INSPIRED publicerades ungefär vid den tiden, och jag tror faktiskt att det hjälpte mycket. Före det fanns kanske Ben Horowitz text om en bra produktchef och en dålig produktchef. Men utöver det var området ännu inte riktigt professionaliserat. Det fanns faktiskt främst på företag och nystartade företag i Silicon Valley.

Jag introducerades till området eftersom grundarna på det nystartade företag där jag arbetade var hängivna följare av allt som Y Combinator gjorde. Många Y Combinator-företag hade produktchefer vid den tiden. Trots att företaget bara hade sex personer när jag började, började jag alltså som produktchef. Som tur var hade jag en bakgrund inom teknik, så jag hade kodat många appar och program och hade även experimenterat lite med Photoshop.

Så när jag började hoppade jag in och hjälpte till med precis allt. Jag utformade hela vår webbplats och designade och gjorde om stora delar av vår app, trots att mina designkunskaper var ganska begränsade. För webbplatsen hanterade jag dessutom vårt innehållshanteringssystem och all teknik bakom det. Jag hoppade alltså in på alla områden som produktchef i ett tidigt skede, samtidigt som jag försökte förstå vad produktledning var och lärde mig hur produktledning fungerade. Men det var verkligen en typisk startupmiljö.

Därefter började jag arbeta med mitt eget nystartade företag, Rap to Beats. Det innebar i princip att jag gjorde exakt samma sak, fast med ännu mer programmering. Jag byggde många fler versioner av appen. Så jag hade verkligen en bakgrund som byggare när jag kom in i produktledningen. Därifrån gick jag vidare till renodlad produktledning på ett företag som hette thredUP, som nu är börsnoterat.

Jag började där när företaget befann sig i serie C och slutade när det befann sig i serie E. Tillsammans byggde vi upp många av de tidiga tillväxtteamen där. Om du minns 2014 var Ubers hänvisningsprogram det stora samtalsämnet. Jag minns att när vi lanserade vårt hänvisningsprogram blev det en enorm tillväxtmotor. Man kunde göra enkla saker som det.

Det var inte ens optimerat. Jag började alltså lansera produkter och insåg att vi som produktchefer kunde förändra företagens tillväxtkurva i grunden. Det var då jag verkligen bestämde mig för att satsa på produktledning som yrke. Sedan dess har jag varit produktchef på platser som Google, Affirm och Epic Games och senast på Apollo.io, där jag var produktchef på vice vd-nivå. Nu arbetar jag heltid med nyhetsbrevet.

Hannah Clark: Fantastiskt. Och jag vet att så många verkligen uppskattar det.

I dag ska vi fokusera på funktionsfabriker och specifikt på hur produktchefer kan överleva i en organisation som fungerar som en funktionsfabrik. Det har nästan blivit ett skällsord i branschen nu.

Låt oss börja från början. Hur utvecklas organisationer till funktionsfabriker, och varför är det ett så vanligt resultat?

Aakash Gupta: Jag tror faktiskt att alla vägar leder till framtidsfabriken. Låt oss säga att du befinner dig i en miljö med klassiskt mandat. Under de senaste fyra eller fem åren har en av några saker hänt.

Antingen har grundaren, som i fallet Airbnb, återtagit kontrollen och sagt: okej, det här är några av de saker jag vill att vi bygger. Eller så kan produktledare ha tagit kontrollen genom många uppsägningar och omorganisationer. Det de ofta gör är att använda ständiga omorganisationer som ett sätt att placera människor i roller och få de arbetsprodukter och funktioner byggda som de själva vill ha.

Det som alltså i slutändan händer är att antingen vd:ar eller produktledare, på grund av pressen i den senaste tidens klimat, säger: vi kan inte bara ge människor mandat. Vi kan inte bara lämna över detta. Ibland ser jag produktchefer som är 26 år gamla och har fyra års arbetslivserfarenhet.

Vi kan inte bara överlåta produktbesluten för vår verksamhet på en miljard dollar till dem. Därför har det som hänt varit att även i klassiskt mandatstyrda miljöer, ända upp till Google och Netflix, bestämmer produktcheferna inte längre 100 procent av färdplanen.

Ofta finns det en process nedifrån och en process uppifrån som pågår parallellt och som är osynlig. I processen nedifrån tar produktchefen fram sina idéer och lämnar in dem i planeringen. Men när man tittar på vad som slutligen godkänns är mycket sådant som cheferna måste godkänna, som de måste övertygas om och som de ofta själva har kommit på.

Därför tror jag att många lägger på en yttre fernissa av mandatstyrning kring mål och nyckelresultat och kvartalsplanering, men slutresultatet blir ändå en funktionsfabrik. Till att börja med gäller det kanske bara en fjärdedel av företagen som verkligen har mandat, och sedan utvecklas de till funktionsfabriker.

För de andra 75 procenten av företagen skulle jag säga att ungefär 30 procent befinner sig i en omvandlingsfas. De företagen säger: vi förstår att vi behöver gå över till agilt arbete. Vi förstår att vi behöver ge produktcheferna mandat. Men när produktcheferna samarbetar med andra funktioner, som design, teknik, affärsverksamhet och försäljning, exempelvis inom bank eller sjukvård där mycket av den digitala omvandlingen sker, är dessa personer fortfarande vana vid att arbeta som i en funktionsfabrik, enligt vattenfallsmodellen.

Så även om produktorganisationen vill genomföra förändringarna tar det åratal. Jag pratade med Marty Cagan, och han sade att det tar tre år. Jag tror att det stämmer ganska väl. Det tar ungefär tre år. Därför finns det företag i den situationen. Det som händer är att produktcheferna hålls ansvariga för mätvärden, men samtidigt bestäms det åt dem vilka funktioner de ska bygga.

Det är en rörig mellanposition. Den sista kategorin är uppenbart vattenfallsstyrda, uppenbart funktionsfabriker, och många platser är helt nöjda med att arbeta så. Om du pratar med en genomsnittlig produktchef på Apple bestämmer cheferna många av produkt- och funktionsbesluten. Jony Ive och Steve Jobs fattade många av de viktiga besluten när Steve Jobs fortfarande var där.

Den modellen kan alltså fortfarande lyckas, och människor tänker: den fungerar inte. Marty sade att de bästa företagen alla ger mandat, men jag har upptäckt att alla vägar leder till framtidsfabriken.

Hannah Clark: Jag kan se hur det, om man följer tankegången, faktiskt blir logiskt.

Låt oss gå igenom några av stegen som du beskriver i blogginlägget du skrev om det här ämnet. Om du inte har läst bloggen är det väldigt intressant hur du har brutit ned frågan och tagit en något kontroversiell ståndpunkt kring hur man ska reagera på att vara produktchef i en funktionsfabrik. Innan vi går in på stegen, kan du berätta lite om var du står i frågan och hur du ser på samsynen med exempelvis Melissa Perry?

Aakash Gupta: Jag tycker att det finns idealister och realister. På den idealistiska sidan har vi personer som Marty Cagan, Teresa Torres och John Cutler, som jag alla tycker mycket om, beundrar och läser allt de skriver. Men jag tror att de anser att man som produktchef bör försöka omvandla organisationen om man befinner sig i en funktionsfabrik.

Det är i grunden det de förespråkar. Många av verktygen och insikterna som de så generöst delar gratis handlar om det. Så jag tycker mycket om och respekterar dem, men det är vad de tror på. Jag och Melissa Perry och andra liknande personer, exempelvis Clair Vaux och Powell Hearn, befinner oss lite mer på den realistiska sidan av skalan. Det innebär att jag inte tror att du som produktchef, om du inte har kanske åtta eller tio års erfarenhet som produktchef och dessutom är grupproduktchef eller har en högre titel, verkligen har den erfarenhet eller det inflytande som krävs för att effektivt omvandla hela organisationen.

I stället kan du kanske tänka på en annan strategi. Varför säger jag det? Jag har sett så många människor försöka leva efter den idealistiska modellen. Jag kanske låter som en upprepad skiva när jag säger det här, men jag älskar att sortera produktledningsforumet på Reddit efter de mest populära inläggen genom tiderna.

Jag tror att det fortfarande är så att åtta av tio av de inläggen handlar om att produktcheferna säger: jag hatar mitt jobb, mitt jobb är outhärdligt. Om man läser detaljerna handlar det om produktchefer i en funktionsfabrik. De skriver saker som: jag började med produktledning efter att ha läst INSPIRED och trodde att jag skulle kunna bestämma färdplanen, men jag är bara en ordermottagare åt vd:n.

Det här är ett oerhört vanligt scenario. Människor befinner sig i de 75 procent av företagen som uttryckligen är funktionsfabriker, och de är missnöjda med jobbet eftersom det faktiskt fungerar så. Om vi tänker på det tycker jag att mitt realistiska råd till nyhetsbrevets många läsare inom produktledning, för att undvika all förvirring, är: acceptera det. Ge upp kampen mot fabriken. Du vinner på att veta att du befinner dig i en fabrik. Då kan du säga: okej, som fabriksarbetare, vad behöver jag göra för att acceptera detta och gå vidare?

Hannah Clark: Jag tror att inställningen betyder väldigt mycket för hur bra vi klarar oss i alla svåra situationer. Men det behöver inte vara svårt.

Låt oss gå igenom stegen du tar upp i blogginlägget, med början i att ge upp kampen mot fabriken, som du redan har berört. När insåg du verkligen att det var ett nödvändigt steg i processen?

Aakash Gupta: Jag tror att det var efter misslyckade försök att omvandla organisationer. Jag har till exempel arbetat i olika typer av miljöer. Många produktchefer har exempelvis inte arbetat i en spelmiljö. Jag arbetade på Epic Games med Fortnite. Många tänker på funktionsfabriken som en plats där vd:n, produktchefen eller designchefen bestämmer. I ett spelföretag är det i stället ofta formgivarna som kommer på fantastiskt häftiga saker tillsammans med de kreativa teamen.

De tänker: det här kommer att bli fantastiskt. Fjortonåringarna kommer att tycka att det här är den coolaste upplevelsen någonsin. Sedan fyller de nästa säsongslansering med sådana upplevelser. Som produktchef är det uppenbart för mig att det finns lågt hängande frukter när det gäller prestanda, introduktion och uppdateringar. Om du någon gång har försökt uppdatera Fortnite vet du att det fortfarande finns förbättringar att göra, även om mycket har blivit bättre.

Jag uppdaterade det nyligen. Det var en fil på 42 gigabyte. Min dator behövde två timmar, och jag använder en Mac, vilket är fruktansvärt. Installationen tog dessutom ungefär 50 minuter. Vi talar alltså om extrem friktion, och företaget släpper sådana uppdateringar två gånger i veckan. Det innebär timmar av friktion två gånger i veckan. I butiken för intäktsgenerering finns dessutom lågt hängande frukter kring att skapa fler varianter för personer som spenderar 3 000 eller 4 000 dollar om året i butiken.

Men för att övertyga personer som brydde sig om vad som var häftigt kunde jag ha försökt säga: vi måste fokusera på resultat i stället för leveranser och häftiga funktioner. Jag trodde först att det kanske var klokt, men det föll helt för döva öron. Jag försökte faktiskt göra sådana förändringar. Sedan arbetade jag på Affirm, där planeringsinfrastrukturen var mycket centraliserad.

Jag tänkte: okej, jag är grupproduktchef och mitt team ska ha mer diffust formulerade problem i sin färdplan. Det fungerade inte alls under min första planeringscykel. Cheferna tittade på den och sade: har ni gjort något arbete? Alla andras färdplaner var mycket mer detaljerade, med fantastiska skisser av deras funktioner, och analysteamet hade räknat fram intäkts- och vinstpåverkan med sju signifikanta siffror.

Då såg man helt enkelt dålig ut. Jag har själv gjort sådana misstag, och nu har jag dessutom coachat många produktchefer. Jag har träffat många produktchefer som kommer till mig eftersom de har det lite svårt i karriären. De kan ha fått ett sämre resultat i en prestationsbedömning än de hoppats på.

När jag undersöker saken djupare gör vi ofta en 360-gradersbedömning. Då upptäcker jag att deras motsvarigheter inom design och teknik säger: ja, deras produktkravdokument var inte tillräckligt detaljerade. Jag märker att dessa produktchefer tror att de arbetar i en miljö med mandat. I verkligheten befinner de sig i en funktionsfabrik, och funktionsfabriken kräver ett fantastiskt och mycket detaljerat produktkravdokument.

De missar alltså dessa grundläggande principer och presterar sedan sämre. Allt detta handlar om att förbättra sin prestation. I min erfarenhet från olika miljöer har jag inte sett att man kan åstadkomma förändring omedelbart. Den enda plats där jag verkligen kunde göra det var när jag nådde direktörs- och vice vd-nivå.

När jag arbetade på thredUP och Affirm var min uppgift faktiskt att höja nivån på organisationernas arbetssätt. När man är där måste man därför arbeta mycket medvetet och stegvis. Det är bra att vi har definierat vad funktionsfabriken är, eftersom du då i princip kan säga: jag ska långsamt förändra varje del av funktionsfabriken, eftersom den är ett antimönster. Men min poäng som karriärråd är att om du inte befinner dig på en viss nivå bör du inte försöka åtgärda antimönstret.

Hannah Clark: Det leder oss till nästa steg, som är att anpassa sig till miljön. Det du skrev handlar om att fokusera på vad ditt verkliga jobb är och att faktiskt göra det. Kan du utveckla det steget och de delsteg som hör till?

Aakash Gupta: Något jag tycker är fascinerande är att när jag ser tillbaka på de arbetsprodukter jag skapade i mina olika jobb som produktchef, särskilt de som togs emot väl, var de helt olika. På Epic Games handlade det i slutändan om presentationer av häftiga funktioner.

Ofta satt jag till klockan två på natten med en teknisk designer och skapade en spelbar demonstration av funktionen med suddig grafik. Det var sådant som fungerade bra. Om jag i stället tittar på Affirm, där jag redan har beskrivit miljön, handlade det om att komma med en fantastisk färdplan för påverkan och storlek, med alla data i kalkylarken och modellerna för att beräkna påverkan. Det var i princip raka motsatser.

Du måste alltså utvärdera hur framgång inom produktledning ser ut i din miljö. Jag rekommenderar att du intervjuar de personer som har varit produktchefer längst på företaget. Det är ett bra sätt. Intervjua också produktchefer som nyligen har blivit befordrade. Det är två mycket bra saker att titta på.

Och håll dig inte bara på ytan i dessa relationer. Försök att äta lunch med personen, helst ansikte mot ansikte. Fråga kanske inte ut personen för djupt första gången. Försök först att skapa värde för personen. När ni har byggt en stark relation och personen hjälper dig som mentor kan ni börja prata mer.

Jag brukar ställa frågor som: skriver du ett produktkravdokument för varje funktion? Kan du dela ditt bästa produktkravdokument? Kan du dela ditt senaste befordringsunderlag? Kan du dela dina senaste anteckningar från ett enskilt samtal med din chef? Det är mycket konkreta frågor, men du kan inte ställa dem till vem som helst om personen inte är din vän.

Jag säger därför: bli vän med personen först. Gör personen till din mentor också, kanske. Jag rekommenderar dock inte att du uttryckligen ber personen att bli din mentor. Många vill se att deras produktchefer och produktledare har en egen tyngdpunkt. De kommer annars kanske att tänka: det här är en undersökande person som verkligen bryr sig om att lyckas.

Det du bör göra är att se på dessa samtal som din egen produkt. När du börjar på ett jobb ska du intervjua kunder, icke-kunder, konkurrenter och andra personer på företaget. Ha sedan ett direkt enskilt samtal med din tekniska ledare, teknikchef, designer, användarforskare och analytiker och förmodligen även med din chef och chefens chef, där ni tydligt definierar roller och ansvar.

Var mycket tydlig. Fråga designern: vad tycker du om att produktchefer gör skisser och trådmodeller? De flesta designers säger kanske att de inte är särskilt intresserade. Vissa kanske säger att det går bra, så länge det inte görs i Figma. Du måste känna till sådana nyanser. Förstå hur du ska arbeta med just dina intressenter.

Ett misstag jag har sett hos personer som gör dessa intervjuer är att de antar att deras jobb som produktchef är likadant som jobbet för en annan produktchef i ett annat team. Men designern, ingenjören och analytikern som du arbetar med har sina egna förväntningar. Alla vill klättra på berget mot produktledning och nå vice vd-nivå.

Men just nu ska du fokusera på steget framför dig, på människorna nära dig och på att skapa ett slags överenskommelse. När du väl har den överenskommelsen kan du börja testa den och se vad som tas emot väl och vad som inte gör det. Teknikchefen kanske inte vet att ingenjörerna i teamet verkligen tycker om att bjudas in till samtal med kunder. Det lär du dig bara genom praktiken.

Var därför mycket uppmärksam på din lilla grupp. Det här är grundläggande karriärråd, men anledningen till att jag tar upp det här är att allt handlar om att förstå vad ditt jobb som produktchef faktiskt är. Jag tror inte att något jobb som produktchef är det andra likt.

Hannah Clark: Det låter som att man i alla arbetsmiljöer formar en mikrokultur med de människor man arbetar närmast. Därför är det viktigt att förstå nyanserna i den kulturen, vilka språk alla talar och att se till att förväntningarna på varandra är samordnade. Jag uppskattar verkligen det.

Det knyter också an till att du nämnde enskilda samtal med personer som har varit framgångsrika i rollen under längre tid.

Nästa steg i din utveckling är alltså att skapa en väg till befordran. Dessa personer är verkligen viktiga för det steget. Kan du berätta lite om strategin för att skapa en sådan karriärkarta för dig själv?

Aakash Gupta: Om man tänker på framtidsfabriken finns det vanligtvis en mycket konsekvent uppsättning kriterier som du måste uppfylla. Kriterierna är ofta oskrivna och outtalade och kan misstolkas av din egen chef. Många lutar sig därför mot sin chef. Jag har haft personer i mitt team som varit ganska pådrivande i våra enskilda samtal om befordran och liknande. Men det de inte förstod, och som jag behövde coacha dem i, var att jag inte är den enda som fattar beslutet om deras befordran.

Om vi tar Affirm som exempel skriver jag ett underlag åt dig som jag lämnar till en befordringskommitté. Den kommittén består av alla produktledare på samma nivå som jag eller högre. Alla dessa personer brukar åtminstone bidra med något i diskussionen. Efter att du har övertygat mig måste du alltså i praktiken få var och en av produktledarna på Affirm på min nivå eller högre att ha något positivt att säga om dig.

Du måste arbeta med dem, och det är det som faktiskt har fungerat på Affirm. Det handlar verkligen om att förstå det outtalade. Jag arbetade med några andra produktchefer på Affirm som hade svårt att bli befordrade. En av dem hade varit senior produktchef i ungefär tre år och hade gjort mycket bra arbete.

Jag började ha enskilda samtal med henne, trots att hon inte tillhörde mitt team, och hon blev befordrad i nästa omgång. Det här var rådet jag gav henne: jag deltog i din senaste befordringskommitté, och det var bara din chef som talade för dig. Hennes chef hade inte gett henne det rådet.

Du kan alltså inte alltid förlita dig på din egen chef. Du måste bygga relationer med andra chefer som får människor befordrade. Hitta dessa personer och skapa relationer med dem. Återigen skulle jag säga att du ska vara vän först och kanske samarbeta med dem i något arbete först, så att de kan se att du är bra.

Fråga dem sedan: hur ser din erfarenhet av befordringskommittéer ut? För mig har de bästa insikterna återigen kommit genom personliga samtal över en öl efter jobbet. Då kan man verkligen förstå vad som händer. Vissa tar ett strikt åtta-till-fem-perspektiv på arbetet.

Jag tycker att det är okej, men jag skulle faktiskt säga att du ska dra av tiden mellan fyra och fem på torsdagar och fredagar och i stället använda klockan åtta till nio på kvällen. Det kommer att vara mycket effektivare för de här samtalen. Använd den tiden till att förstå hur människor blir befordrade.

Många har frågat mig: hur blev du vice vd så snabbt? Det grundläggande svaret är att jag förstod befordringsvägarna på olika företag. På nästan varje företag jag började på blev jag befordrad inom ett eller två år. Jag fick fler personer i mitt team och ett större ansvarsområde. Det berodde på att jag fokuserade helt på den här befordringsvägen.

När jag frågade mina vänner om de hade pratat med någon om det eller vad de visste om saken visste många inte ens att det fanns en befordringskommitté på Affirm. Jag har träffat många sådana personer. Jag tänkte: det finns verkligen en kunskapslucka här. Att fylla den kunskapsluckan är alltså steg ett. Steg två är att tänka på vilka dina unika styrkor är.

Som produktchef kommer alla att tappa bollar någonstans. Din återkoppling om design kanske är åtta av tio. Din förmåga att hantera besvärliga intressenter kanske är sju av tio. Oavsett vad det är ska du luta dig mot dina styrkor. För mig var skrivande en uppenbar styrka.

Luta dig sedan verkligen mot den. Hur kan du skapa en veckouppdatering? Hur kan du sprida en fantastisk produktstrategi till fler produktteam än du normalt skulle göra? På så sätt använder du dina styrkor inom de unika befordringskriterierna. Jag brukade dela mitt skrivande och säga: här är en del av min strategi för betalningsgrunderna som påverkar produktteamet för betalningar.

Innan vi slutför vår färdplan vill jag därför dela en skärmbild av detta med er. Det kunde intressera dem tillräckligt för att de skulle läsa resten av dokumentet och säga: oj, han gör ett bra produktarbete. Det handlar om att använda dina styrkor mot dessa kriterier.

Hannah Clark: Det här är så klokt och så konkret. Jag uppskattar verkligen det konkreta angreppssättet.

Nästa steg är att höja nivån på isolerade arbetssätt. När du talar om isolerade arbetssätt i det här sammanhanget, vad syftar steget på och vilka konkreta exempel finns det på hur man kan utveckla dessa färdigheter?

Aakash Gupta: Jag nämnde att detta särskilt på grupproduktchefsnivå och högre bör göras på organisationsnivå.

Du bör alltså prova det med vissa team och visa att det fungerar. Om du befinner dig under grupproduktchefsnivå tycker jag att du ska prova det inom ditt eget team. När du i de enskilda samtalen har skapat en överenskommelse med dina design-, teknik- och analyskollegor och visat att du kan lyckas inom ramen för deras förväntningar är det dags att säga: låt oss höja nivån.

Du bör också be om deras återkoppling och ändra vissa saker utifrån vad de säger. Ordningen nedan är den ordning jag har experimenterat mycket med sedan jag började coacha människor, och det här är den mest effektiva ordningen för att flytta sig framåt.

Nummer ett är sammanfattningar av funktionsresultat. Jag tycker att de är mycket ofarliga i en funktionsfabrik eller liknande miljö. Vi har lanserat en funktion som kom från vd:n Brian Chesky, men han vill ändå veta vad som hände och varför. I funktionsfabriker märker jag att chefer faktiskt bryr sig mycket om varför något hände.

Det produktchefer ofta rapporterar är: A överträffade B, så jag fortsätter med A. Det är inte särskilt imponerande. A överträffade B eftersom … Och plötsligt påverkar du vad som händer härnäst. Även om det är en funktionsfabrik och de kanske inte lyssnar på vad som ska hända sedan följer det ändå av din berättelse.

Låt mig ge ett konkret exempel. Om du arbetar på Airbnb och just har lanserat totalpris eftersom Brian Chesky sade åt dig att göra det, vill du återkomma till honom med vad som hände och varför. Vi vet att konverteringsgraden för det som människor köper kommer att sjunka, men frågan är hur mycket. Vi vet att NPS kommer att öka eftersom människor inte längre kommer att överraskas av priserna.

Vi tror faktiskt att konverteringsgraden kommer att öka när människor har lagt till något i varukorgen och slutför sin bokning. Vi vet att konverteringsgraden högst upp i tratten på kartan kommer att sjunka och att konverteringsgraden på köpsidan kommer att öka. Vi vet inte hur den totala konverteringsgraden kommer att påverkas.

Brian kommer verkligen att bry sig om detta. När uppgifterna kommer tillbaka är de överraskande. Konverteringsgraden sjönk bara med två procent på kartsidan men ökade med sex procent på köpsidan. Den totala konverteringsgraden ökade alltså med fyra procent. Hans briljanta idé var uppenbarligen briljant.

Vi ser en ökning av konverteringsgraden med fyra procent. Varför hände det? Du behöver gå vidare. Intervjua några fler personer, observera dem och prata med din användarforskare. Du kanske upptäcker att människor tidigare inte litade på kartpriserna, exempelvis 357 dollar per natt. De litade aldrig riktigt på dem, och därför löste vi ett förtroendeproblem.

Då kan du återvända till Brian och säga: anledningen till att totalpriset överträffade förväntningarna när det gäller konverteringsgraden, och här är en intressant insikt, är att människor hade mycket lågt förtroende för vårt nattpris.

Då kan han säga: var har människor annars lågt förtroende för oss? Kanske har de lågt förtroende för vissa av våra omdömen eller för några av våra Airbnb Plus-boenden. Sedan kan du skapa en färdplan utifrån det. Jag tog upp det här långa exemplet för att förklara att sammanfattningar av funktionsresultat är mycket ofarliga och hjälper dig in på den första vägen.

Den andra intressanta saken är att beräkna påverkan. Produktchefer sitter ofta fast i att vara ansvariga för resultat, samtidigt som de får leveranser att bygga. I den världen tycker jag att det är spännande och effektivt att, när du får en leverans, bygga det starkaste möjliga argumentet med så mycket data som möjligt för hur funktionen kommer att prestera.

Vd:n på thredUP trodde till exempel att en ökning av hänvisningsprogrammet från 10/10 till 30/30 plötsligt skulle kunna öka våra intäkter med fem procent nästa månad. Jag använde de mest generösa antagandena, det högsta antalet delningar och de mest generösa nivåerna av godkända hänvisningar från våra bästa kampanjer. När jag lade ihop allt blev det uppenbart att den högsta möjliga ökningen av nästa månads intäkter var ungefär 0,1 procent.

Då blev det tydligt för honom att funktionen inte skulle uppnå målet han ville nå. Att bygga en ekonomisk modell för påverkan är alltså nummer två.

Nummer tre är att människor vanligtvis sätter vagnen framför hästen. De vill börja med upptäckt. Jag säger att upptäckt är nummer tre. Du har alltså börjat skriva sammanfattningar av funktionsresultat och börjat beräkna påverkan innan funktionerna byggs.

När du får en leverans säger du: tack för trådmodellen, herr vd eller herr vice vd. Nu ska vi göra en ordentlig upptäckt och ta med dig genom processen. Jag ska visa några av videorna, kanske med hjälp av ett nytt program som Dovetail, där jag på 30 sekunder kan lyfta fram problemen med detta.

Därefter kommer den nya designen. Vissa har den delen på plats. Nästa steg är att utvidga det till upptäckt av problem. Problemet som du försökte lösa med den här designen var kanske inte det verkliga problemet. Vi tror faktiskt att det finns en helt annan del av produkten där problemet kan lösas. Då går du från upptäckt av lösningar till upptäckt av problem. Det är 3A och 3B.

Nummer fyra är att gå vidare till mål och nyckelresultat. Här kommer vi verkligen in på grupproduktchefsområdet. Som huvudproduktchef rekommenderar jag dig att införa mål och nyckelresultat om resten av företaget gör det? Förmodligen inte. Men som grupproduktchef tror jag att mål och nyckelresultat är mycket effektiva när teamen väl arbetar med upptäckt.

Många börjar med mål och nyckelresultat som steg två, före framtida resultatsammanfattningar och beräkningar av påverkan. Jag upptäcker att deras mål och nyckelresultat då bara är nonsens. De missar i allmänhet alla sina mål och nyckelresultat. Jag skulle säga att detta gäller ungefär 90 procent av företagen.

Det är därför jag har den här mycket medvetna ordningen. Därefter kommer målhierarkier som hjälper dig att koppla mål och nyckelresultat till problem och lösningar. Till sist kommer produktstrategier. Det är roligt eftersom alla tror att produktledning är produktstrategi, men jag tycker inte att det är så förrän du faktiskt har kontroll över hela trädet av mål, problem och lösningar och kan skriva en produktstrategi.

Fram till dess skriver vd:n i praktiken din produktstrategi. När du har fått fullt mandat kan du lägga till produktstrategi.

Hannah Clark: Nästa steg är förstås att bygga din koalition. Vi har redan pratat lite om att skapa nära relationer med design- och teknikresurser. Jag undrar om du har en berättelse om hur detta har fungerat för dig i verkligheten?

Aakash Gupta: Låt oss gå tillbaka till Epic Games. Vi talade lite om den situationen. Relationer stod faktiskt i centrum för allt inflytande jag hade där. Något jag verkligen ville göra var att arbeta med Fortnites prestanda.

Fortnite är ett spel som kräver mycket skicklighet. Människor spelar omkring 2 000 timmar om året. Det är som ett heltidsjobb. Människor lägger enormt mycket tid på spelet. Anledningen är att man får ut mer av spelet ju fler timmar man lägger ned. Det finns personer som tävlar på den nivån och det finns tekniker att lära sig.

Problemet är att din färdighetsnivå begränsas om du har hög fördröjning eller mycket dålig bildfrekvens. I uppgifterna såg jag att personer med dålig prestanda på grund av en dålig dator eller dålig internetanslutning tenderade att sluta efter 1 000 till 2 000 timmar, medan personer med mycket bra prestanda kunde stanna i 12 000 eller 14 000 timmar.

Det finns fortfarande människor som spelar Fortnite i dag. Spelet släpptes för länge sedan. Det här var min viktiga insikt, men jag kunde inte bara börja med den och säga att vi därför skulle prioritera prestanda, som jag kanske hade gjort på Google. I stället behövde jag påverka viktiga designers och ingenjörer.

Jag behövde förstå att det fanns en person som hette Jason. Han hade skapat Call of Duty och ledde nu Fortnite. I slutändan fattade han alla beslut om vad som faktiskt hände i Fortnite. Han respekterade verkligen åsikterna hos de hårdast arbetande ingenjörerna och formgivarna, de som arbetade omkring 120 timmar i veckan.

De bara levererade allt. Inom spel är det tyvärr verkligheten. Det finns personer som arbetar lika mycket som inom investment banking. Han respekterade alla dessa personer, med rätta. Jag bestämde mig därför för att det var dessa personer jag behövde få med i min koalition.

Eftersom de arbetade så hårt hade de ingen tid att se hur allt de gjorde presterade. Det var min öppning. Som jag nämnde är resultatsammanfattningar din väg in. Jag började visa dem: ni lanserade Fortnite kapitel 2, säsong 4, uppdatering 6.4. Det här är arbetet som de är mitt uppe i. Ingen berättar för dem hur uppdatering 6.4 presterade, än mindre hur säsong 2, kapitel 4 presterade.

Jag kom därför med uppgifter som visade att uppdatering 6.4 gjorde detta, detta och detta med spelet. Användningen av prickskyttegevär ökade med åtta procent. Antalet dödade minskade med sex procent. Spelare med låg rank besegrade spelare med hög rank i en omfattning som aldrig tidigare hade setts i spelet.

De blev entusiastiska över sitt hårda arbete och började bry sig om vad jag hade att säga. Jag lade till lite prestandamagi ovanpå allt. Spelare med en fördröjning på över 200 millisekunder slutade spela i högre takt än någonsin tidigare. Små saker som att lägga till gevär, bollar och bilar i spelet innebar att personer med en ping på över 100 millisekunder förlorade sin rank i aldrig tidigare skådad takt.

Sådana insikter hjälpte dem att på ett avslappnat sätt börja arbeta in prestanda i spelet. De började förstå hur mycket prestandan påverkade spelet, och vi gjorde stora förbättringar av prestandan. Det är ett exempel på hur jag strategiskt tänkte kring vilka som borde och kunde ingå i min koalition. Jag byggde bakifrån för att skapa relationen och inflytandet.

Hannah Clark: Det är klokt på så många nivåer. Du bygger bra relationer, människor litar på dig och du blir inflytelserik nästan passivt. Lysande.

Innan vi avslutar vill jag ta upp några vanliga misstag som du har lagt märke till att produktchefer gör i funktionsfabriksmiljöer. Ett av dem är uppenbarligen att inte inse att man är dömd att arbeta i en funktionsfabrik. Vilka andra misstag kan vi ta upp för dem som lyssnar?

Aakash Gupta: Det finns kanske sex stycken som jag vill nämna. Det första är att de bara jagar leveransmått. De har i princip hört mitt råd och gett upp kampen mot fabriken. Fabriken bryr sig om hastigheten i Jiras berättelsepoäng. Fabriken bryr sig om hur många stora funktioner jag släpper i tid. Fabriken bryr sig om hur få gånger jag flyttar fram ett förfallodatum för en funktion.

Det är det enda jag optimerar för. Jag tycker fortfarande att det är ett misstag. Du måste fortfarande titta på resultaten av alla dina funktioner. Jag vill inte att uppmaningen att acceptera fabriken ska innebära att du slutar göra ett bra produktarbete. Ja, fabriken kan be dig bygga en fruktansvärt dålig funktion utan påverkan, men du måste ändå använda ditt produktomdöme innan du bygger den.

Det gör två saker. För det första fattar du rätt beslut om resursfördelning där du kan. För det andra bygger du upp färdigheten att göra bra produktarbete. Jag märker att många som börjar i en funktionsfabrik låter sina färdigheter förtvina.

Jag kan säga: Ben började i funktionsfabriken på J. P. Morgan i fyra år, och jag tycker att han är en sämre produktchef än när jag kände honom på Google. Sådana saker har faktiskt hänt. Det handlar om att hålla sin färdighetsutveckling på en hög nivå och fortfarande förstå vilken mätbar påverkan och användarpåverkan allt du lanserar har.

Det andra misstaget som produktchefer i funktionsfabriker gör är att de, eftersom de har anammat jakten på stora funktioner och vd:n är entusiastisk, bara fortsätter att leverera. De försummar det tekniska skuldberget. Utvecklarupplevelsen blir sämre och byggtiden kanske är tre timmar. Det tar en hel dag att göra en enkel ändring, men man fortsätter att säga att den viktiga Fortnite-säsong 16 närmar sig och måste lanseras.

Jag tycker att det är mycket vanligt. Jag har sett det hos de flesta produktchefer i funktionsfabriker. Jag brukar tänka på oavsiktlig och avsiktlig teknisk skuld. Den oavsiktliga tekniska skulden kommer från användarupplevelsen och den vill jag minimera. Jag vill avsätta tid för att hantera den.

Sedan finns den avsiktliga tekniska skulden, när du jagar den stora funktionen. Vi gjorde vissa kompromisser, och så länge du fattar dem medvetet är det okej. Om du investerar i funktionen och den går från noll till ett till hundra kan du senare gå tillbaka och rätta till problemen.

Det tredje misstaget är att ignorera användaråterkoppling. Jag nämnde att det kan vara ett stort steg att bara visa sin trådmodell och ändra den. Jag tycker inte att det borde vara ett stort steg för någon produktchef. När jag frågar någon: ni lanserade den här stora funktionen, hur många användare visade ni de slutliga designerna för? Ungefär hälften av produktcheferna säger att de inte visade den för några användare. De behövde bara skynda sig att lansera den.

Jag tycker att det är ett enormt misstag. Även om du sitter fast i funktionsfabriken står din karriär på spel genom allt ditt team lanserar. Som produktchef är det som ditt team lanserar ditt cv, oavsett om du får sparken eller blir befordrad. Se därför till att den dåliga idén blir den bästa versionen den kan vara.

Det fjärde misstaget är att låta rädslan att missa något styra färdplanen. HubSpot lanserade ett CRM, så vi behöver ett CRM. Typefully har publicering på LinkedIn, så vårt Twitter-verktyg Tweet Hunter behöver publicering på LinkedIn. Vi är rädda att de tar några av våra kunder. Kanske förlorade vi vår största kund, och plötsligt vill vi bygga allt som kunde ha räddat den kunden.

Jag tycker att det är ett stort misstag. Försök i stället visa cheferna omfattningen av en funktion. Det är det jag menar med att beräkna påverkan. När du har skrivit sammanfattningar av funktionsresultat handlar det om att beräkna påverkan och fråga hur stor den möjliga målgruppen är.

Ni vill bygga en helt ny produkt i vår produktserie. Vår senaste nya produkt används av 0,2 procent av användarna. Tror ni verkligen att vi måste investera i ännu en produkt som 0,2 procent av våra användare kommer att använda? När du ser att rädslan att missa något styr den som leder funktionsfabriken är det en tydlig varningssignal.

Det är här jag kanske behöver avvika från funktionsfabriken. Det femte misstaget är att köra slut på teamet. Det är mycket vanligt även i miljöer där produktchefer har mandat eller där man bara försöker driva hårt. Även om det är viktigt att leverera snabbt tenderar ett välmotiverat och friskt team att skapa de bästa resultaten.

Du kanske kan få tio procents tillväxt med ett utbränt team, men om du vill uppnå en tillväxt på 50 procent måste teamet fungera på topp. Som produktchef säger jag därför: förespråka bättre verktyg. Förespråka en budget för lärande och utveckling. Förespråka en välplanerad teambuildingdag.

Det här är min favoritmetod. Jag brukar organisera sådant eller förespråka det. Jag kan fråga min chef: vi har precis lanserat en stor funktion, eller en stor funktion ska snart lanseras. Jag tror att det vore fantastiskt om produktteamet kunde samlas och fira det.

Sådana små saker gör stor skillnad i alla funktionsfabriksmiljöer, eftersom det inte bara är produktchefen som ofta mår dåligt. Även designern och ingenjörerna är frustrerade.

Det sjätte misstaget är att tappa bort helheten. Vi får vadet, vi får vadet, vi får vadet. Vi glömmer ofta varför. Jag har talat om varför i samband med mätvärden och användarproblem.

Glöm inte heller produktstrategin. Även om jag placerade produktstrategin som det sista steget tycker jag att du, som en del av att utveckla dina färdigheter, bör utveckla din förmåga inom produktstrategi. Produktchefens roll har krympt kraftigt under de senaste tre eller fyra åren.

Det finns helt enkelt färre jobb som produktchef än tidigare, samtidigt som produktdesign och produktteknik fortsätter att växa. De växer på bekostnad av produktledningen. Om produktchefer ska lyckas i en miljö där antalet jobb minskar måste vi försöka påverka produktstrategin.

Även om du accepterar funktionsfabriken och arbetar steg för steg med isolerade arbetssätt kommer det i varje fabrik att finnas 10 till 15 procent av färdplanen som du kan påverka. Det kommer att finnas 10 till 15 procent av sprinten där designern och teknikchefen vill att du bidrar.

Du är fortfarande en del av teamet, även om det är en fabrik och vi nu har accepterat det som fabriken bryr sig om. Se till att de funktioner vi lanserar är strategiskt mycket viktiga. En av de bästa produktcheferna i en funktionsfabrik arbetar fortfarande på Epic Games, och en annan arbetar fortfarande på Affirm. Varje funktion de lanserar förändrar företagets utveckling.

De lanserar inte sina egna funktioner särskilt ofta eftersom de sitter fast i den här miljön. Men när de gör det förändrar det spelplanen. På Affirm lanserade en av dem maskininlärning för att organisera vilka lån man bör återbetala. Det var en avancerad backendtillämpning med maskininlärning, men den förbättrade återbetalningsgraden med ungefär 15 procent. Det gav Affirm ett ledande försprång i branschen.

Det är sådana stora effekter man bör motiveras av. Om du sitter fast i funktionsfabriken efter att ha lyssnat på Aakash och Hannah i 45 minuter om funktionsfabriken, försök att komma på geniala funktionsidéer själv och få in dem där du kan.

Hannah Clark: Där kom verkligen slutklämmen. Aakash, tack så mycket för att du tog dig tid att prata med oss. För de fem personer som lyssnar och ännu inte följer dig, var kan de följa dig på nätet?

Aakash Gupta: Helst genom nyhetsbrevet. Jag finns på Substack. Jag vet att vissa inte tycker om popup-fönstret som ber om deras e-postadress.

Du kan bara trycka på ignorera och fortsätta läsa om du vill. I dag pratar jag med fler än tio personer i genomsnitt i varje text. I min senaste text hade jag en gästskribent. Vi pratade med tio personer var och intervjuade dem. Vi fick faktiskt verkliga insikter.

Det är alltså inte den typ av produktinnehåll som du kanske ser från mig på LinkedIn eller X och tänker att det bara är vanligt produktinnehåll som alla andra skriver. Det här är forskningsstudier från verkliga människor. För jobbsökande inom produktledning pratade vi med produktledare som nyligen hade fått roller som vice vd eller direktör. Vi pratade med rekryterare som faktiskt tillsätter sådana roller i branschen.

Det jag försöker göra är att bidra med verkliga data och verkliga insikter. Om du är intresserad av det är det detta jag arbetar med och där du kan hitta mig.

Hannah Clark: Fantastiskt. Vi ses där. Och tack så mycket för att du kom hit.

Aakash Gupta: Tack, jag uppskattar det.

Hannah Clark: Tack för att du lyssnade. För fler fantastiska insikter, instruktionsguider 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 brukar lyssna på poddar.