Slik lykkes du i en funksjonsfabrikk som produktsjef (med Aakash Gupta, mannen bak Product Growth)

Les transkripsjonen:

Vi prøver ut transkripsjon av podkastene våre ved hjelp av et program. Tilgi eventuelle skrivefeil, siden roboten ikke er korrekt 100 % av tiden.

Hannah Clark: Funksjonsfabrikk: substantiv. Definisjon: et programvareselskap som fokuserer på å bygge og lansere nye funksjoner kontinuerlig, i stedet for å utvikle et produkt brukerne faktisk ønsker. Brukt i en setning: «Jeg trodde jeg ble ansatt for å lede produktteamet i en modig, ny retning, men i stedet jobber jeg bare videre i en funksjonsfabrikk.»

Si meg: Ville bildet ditt vært ved siden av dette oppslaget i ordboken? Du og tusenvis av andre produktsjefer, min venn. Så hvis det bare er slik det er, hva kan du gjøre med det?

Min gjest i dag er Aakash Gupta, som skriver det ikoniske Product Growth-nyhetsbrevet. Før han begynte å arbeide med nyhetsbrevet på heltid, hadde Aakash de siste tolv årene hatt senior- og lederroller innen produkt i selskaper som Epic Games, Affirm og Apollo. Det betyr at han har erfart omtrent alle nivåer av innflytelse en produktsjef kan ha.

Og som du kan forestille deg, kjenner Aakash altfor godt til omstendighetene som skaper funksjonsfabrikker. Strategien hans for å fungere som produktsjef i slike organisasjoner er både svært praktisk og forfriskende realistisk. Dette er en episode du kommer til å ønske å følge nøye helt til slutten, så la oss sette i gang.

Velkommen tilbake til The CPO Club-podkasten.

Aakash, tusen takk for at du tok deg tid til å snakke med oss i dag.

Aakash Gupta: Absolutt. Hyggelig å være her. Og takk for invitasjonen.

Hannah Clark: Bare hyggelig. Kan du fortelle oss litt om karrierebakgrunnen din og hvordan du kom dit du er i dag?

Aakash Gupta: Ja. Da jeg begynte med produktledelse rundt 2008, følte jeg at fagområdet ikke var like utviklet. Jeg tror INSPIRED ble utgitt omtrent på den tiden, og jeg tror faktisk det hjalp mye. Før det fantes det kanskje en artikkel av Ben Horowitz, «god produktsjef, dårlig produktsjef». Men utover det var fagfeltet ikke egentlig profesjonalisert. Det eksisterte hovedsakelig i selskaper og oppstartsbedrifter i Silicon Valley.

Jeg ble introdusert for det fordi gründerne i oppstartsbedriften jeg jobbet i, fulgte alt Y Combinator gjorde svært tett. Mange Y Combinator-selskaper hadde produktsjefer på den tiden. Selv om oppstartsbedriften bare hadde seks ansatte da jeg begynte, startet jeg derfor som produktsjef. Heldigvis hadde jeg bakgrunn fra ingeniørfag, så jeg hadde kodet mange apper, programmert og også lekt litt med Photoshop.

Så jeg hoppet inn og gjorde absolutt alt da jeg begynte. Jeg utformet hele nettstedet vårt, og jeg designet og redesignet store deler av appen vår, selv om designferdighetene mine var ganske begrensede. For nettstedet vårt administrerte jeg også innholdsstyringssystemet og all teknologien bak det. Jeg gjorde altså litt av alt som produktsjef i en tidlig fase, samtidig som jeg prøvde å finne ut hva produktledelse var og lærte faget. Men det var virkelig produktledelse i oppstartsbedriftsstil.

Deretter startet jeg min egen oppstartsbedrift, Rap to Beats. Det innebar i praksis at jeg gjorde nøyaktig det samme, bare med enda mer koding. Jeg bygde langt flere versjoner av appen. Jeg hadde altså en tydelig bakgrunn som bygger da jeg gikk inn i produktledelse. Derfra gikk jeg over til ordentlig produktledelse i et selskap som het thredUP, som nå er børsnotert.

Jeg begynte da selskapet var i serie C, og sluttet da det var i serie E. Sammen bygde vi opp mange av de tidlige vekstteamene der. I 2014 var Ubers verveprogram for eksempel det store samtaleemnet. Jeg husker at da vi lanserte verveprogrammet vårt, ble det en enorm drivkraft for vekst. Man kunne gjøre enkle ting som det.

Det var ikke engang optimalisert. Jeg begynte å lansere produkter og innså at vi som produktsjefer kunne endre vekstbanen til selskaper grunnleggende. Det var da jeg virkelig viet meg til produktledelsesfaget. Siden den gang har jeg vært produktsjef i selskaper som Google, Affirm og Epic Games, og senest Apollo.io, der jeg var visepresident for produkt. Nå arbeider jeg med nyhetsbrevet på heltid.

Hannah Clark: Fantastisk. Og jeg vet at så mange setter stor pris på det.

I dag skal vi fokusere på funksjonsfabrikker, og spesielt på hvordan produktsjefer kan overleve i en organisasjon som fungerer som en funksjonsfabrikk. Det er nesten blitt et skjellsord i bransjen nå.

La oss begynne fra starten. Hvordan utvikler organisasjoner seg til funksjonsfabrikker, og hvorfor er dette et så vanlig resultat?

Aakash Gupta: Jeg tror faktisk at alle veier fører til funksjonsfabrikken. La oss si at du befinner deg i et miljø med myndiggjøring, et klassisk myndiggjort miljø. Det som har skjedd de siste fire–fem årene, er én av et par ting.

Enten har grunnleggeren, slik som i Airbnb, tatt tilbake kontrollen og sagt: «Dette er noen av tingene jeg vil ha bygget.» Eller så kan produktledere ha tatt kontroll gjennom mange oppsigelser og omorganiseringer. Det de ofte gjør, er å bruke konstante omorganiseringer som en måte å plassere folk i roller og få bygget arbeidsprodukter og funksjoner som de selv ønsker.

Det som til syvende og sist skjer, er altså at enten toppsjefer eller produktledere, på grunn av presset i det senere markedet, sier: «Vi kan ikke bare ha myndiggjøring. Vi kan ikke bare overlate dette.» Noen ganger ser jeg at produktsjefer er 26 år gamle og har fire års arbeidserfaring.

Vi kan ikke bare overlate beslutninger om produktet i en virksomhet verdt én milliard dollar til dem. Det som har skjedd, er derfor at selv i klassisk myndiggjorte miljøer, helt opp til Google og Netflix, forteller folk jeg snakker med at det ikke er slik at produktsjefene plutselig bestemmer 100 % av veikartet.

Mange ganger foregår det en nedenfra-og-opp-prosess og en ovenfra-og-ned-prosess parallelt, uten at det er synlig. I nedenfra-og-opp-prosessen kommer produktsjefen med ideene sine og sender dem inn i planleggingen. Men når man ser på resultatet av det som til slutt blir vedtatt, er mye av det ting ledere måtte godkjenne, bli overbevist om eller ofte selv hadde ideene til.

Jeg tror derfor mange pynter på det myndiggjorte miljøet med OKR-er og kvartalsplanlegging, men sluttresultatet er likevel en funksjonsfabrikk. Kanskje bare en fjerdedel av selskapene er reelt myndiggjorte til å begynne med, før de synker ned i en funksjonsfabrikk.

For de andre 75 % av selskapene vil jeg si at omtrent 30 % befinner seg i en omstillingsfase. Disse selskapene sier: «Vi forstår at vi må gå over til smidig arbeidsmetodikk. Vi forstår at vi må få myndiggjorte produktsjefer.» Men det som igjen skjer, er at når produktsjefer arbeider med andre funksjoner – for eksempel design, utvikling, forretning og salg – i bransjer som bank og helsevesen, der mye av denne digitale omstillingen skjer, er disse menneskene fortsatt vant til å arbeide på funksjonsfabrikkmåten, altså fossefallsmetoden.

Selv om produktorganisasjonen ønsker å gjennomføre endringene, tar det flere år. Jeg snakket med Marty Cagan, og han sa at det tar tre år. Jeg tror det stemmer. Det tar omtrent tre år. Det finnes altså selskaper som befinner seg i denne blandingen. Det som ender opp med å skje, er at produktsjefer holdes ansvarlige for måltall, samtidig som de får beskjed om hvilke funksjoner de skal bygge.

Det er en rotete mellomposisjon. Den siste gruppen består av åpenbare fossefallsmiljøer og åpenbare funksjonsfabrikker, og mange steder synes det er helt greit å arbeide slik. Hvis du snakker med en gjennomsnittlig produktsjef i Apple, er det lederne som avgjør mange av produkt- og funksjonsbeslutningene. Jony Ive og Steve Jobs tok mange av de viktigste beslutningene da han var der.

Den modellen kan fortsatt lykkes, og folk tenker: «Den lykkes ikke.» Marty sa at de beste selskapene alle er myndiggjorte, men jeg har funnet ut at alle veier fører til funksjonsfabrikken.

Hannah Clark: Når man følger tankerekken, ser jeg at det gir logisk mening.

La oss gå gjennom noen av trinnene du beskriver i blogginnlegget du skrev om dette temaet. Hvis du ikke har lest blogginnlegget, er det svært interessant hvordan du har delt det opp, og at du har inntatt et litt kontroversielt standpunkt til hvordan man bør reagere på å være produktsjef i en funksjonsfabrikk. Før vi går inn i trinnene, kan du si litt om hvor du står i dette, og hvilken enighet du har, særlig med Melissa Perry?

Aakash Gupta: Ja. Jeg tror det finnes idealister og realister. På den idealistiske siden har du folk som Marty Cagan, Teresa Torres og John Cutler. Jeg er veldig glad i, beundrer og leser alt de skriver. Men jeg tror de mener at du som produktsjef bør prøve å omforme organisasjonen hvis du befinner deg i en funksjonsfabrikk.

Det er i bunn og grunn det de forkynner, og mange av verktøyene og innsiktene de så sjenerøst deler gratis, handler om dette. Jeg respekterer dem, men det er det de tror på. Jeg og Melissa Perry, og andre som Clair Vaux og Powell Hearn, befinner oss litt mer på den realistiske siden av skalaen. Det vil si at jeg ikke tror du som produktsjef, med mindre du kanskje har åtte–ti års erfaring og i tillegg har tittelen gruppeleder for produkt eller høyere, egentlig har erfaringen eller innflytelsen som trengs for å omforme hele organisasjonen effektivt.

I stedet kan du kanskje tenke på en annen strategi. Hvorfor sier jeg det? Fordi jeg har sett så mange forsøke å leve etter denne idealistiske tilnærmingen. Mange har kanskje hørt meg fortelle dette før, siden jeg kan høres ut som en ødelagt plate, men jeg liker å sortere produktledelsesforumet på Reddit etter innleggene med høyest rangering gjennom tidene.

Jeg tror fortsatt at åtte av ti av disse innleggene handler om produktsjefer som sier: «Jeg hater jobben min. Jobben min er elendig.» Hvis du leser detaljene, handler det om produktsjefer i funksjonsfabrikker. Noen av sitatene er: «Jeg begynte med produktledelse etter å ha lest INSPIRED, og jeg trodde jeg skulle kunne bestemme veikartet, men jeg er bare en som tar imot bestillinger fra toppsjefen.»

Dette er et ekstremt vanlig scenario: Folk befinner seg i de 75 % av selskapene som uttrykkelig er funksjonsfabrikker, og de er misfornøyde med jobben fordi den faktisk er slik. Når vi tenker på dette, føler jeg at rådet mitt til leserne av nyhetsbrevet, for å unngå all denne forvirringen, realistisk sett er: Bare omfavn det. Overgi deg til fabrikken. Det er bedre å vite at du er i en fabrikk. Da kan du si: «Greit, som fabrikkarbeider, hva må jeg gjøre for å omfavne dette og komme videre?»

Hannah Clark: Ja, jeg tror den innstillingen har mye å si for hvor godt vi klarer oss i enhver vanskelig situasjon. Men det trenger ikke være vanskelig.

La oss gå litt gjennom trinnene du presenterte i blogginnlegget, med utgangspunkt i å overgi seg til fabrikken, som du allerede har vært inne på. Når opplevde du at dette virkelig falt på plass som et nødvendig trinn i prosessen?

Aakash Gupta: Jeg tror det var etter mislykkede forsøk på omstilling. Jeg har for eksempel vært i ulike typer miljøer. Mange produktsjefer har ikke vært i et spillmiljø. Jeg jobbet hos Epic Games med Fortnite. Mange tenker på funksjonsfabrikken som at toppsjefen, produktdirektøren eller designdirektøren bestemmer. I et spillselskap er det ofte designerne som finner på kjempekule ting, og de kreative som sier: «Dette blir fantastisk.»

De fyller neste sesonglansering med de mest fantastiske opplevelsene. Som produktsjef er det åpenbart for meg at det finnes lavthengende frukter når det gjelder ytelse, introduksjon og oppdateringer. Hvis noen har prøvd å oppdatere Fortnite, vet de at det fortsatt finnes forbedringsmuligheter. Jeg oppdaterte det nylig.

Det var en fil på 42 GB. Datamaskinen min brukte to timer, og jeg bruker Mac, noe som er forferdelig. Det tok ytterligere 50 minutter å installere oppdateringen. Vi snakker altså om ekstrem friksjon, og selskapet lanserer disse oppdateringene to ganger i uken. Det betyr flere timer med friksjon to ganger i uken. I butikken for kjøp i spillet fantes det også lavthengende frukter, for eksempel å lage flere varianter rettet mot folk som bruker 3–4 000 dollar i året i butikken.

Men for å overbevise folk som brydde seg om hva som var kult, kunne jeg ha valgt én tilnærming. Jeg tenkte først at dette kanskje var smart: «Hei, vi må fokusere på resultater, ikke leveranser, og ikke på kule funksjoner.» Alt dette falt for døve ører. Jeg prøvde faktisk dette. Deretter var jeg i Affirm, som hadde en svært sentralisert planleggingsinfrastruktur.

Jeg tenkte: «Greit, jeg er gruppeleder for produkt. Teamet mitt skal arbeide med mer uklare problemer.» Det fungerte overhodet ikke gjennom den første planleggingssyklusen. Lederne så på planen og sa: «Har dere gjort noe arbeid? Alle andres veikart er mye mer detaljerte, med fantastiske skisser av funksjonene, og analyseteamet har beregnet inntekts- og resultateffekten ned til sju signifikante sifre.»

Da ser du rett og slett dårlig ut. Jeg har selv gjort disse feilene, og nå har jeg også veiledet mange produktsjefer. Mange kommer til meg fordi de sliter litt i karrieren. De kan ha fått en lavere vurdering enn de ønsket.

Når jeg undersøker saken nærmere, gjør vi ofte en 360-graders vurdering. Da finner jeg at de har en designer og en utvikler som sier: «Ja, produktkravspesifikasjonene hans var ikke detaljerte nok.» Jeg opplever at disse produktsjefene tror de befinner seg i en myndiggjort verden, men i virkeligheten lever de i en funksjonsfabrikk, og funksjonsfabrikken krever en svært detaljert produktkravspesifikasjon.

De overser derfor disse grunnleggende prinsippene og presterer dårligere. Alt dette er altså motivert av at du må forbedre prestasjonene dine. I min virkelige erfaring fra disse ulike miljøene har jeg ikke sett at man kan endre ting umiddelbart. Det eneste stedet jeg virkelig klarte det, var etter at jeg nådde direktør- og visepresidentnivå.

Da jeg var i thredUP og Affirm, var jobben faktisk å heve arbeidsmåtene i organisasjonene. Når det skjer, må du bevisst og gradvis bryte ned funksjonsfabrikken. Det er flott at vi har definert hva funksjonsfabrikken er, fordi du i praksis kan si: «Jeg skal gradvis bryte ned hvert element i funksjonsfabrikken, siden den er et antidesignmønster.» Poenget mitt som karriereråd er likevel at hvis du ikke er på et visst nivå, bør du ikke prøve å løse dette antidesignmønsteret.

Hannah Clark: Det bringer oss til neste trinn: å tilpasse seg miljøet. Det du skrev, handler om å fokusere på hva den egentlige jobben din er – å gjøre den egentlige jobben din. Kan du utdype dette trinnet og undertrinnene som hører til?

Aakash Gupta: Ja. Det jeg synes er fascinerende, er at når jeg ser tilbake på arbeidsproduktene jeg skapte i de ulike jobbene mine som produktsjef, særlig de som ble godt mottatt, var de helt forskjellige. Hos Epic Games handlet det til syvende og sist om presentasjoner av kule funksjoner.

Ofte satt jeg til klokken to om natten sammen med en teknisk designer, og vi lagde en spillbar demonstrasjon av den kule funksjonen med uklare grafikkelementer. Det var dette som fungerte godt. Hvis jeg ser på Affirm, har jeg allerede forklart litt om miljøet. Der fungerte det da jeg kom med et fantastisk veikart med konsekvensvurdering, fylt med regnearkdata og modeller for beregning av effekt. Det var i praksis to fullstendige motsetninger.

Du må derfor vurdere hva som kjennetegner suksess innen produktledelse i ditt miljø. Jeg anbefaler å intervjue dem som har vært produktsjefer lengst i selskapet. Det er én god metode. Deretter kan du snakke med produktsjefer som nylig har blitt forfremmet. Dette er to svært gode ting å undersøke.

Du bør selvsagt ikke holde deg til overflaten i disse relasjonene. Jeg anbefaler at du prøver å spise lunsj med personen, helst ansikt til ansikt. Ikke grav for dypt med én gang. Prøv kanskje først å tilby dem noe av verdi. Når du har opparbeidet deg et godt forhold til dem og de hjelper deg som mentor, kan du begynne å stille spørsmål.

Jeg liker å spørre: «Skriver du en produktkravspesifikasjon for hver funksjon? Kan du dele den beste produktkravspesifikasjonen din? Kan du dele den siste forfremmelsespakken din? Kan du dele notatene fra den siste én-til-én-samtalen med lederen din?» Dette er svært taktiske spørsmål, men du kan ikke spørre hvem som helst om dette hvis dere ikke er venner.

Jeg sier derfor at du først bør bli venn med dem. Kanskje også la dem bli mentoren din, selv om jeg ikke anbefaler å spørre direkte om de vil være mentoren din. Mange ønsker å se at produktsjefene og produktlederne deres har sitt eget tyngdepunkt. De vil heller tolke det som: «Han eller hun er undersøkende og bryr seg virkelig om å lykkes.»

Det du bør gjøre, er å gjennomføre disse intervjuene akkurat som med ditt eget produkt. Når du begynner i en jobb, skal du intervjue kunder, ikke-kunder, konkurrenter og andre i selskapet. Deretter anbefaler jeg sterkt at du har en direkte én-til-én-samtale med teknologilederen, utviklingslederen, designeren, brukerforskeren, analytikeren og sannsynligvis også lederen til lederen din, der dere tydelig definerer roller og ansvarsområder.

Du bør være svært tydelig. Spør designeren: «Hva synes du om at produktsjefer lager skisser og trådmodeller?» De fleste designere vil si: «Nei, det er jeg kanskje ikke så interessert i.» Noen kan si at det er greit, så lenge det ikke gjøres i Figma. Du må kjenne til slike nyanser. Forstå hvordan du skal arbeide med dine konkrete interessenter.

En feil jeg har sett hos noen som gjennomfører disse intervjuene, er at de antar at jobben som produktsjef er lik jobben til en annen produktsjef i et annet team. Men designeren, utvikleren og analytikeren du arbeider med, har sine egne forventninger. Alle ønsker å bestige fjellet produktledelse for å nå visepresidentnivå.

Men akkurat nå bør du bare fokusere på trinnet foran deg, på menneskene nærmest deg, og lage en avtale. Når du har denne avtalen, kan du begynne å teste den og se hva som blir godt mottatt og hva som ikke gjør det. Kanskje utviklingslederen ikke vet at utviklerne i teamet hans elsker å bli invitert til samtaler om kundeinnsikt.

Det lærer du bare gjennom praksis. Følg derfor nøye med på den lille gruppen din. Dette er grunnleggende karriereråd, men grunnen til at jeg tar det med her, er at det handler om å forstå hva jobben din som produktsjef faktisk er. Jeg tror ikke noen jobber som produktsjef er like.

Hannah Clark: Det høres ut som om menneskene du arbeider tettest med, i alle arbeidsmiljøer danner en slags mikrokultur. Det er derfor viktig å forstå nyansene i denne kulturen, hvilke språk alle snakker, og sørge for at forventningene dere har til hverandre, er samstemte. Det setter jeg stor pris på.

Det henger også sammen med at du nevnte én-til-én-samtaler med personer som har lykkes i rollen over lengre tid.

Det neste trinnet i utviklingen din er å lage en vei til forfremmelse. Disse personene er en viktig del av dette trinnet. Kan du fortelle litt om strategien for å lage et slikt karriereveikart for deg selv?

Aakash Gupta: Hvis du tenker på funksjonsfabrikken, finnes det vanligvis et svært konsekvent sett med kriterier du må oppfylle. Disse kriteriene er ofte uskrevne og usagte, og de blir feiltolket av din egen leder. Mange støtter seg derfor på sin egen leder. Jeg har hatt personer i teamet mitt som var ganske pågående i én-til-én-samtaler om å bli forfremmet. Men det de ikke forsto, og som jeg måtte veilede dem i, var at jeg ikke var den eneste som tok avgjørelsen om forfremmelsen deres.

La oss ta Affirm som eksempel. Jeg skriver en vurdering for deg som jeg sender til en forfremmelseskomité. Denne komiteen består av alle produktlederne på mitt nivå eller høyere. Alle disse personene sier i det minste noe i løpet av samtalen. Etter at du har overbevist meg, må du derfor i praksis overbevise hver enkelt produktleder på mitt nivå eller høyere om å ha noe positivt å si om deg.

Du må samarbeide med dem, og det er dette som faktisk har fungert i Affirm. Det handler om å forstå det usagte. Jeg arbeidet med andre produktsjefer i Affirm som hadde problemer med å bli forfremmet. Én hadde vært senior produktsjef i omtrent tre år og hadde gjort mye godt arbeid.

Jeg begynte å ha én-til-én-samtaler med henne, selv om hun ikke var i teamet mitt, og hun ble forfremmet i neste runde. Dette var rådet jeg ga henne: «Jeg var med i den siste forfremmelseskomiteen din, og det var bare lederen din som snakket varmt om deg.» Lederen hennes hadde ikke gitt henne dette rådet.

Du kan altså ikke alltid stole på at din egen leder gir deg hele bildet. Du må i praksis bygge relasjoner med andre ledere som får folk forfremmet. Finn disse personene og bygg relasjoner. Igjen vil jeg si: Bli venn med dem først, og gjør kanskje noe arbeid sammen med dem slik at de kan se at du er dyktig.

Deretter kan du spørre: «Hei, hvilken erfaring har du med forfremmelseskomiteer?» For meg har de beste innsiktene kommet ansikt til ansikt over noen øl etter arbeidstid. Da kan du virkelig lære hva som foregår. Noen tar en vanlig arbeidsdag fra ni til fem. Jeg vil egentlig anbefale å trekke fra klokken 16–17 på torsdag og fredag og heller gjøre det til klokken 20–21, fordi det vil være langt mer effektivt for slike samtaler.

Bruk tiden til å lære hvordan folk blir forfremmet. Mange har spurt meg: «Hvordan kom du så raskt til visepresidentnivå?» Det grunnleggende svaret er at jeg forsto forfremmelsesveiene i de ulike selskapene. I nesten alle selskaper jeg begynte i, ble jeg forfremmet i løpet av ett eller to år. Jeg fikk flere personer i teamet, og ansvarsområdet mitt ble større. Det skyldtes at jeg var helt fokusert på denne veien til forfremmelse.

Da jeg spurte vennene mine: «Har du snakket med noen om dette?» eller «Hva vet du om dette?», visste mange ikke engang at det fantes en forfremmelseskomité i Affirm. Det viser at det finnes et reelt kunnskapsgap. Å fylle dette kunnskapsgapet er derfor det første trinnet. Det andre er å tenke på hvilke unike styrker du har.

Som produktsjef kommer alle til å slippe noen baller et sted. Kanskje tilbakemeldingene dine på design er åtte av ti. Kanskje evnen din til å håndtere vanskelige interessenter er sju av ti. Uansett hva det er, bør du lene deg inn i styrkene dine. Kanskje det er skriving. Det var en åpenbar styrke for meg.

Len deg virkelig inn i den. Hvordan kan du lage en ukentlig oppdatering? Hvordan kan du gjøre en fantastisk produktstrategi kjent for flere produktteam enn du normalt ville gjort? På den måten utnytter du styrkene dine innenfor de unike forfremmelseskriteriene. Jeg gjorde dette ved å dele tekstene mine. Jeg kunne si: «Hei, denne delen av strategien min, plattformene for betaling, påvirker produktteamet for plattformene.»

Før vi ferdigstiller veikartet vårt, deler jeg derfor et skjermbilde med deg. Det kunne vekke nok interesse til at de så på resten av dokumentet og sa: «Oi, han gjør godt produktarbeid.» Det handler om å utnytte styrkene dine opp mot kriteriene.

Hannah Clark: Dette er svært smart og veldig taktisk. Jeg setter stor pris på den taktiske tilnærmingen.

Det neste trinnet er å løfte isolerte arbeidsmåter. Når du viser til isolerte arbeidsmåter i denne sammenhengen, hva innebærer dette trinnet, og hva er noen konkrete eksempler på hvordan folk kan utvikle disse ferdighetene?

Aakash Gupta: Jeg nevnte at dette særlig bør gjøres på organisasjonsnivå fra gruppeledernivå og oppover.

Du bør i praksis teste dette med enkelte team og bevise at det fungerer. Hvis du er under gruppeledernivå, mener jeg du bør teste det innenfor ditt eget team. Etter at du gjennom én-til-én-samtaler, der du har etablert en avtale med design-, utviklings- og analysepartnerne dine, har bevist at du kan lykkes under forventningene deres, er det på tide å si: «La oss løfte dette opp et nivå.»

Du bør også be om tilbakemeldinger og justere enkelte ting basert på det de sier. Tilbakemeldingen din bør være slik. Jeg har prøvd ut denne rekkefølgen mange ganger mens jeg har veiledet folk, og dette er rekkefølgen på teknikkene som fungerer best.

Nummer én er å skrive oppsummeringer av funksjonsresultater. Jeg synes disse er lite truende i en funksjonsfabrikk. Vi har lansert en funksjon. Den kom fra Brian Chesky, toppsjefen, ja, men han ønsker å vite hva som skjedde og hvorfor. I funksjonsfabrikker opplever jeg faktisk at ledere virkelig bryr seg om hvorfor noe skjedde.

Det produktsjefer ofte rapporterer, er: «A gjorde det bedre enn B, så jeg viderefører A.» Det er ikke like imponerende som: «A gjorde det bedre enn B fordi …» Plutselig påvirker du hva som kommer etterpå. Selv om dette er en funksjonsfabrikk, og de kanskje ikke lytter til hva som kommer etterpå, følger det også av fortellingen din.

La meg gi et konkret eksempel. Hvis du er i Airbnb og nettopp har lansert totalpris fordi Brian Chesky ba deg lansere totalpris, bør du gå tilbake til ham med hva som skjedde og hvorfor. Det interessante er at vi vet at konverteringsraten for det folk kjøper, vil gå ned. Spørsmålet er hvor mye. Vi vet at NPS-en vil øke fordi folk ikke vil bli overrasket av prisen.

Vi tror faktisk at konverteringsraten vil øke når folk legger noe i handlekurven og fullfører bestillingen. Vi er derfor usikre. Vi vet at konverteringsraten øverst i trakten på kartsiden vil gå ned. Vi vet at konverteringsraten på kjøpssiden vil gå opp.

Vi vet ikke hvor mye den samlede konverteringsraten vil bli påvirket. Brian kommer til å bry seg om dette. Når dataene kommer tilbake, er resultatet faktisk vanskelig å tolke. Konverteringsraten gikk bare ned 2 % på kartsiden, men opp 6 % på kjøpssiden. Samlet konverteringsrate gikk dermed opp 4 %. Den geniale ideen hans var altså tilsynelatende genial.

Vi ser en økning på 4 % i konverteringsraten. Hvorfor skjedde det? Du må gå videre. Intervju et par personer til, observer dem og snakk med brukerforskeren. Du kan finne ut at folk tidligere ikke stolte på prisene på kartet, for eksempel 357. De stolte aldri på dette, og vi løste dermed et tillitsproblem.

Da kan du gå tilbake til Brian og si: «Grunnen til at totalpris gjorde det bedre når det gjelder konverteringsrate, og jeg vil vise deg denne interessante innsikten, er at den også gjorde det bedre på kartet: Folk hadde svært lav tillit til oss når det gjaldt prisen per natt.»

Da kan han spørre: «Hvor ellers har folk lav tillit til oss?» Kanskje folk har lav tillit til enkelte av anmeldelsene våre, eller til noen av Airbnb Plus-stedene våre. Deretter kan du lage et veikart basert på dette. Jeg gikk gjennom dette lange eksempelet for å forklare at oppsummeringer av funksjonsresultater er lite truende, og at de leder deg inn på den første veien.

Den andre interessante tingen er å beregne effekt. Produktsjefer sitter ofte fast i å være ansvarlige for resultater, samtidig som de blir gitt leveranser. I den verdenen synes jeg det er spennende og effektivt å lage det sterkeste mulige argumentet når du får en leveranse, med mest mulig data om hvordan funksjonen kommer til å prestere.

Et eksempel er at toppsjefen i thredUP mente at en endring av verveprogrammet fra 10/10 til 30/30 plutselig kunne gi en inntektsøkning på 5 % neste måned. Jeg brukte de mest generøse antakelsene, det høyeste antallet delinger og de mest generøse anslagene for aksept av vervinger fra de beste kampanjene våre. Da ble det tydelig at det høyeste jeg kunne komme frem til, var en økning på 0,1 % i inntektene neste måned.

Da ble det tydelig for ham at denne funksjonen ikke kom til å oppnå målet han ønsket. Å bygge en økonomisk modell for effektberegning er derfor nummer to.

Nummer tre er at folk vanligvis setter vognen foran hesten. De vil gjøre innsiktsarbeid først. Jeg sier at innsiktsarbeid er nummer tre. Du har begynt å skrive oppsummeringer av funksjonsresultater og beregne effekten av funksjoner før de er lansert. Når du får en leveranse, sier du: «Takk for trådmodellen, toppsjef. Nå skal vi gjøre ordentlig innsiktsarbeid og ta deg med på veien.»

Jeg viser deg kanskje noen videoer ved hjelp av ny programvare som Dovetail, der jeg på 30 sekunder kan trekke frem høydepunktene: «Dette er problemene med løsningen.» Deretter viser jeg det nye designet. Noen gjør allerede deler av dette. Neste steg er å utvide til innsikt i problemer. Problemet du forsøkte å løse med dette designet, kan i virkeligheten løses i en helt annen del av produktet. Da går du fra innsikt i løsningen til innsikt i problemet. Det er omtrent 3A og 3B.

Nummer fire er å gå over til OKR-er. Her beveger vi oss virkelig inn på gruppeledernivå. Som hovedansvarlig produktsjef anbefaler jeg deg å innføre OKR-er hvis resten av selskapet gjør det? Sannsynligvis ikke. Men hvis du er gruppeleder for produkt, synes jeg OKR-er er svært effektive når teamene dine først arbeider med innsikt.

Mange gjør OKR-er som nummer to. De gjør innsiktsarbeid først, deretter OKR-er. Men de har ikke utviklet ferdighetene for oppsummeringer av funksjonsresultater og effektberegning. Jeg opplever at OKR-ene i slike selskaper bare er tull. De bommer stort sett på alle OKR-ene sine. Jeg vil si at dette gjelder omtrent 90 % av selskapene.

Derfor har jeg denne bevisste rekkefølgen. Etter dette kommer trær for mål, problemer og løsninger, som hjelper deg å knytte OKR-ene til problemer og løsninger. Til slutt kommer produktstrategier. Det er morsomt, for alle tror at produktledelse er produktstrategi. Jeg tror ikke det før du faktisk har kontroll over hele treet for mål, problemer og løsninger, slik at du kan skrive en produktstrategi. Inntil da skriver toppsjefen produktstrategien din, i praksis. Når du er fullt myndiggjort, kan du legge til produktstrategi.

Hannah Clark: Det neste trinnet er selvsagt å bygge koalisjonen din. Vi har allerede snakket litt om å danne tette relasjoner med design- og utviklingsressursene dine. Jeg er nysgjerrig på om du har en historie fra virkeligheten om hvordan dette har fungert for deg?

Aakash Gupta: Ja, la oss gå tilbake til Epic Games. Vi snakket litt om den situasjonen. Det var faktisk relasjoner som lå i sentrum for all innflytelsen jeg hadde der. Noe av det jeg virkelig ønsket å arbeide med, var ytelsen i Fortnite.

Fortnite er et spill med høye ferdighetskrav. Folk spiller rundt 2 000 timer i året. Det er som en fulltidsjobb. Folk legger ned enormt mye arbeid i spillet. Grunnen er at jo flere timer du legger inn, desto mer får du ut av det. Det finnes mennesker som konkurrerer på dette nivået, og teknikker som må læres.

Problemet er at hvis forsinkelsen er svært høy eller bildefrekvensen er dårlig, tar ferdighetsutviklingen slutt. I dataene la jeg merke til at personer med svært dårlig ytelse fordi de hadde en dårlig maskin eller dårlig internett, sluttet etter 1–2 000 timer, mens personer med svært god ytelse ble værende i 12–14 000 timer.

Det finnes fortsatt mennesker som spiller Fortnite i dag. Spillet kom ut for lenge siden. Dette var min avgjørende innsikt, men jeg kunne ikke bare lede med den, slik jeg kanskje ville gjort hos Google, og si: «Derfor prioriterer vi ytelse.» Jeg måtte i stedet være svært innflytelsesrik overfor viktige designere og utviklere.

Jeg måtte forstå at det fantes en person som het Jason. Han hadde skapt Call of Duty og ledet nå Fortnite. Til syvende og sist tok han alle beslutningene om hva som faktisk skjedde i Fortnite. Han respekterte virkelig meningene til de mest hardtarbeidende utviklerne og designerne, altså dem som arbeidet rundt 120 timer i uken.

De lanserte alt. I spillbransjen er dette dessverre virkeligheten. Det finnes mennesker som arbeider like mye som i investeringsbanker. Han respekterte disse menneskene, med god grunn. Jeg bestemte meg for at det var disse personene jeg måtte ha med i koalisjonen min.

Fordi de arbeidet så hardt, hadde de ikke tid til å se hvordan alt de gjorde, fungerte. Det var min inngang. Som jeg sa, er oppsummeringer av funksjonsresultater inngangen. Jeg begynte å vise dem: «Dere lanserte Fortnite kapittel 2, sesong 4, oppdatering 6.4. Dette er resultatene.» Ingen fortalte dem hvordan oppdatering 6.4 fungerte, langt mindre hvordan kapittel 2, sesong 4 fungerte.

Jeg kom med informasjon om at oppdatering 6.4 gjorde dette og dette med spillet. Bruken av skarpskyttere økte med 8 %. Antallet drap gikk ned med 6 %. Spillere med lav rang slo spillere med høy rang oftere enn noen gang før i spillet. De ble begeistret over resultatene av det harde arbeidet sitt. De begynte å bry seg om det jeg sa.

Deretter la jeg litt ytelsesstøv oppå det hele. Spillere med forsinkelse over 200 millisekunder sluttet i et høyere tempo enn noen gang tidligere. Små ting som å legge rifler, ballere og biler inn i spillet betydde at personer med over 100 millisekunders ping mistet rangeringen sin i enestående tempo.

Slik innsikt hjalp dem gradvis med å bygge ytelse inn i spillet. De begynte å innse hvor mye ytelsen påvirket spillet, og vi forbedret ytelsen betydelig. Dette er et eksempel på at jeg tenkte strategisk på hvem koalisjonen min burde og kunne bestå av, og bygde baklengs for å etablere relasjonen og innflytelsen.

Hannah Clark: Det er smart på så mange nivåer. Du bygger gode relasjoner, folk stoler på deg, og du blir innflytelsesrik nesten passivt. Genialt.

Før vi avslutter, vil jeg gjerne ta opp noen vanlige feil du har lagt merke til at produktsjefer gjør i funksjonsfabrikkmiljøer. Én av dem er åpenbart å ikke innse at man er dømt til å være i en funksjonsfabrikk. Hvilke andre feil kan vi gå gjennom for dem som lytter?

Aakash Gupta: Det er kanskje seks jeg vil nevne. Den første er at de bare følger leveransemåltall. De har hørt rådet mitt og overgitt seg til fabrikken. Fabrikken bryr seg om hastigheten målt i Jira-poeng. Fabrikken bryr seg om hvor mange store funksjoner jeg lanserer i tide. Fabrikken bryr seg om hvor få ganger jeg skyver en tidsfrist for en funksjon.

Det er det eneste jeg optimaliserer for. Jeg tror fortsatt det er en feil. Du må fortsatt se på resultatene av alle funksjonene dine. Jeg vil ikke at overgivelsen til fabrikken skal bety at du slutter å gjøre godt produktarbeid. Fabrikken kan be deg bygge en forferdelig funksjon uten effekt, men du må fortsatt bruke produktforståelsen din før du bygger den.

Det vil gjøre to ting. For det første tar du riktige beslutninger om ressursfordeling der du kan. For det andre bygger du ferdighetene som trengs for godt produktarbeid. Jeg opplever at mange som begynner i en funksjonsfabrikk, slutter å utvikle ferdighetene sine.

Jeg kan si: «Ben jobbet i funksjonsfabrikken hos J.P. Morgan i fire år, og jeg synes han er en dårligere produktsjef enn da jeg kjente ham i Google.» Slike historier har faktisk skjedd. Det handler derfor om å holde ferdighetsutviklingen høy og fortsatt forstå hvilken effekt på måltall og brukere alt du lanserer, har.

Den andre feilen produktsjefer i funksjonsfabrikker gjør, er at de, fordi de har omfavnet jakten på store funksjoner og toppsjefen er begeistret, bare fortsetter å lansere funksjon etter funksjon. På et tidspunkt forsømmer de teknisk gjeld.

Det kommer stadig opp. Utvikleropplevelsen blir dårligere, og de sier at byggetiden er tre timer og at det tar en hel dag å gjøre en enkel endring. Men du fortsetter å si: «Vi har den viktige Fortnite-sesong 16 foran oss, og vi må lansere den, så vi må bare ignorere dette.» Jeg tror dette er svært vanlig.

Jeg har faktisk sett dette hos de fleste produktsjefer i funksjonsfabrikker. Jeg liker å skille mellom tilfeldig og bevisst teknisk gjeld. Den tilfeldige tekniske gjelden kommer fra brukeropplevelsen, og den ønsker jeg å minimere. Jeg vil sette av tid til å håndtere den.

Så har du den bevisste tekniske gjelden, som oppstår når du bare jager den store funksjonen. Vi inngikk disse kompromissene, og så lenge du er bevisst på dem, er det greit. Hvis du investerer i funksjonen og den går fra null til én til hundre, bør du gå tilbake og rette opp kompromissene.

Den tredje feilen er å ignorere tilbakemeldinger fra brukerne. Jeg nevnte ganske tilfeldig at du til og med bør vise trådmodellen din og endre den. For noen er dette et stort steg fremover. Jeg synes ikke det bør være et stort steg for noen produktsjef. Når jeg spør noen: «Du lanserte denne store funksjonen. Hvor mange brukere viste dere de endelige designene til?»

For produktsjefer som lytter, vil kanskje 50 % si: «Vi viste den siste store funksjonen vår til ingen brukere. Vi måtte bare skynde oss å lansere den.» Jeg synes dette er en stor feil. Selv om du sitter fast i funksjonsfabrikken, står karrieren din på spill gjennom alt teamet ditt lanserer.

Ikke misforstå dette. Som produktsjef er det teamet ditt lanserer, CV-en din, og det avgjør om du får sparken eller blir forfremmet. Sørg derfor for at dette er den beste versjonen av den dårlige ideen det kan bli.

Den fjerde feilen er å la frykten for å gå glipp av noe styre veikartet. Dette er faktisk den klassiske grunnen til at vi har funksjonsfabrikken.

HubSpot lanserte et CRM, så vi må ha et CRM. Typefully har publisering på LinkedIn, så Twitter-verktøyet vårt, Tweet Hunter, må ha publisering på LinkedIn. Vi føler frykt for å gå glipp av noe og at de stjeler kundene våre. Kanskje vår største kunde sluttet. Plutselig tenker vi: «Hvorfor bygger vi ikke bare alt som kunne ha reddet denne kunden?»

Jeg synes dette er en enorm feil. Jeg ville forsøkt å vise lederne dine hvor omfattende en funksjon egentlig er. Det var dette jeg nevnte om effektberegning. Etter oppsummeringene av funksjonsresultatene handler det om å beregne effekten. Du kan spørre: «Hvor stor er den mulige målgruppen?»

Dere vil bygge et helt nytt produkt i produktpakken vår. Det siste nye produktet vårt brukes av 0,2 % av brukerne. Tror dere virkelig vi må investere i enda et produkt som 0,2 % av brukerne kommer til å bruke? Når du ser denne frykten for å gå glipp av noe hos personen som styrer funksjonsfabrikken, er det et godt varselsignal.

Her må jeg kanskje avvike fra funksjonsfabrikken. Den femte feilen er å slite ut teamet. Dette er svært vanlig, også i myndiggjorte produktmiljøer, eller når man bare prøver å presse hardt. Selv om det er viktig å lansere raskt, gir et svært motivert og sunt team vanligvis de beste resultatene.

Du kan kanskje oppnå 10 % vekst med et utbrent team, men hvis du vil ha en vekst på 50 %, må teamet arbeide på sitt beste. Som produktsjef bør du derfor alltid argumentere for bedre verktøy, et budsjett for læring og utvikling og en godt timet samling utenfor kontoret.

Dette er min favoritteknikk. Jeg organiserer eller argumenterer ofte for slike ting. Jeg kan spørre sjefen min: «Hei, vi har nettopp lansert en stor funksjon, eller en stor funksjon skal snart lanseres. Jeg tror det ville vært flott om produktteamet mitt kunne samles for å feire det.»

Slike små ting kan ha stor betydning. Det går tilbake til de første dagene mine i produktledelse, da jeg tok med brownies til utviklerne når de lanserte en stor funksjon. Jeg ga designerne highfives når designet var godt. Slike små ting har stor effekt i alle funksjonsfabrikkmiljøer, fordi det ikke bare er produktsjefen som ofte er misfornøyd.

Designeren og utviklerne er også frustrerte. Den sjette feilen er å miste det større bildet av syne. Vi får hva-et, hva-et og hva-et. Vi glemmer ofte hvorfor-et. Jeg har snakket om hvorfor-et i forbindelse med måltall og brukerproblemer.

Men ikke glem produktstrategien. Selv om jeg satte produktstrategi som det siste trinnet, mener jeg at du bør utvikle ferdighetene dine innen produktstrategi, i tråd med den første feilen om å utvikle ferdighetene dine. Produktledelse som fag har blitt betydelig mindre de siste tre–fire årene.

Det finnes rett og slett færre jobber som produktsjef enn før, samtidig som produktdesign og produktutvikling fortsetter å vokse. Disse områdene vokser på bekostning av produktledelse. Hvis vi vil at produktsjefer skal lykkes i et miljø med færre jobber, må vi forsøke å ha innflytelse på produktstrategien.

Når du er i funksjonsfabrikken, selv om du omfavner den og går trinn for trinn gjennom isolerte arbeidsmåter, vil det i enhver fabrikk finnes 10–15 % av veikartet du kan påvirke. Det vil finnes 10–15 % av sprinteren som designeren eller utviklingslederen ønsker at du skal bidra til.

Du er fortsatt en del av teamet, selv om det er en fabrikk og vi har overgitt oss til det fabrikken bryr seg om. Sørg for at funksjonene dere lanserer, er utrolig strategiske. En av de beste produktsjefene i en funksjonsfabrikk arbeider fortsatt i Epic Games. Jeg kjenner også en som fortsatt arbeider i Affirm. Hver funksjon disse produktsjefene lanserer, endrer selskapets utvikling.

De lanserer ikke egne funksjoner så ofte, fordi de sitter fast i dette miljøet. Men når de gjør det, endrer det spillet. I Affirm lanserte denne personen maskinlæring for å organisere hvilke lån du bør betale tilbake. Det var en dyp maskinlæringsløsning i bakenden, men den forbedret tilbakebetalingsraten med omtrent 15 %. Det ga Affirm et bransjeledende fortrinn, og aksjekursen økte med 300–400 %.

Han skapte altså enorme resultater. Det er dette folk bør motiveres av. Jeg sitter fast i funksjonsfabrikken. Jeg har nettopp hørt på Aakash og Hannah i 45 minutter om funksjonsfabrikken. Prøv å utvikle geniale funksjonsideer på egen hånd og få dem inn der du kan.

Hannah Clark: Det var virkelig en avslutning som fortjener applaus. Aakash, tusen takk for at du tok deg tid til å snakke med oss. For de fem som lytter og som ikke følger deg ennå: Hvor kan de følge deg på nettet?

Aakash Gupta: Helst gjennom nyhetsbrevet. Jeg er på Substack. Jeg vet at noen ikke liker popup-vinduet for e-postadressen.

Du kan bare trykke på ignorer og fortsette å lese hvis du vil. I disse dager snakker jeg med over ti personer i gjennomsnitt for hver tekst. I den siste teksten min hadde jeg en gjestesamarbeidspartner. Vi snakket med ti personer hver og intervjuet dem. Vi fikk faktisk ekte innsikt.

Det er ikke den typen produktinnhold du kanskje ser fra meg på LinkedIn eller X, der du tenker: «Han lager vanlig produktinnhold, akkurat som alle andre.» Dette er forskningsstudier basert på faktiske mennesker. For jobbsøk innen produktledelse snakket vi med produktledere som nylig hadde fått stillinger som visepresident eller direktør. Vi snakket med rekrutterere som faktisk finner kandidater til bransjen.

Jeg prøver å bringe ekte data og ekte innsikt. Hvis folk er interessert i dette, er det dette jeg arbeider med, og der de kan finne meg.

Hannah Clark: Fantastisk. Vi sees der. Og tusen takk for at du kom.

Aakash Gupta: Greit, tusen takk.

Hannah Clark: Takk for at du lyttet. Du finner flere gode innsikter, veiledninger og verktøyanmeldelser ved å abonnere på nyhetsbrevet vårt på theproductmanager.com/subscribe. Du kan høre flere samtaler som denne ved å abonnere på The CPO Club, uansett hvor du får podkastene dine.