Bør det finnes helter innen produktledelse?
Innen produktledelse er det lett å ende opp med å ta på seg heltekappen. Men hva om den virkelige veien til suksess og gjennomslagskraft går lenger enn appellen ved å være teamets selvskrevne redningsperson?
I denne episoden får Hannah Clark selskap av Clement Kao – grunnleggeren av Product Teacher – for å dykke ned i heltemotets finurligheter innen produktledelse og utforske strategier for å styrke produktteam på en mer bærekraftig måte.
Høydepunkter fra intervjuet
- Clements vei fra ledelseskonsulent til Product Teacher [00:54]
- Clement har en utradisjonell bakgrunn. Han startet som ledelseskonsulent, gikk deretter over til å bli UX-forsker og dataanalytiker, og ble til slutt produktleder.
- Han la merke til at mange andre møtte lignende utfordringer innen produktledelse og manglet ressurser og veiledning.
- Etter hvert som karrieren utviklet seg, innså Clement at han kunne ha større innvirkning ved å hjelpe andre produktledere med å lykkes.
- Dette førte til at han grunnla Product Teacher, med mål om å hjelpe produktledere på ulike stadier i karrieren – fra nybegynnere til erfarne fagpersoner.
- Product Teacher har støttet over 7 000 produktledere innen områder som å komme inn i fagfeltet, utvikle karrieren og utforme produktstrategier og prosesser.
- En ny definisjon av heltemot innen produktledelse [02:44]
- Clement presiserer at heltemot innen produktledelse ikke nødvendigvis er negativt; det handler om hvor ofte og i hvilken sammenheng det brukes.
- Det forventes at produktledere tar ansvar og løser problemer når det er nødvendig, men å støtte seg for ofte på heltemot kan føre til problemer.
- Overdreven avhengighet av heltemot kan føre til at andre teammedlemmer forsømmer ansvarsområdene sine, slik at organisasjonen lider.
- Når en produktleder blir den eneste helten, svekker det andre deler av organisasjonen og gjør den avhengig av én enkeltperson.
- Det bør være en balanse, der produktledere griper inn bare når det virkelig er nødvendig, og ikke som en daglig eller ukentlig rutine.
- Hvis heltemot ofte er nødvendig, tyder det på dypere problemer i organisasjonen som må tas tak i.
Produktledere bør være klare til å ta ansvar når det trengs. Men hvis dette skjer ofte, kan det være underliggende problemer som krever oppmerksomhet.
Clement Kao
- Hvorfor produktledere ender opp med å ha for mange hatter [04:54]
- Clement forklarer at mange produktledere havner i heroiske roller på grunn av endringer i hvordan arbeidet organiseres over tid.
- Det har blitt vanlig å fordele ansvar på tvers av matriser, der enkeltpersoner støtter flere initiativer eller team samtidig.
- Manglende klarhet rundt hvem som skal håndtere bestemte oppgaver, fører til at man som standard henvender seg til produktlederen.
- Oppstartsbedrifter og mindre team mangler ofte tydelige retningslinjer for fordeling av oppgaver, noe som fører til at produktledere påtar seg ulike ansvarsområder.
- Når en produktleder har håndtert en oppgave på en vellykket måte, skaper det en selvforsterkende sirkel der det forventes at vedkommende fortsetter å gjøre det.
- Eksempler inkluderer produktledere som på ubestemt tid tar ansvar for analyse, markedsundersøkelser, kundediskusjoner eller salgssamtaler.
- Denne trenden har blitt forsterket det siste tiåret, og produktledere blir overbelastet på grunn av deres antatte kompetanse på ulike områder.
- Identifisere og håndtere organisatoriske svakheter [06:58]
- Clement antyder at hyppige tilfeller der produktledere må være helter, kan tyde på organisatoriske mangler.
- Enkelte heroiske innsatser forventes, men gjentakende mønstre tyder på dypere problemer.
- Organisasjoner som verdsetter retrospektiver, bør bruke dem til å analysere problemer og forhindre at de oppstår igjen.
- Hvis lignende problemer oppstår gjentatte ganger, er det avgjørende å håndtere de underliggende årsakene for å hindre at produktledere regelmessig påtar seg oppgaver som ligger utenfor ansvarsområdet deres.
- Regelmessige retrospektiver bør bidra til å identifisere og korrigere mønstre der produktledere blir overbelastet eller påtar seg oppgaver de ikke burde håndtere.
- Effektive retrospektiver: Et verktøy for organisatorisk endring [08:07]
- Clement understreker hvor viktig det er å ha retrospektiver uten skyldplassering når man skal håndtere systemiske problemer.
- Han anbefaler å fokusere på systemet, ikke enkeltpersoner, under retrospektiver.
- Ved å bruke et eksempel fra flytrafikkontrollen viser han hvordan feil sjelden skyldes én enkelt person, men snarere er et resultat av systemiske problemer.
- Retrospektiver bør ha som mål å forbedre systemet for å forhindre feil, i stedet for å plassere skyld.
- Tankegangen under retrospektiver bør være samarbeidende, med fokus på hvordan systemet kan gjøres bedre for alle.
- Målet bør være kontinuerlig forbedring, slik at belastningen ikke hver gang et problem oppstår, utelukkende faller på produktlederen.
Et viktig aspekt ved å gjennomføre et retrospektiv er å sørge for at det forblir uten skyldplassering, med fokus på systemet og ikke menneskene.
Clement Kao
- Personlige og organisatoriske casestudier om rolleavklaring [11:15]
- Clement deler en personlig historie om en gang han påtok seg for mange oppgaver innen produktdrift, noe som hindret teamets vekst.
- I utgangspunktet følte han at det var hans plikt som produktleder å sørge for produktets suksess, men senere innså han at han undergravde kollegenes arbeid ved å ikke delegere oppgaver.
- Lederen hans grep inn og hjalp ham med å innse behovet for å delegere ansvar til andre teammedlemmer for å sikre skalerbarhet og langsiktig suksess.
- Viktige faktorer i den vellykkede korrigeringen var støtte fra ledelsen, å omformulere ansvar som muligheter for eierskap og regelmessige oppfølgingssamtaler for å sikre en smidig overgang.
- Erfaringen lærte Clement hvor viktig det er å dele ansvar og gi kollegene myndighet til å ta eierskap til oppgavene sine.
- Clement deler også en nylig casestudie fra en stor organisasjon der produktteamet gikk fra løsningsarkitektur til produktledelse.
- I utgangspunktet slet teamet, som hovedsakelig besto av tidligere løsningsarkitekter, med å skille rollene fra hverandre, noe som førte til overlapp og forvirring.
- Produktteamet påtok seg utilsiktet oppgaver innen løsningsarkitektur, noe som hindret skalerbarhet og langsiktig suksess.
- Gjennom flere kontaktpunkter og diskusjoner samordnet teamet rollene sine på nytt og tydeliggjorde at produktledere fokuserer på den sentrale produktutviklingen, mens løsningsarkitekter håndterer kundespesifikke løsninger.
- Teamets åpenhet for tilbakemeldinger og vilje til å redefinere samarbeidet tidlig bidro til suksessen.
- Denne proaktive tilnærmingen forhindret langsiktige problemer og sørget for at hvert teammedlem hadde eierskap til oppgaver som var relevante for rollen deres, noe som fremmet skalerbarhet og effektivitet.
- Clement deler en personlig historie om en gang han påtok seg for mange oppgaver innen produktdrift, noe som hindret teamets vekst.
- Tankesett og modenhet: Å navigere i organisatorisk vekst [21:46]
- Vurder arbeidsmengden din regelmessig for å identifisere oppgaver som ikke er i tråd med det sentrale produktansvaret. Erkjenn følelser av å være overveldet eller å ha hodet over vannet, noe som kan tyde på manglende samsvar i forventningene til rollen.
- Informer lederen din om oppgaver som tar tid, men som ikke er knyttet til det sentrale produktansvaret. Presenter data om tidsfordelingen og årsakene til ubalansen i arbeidsmengden. Ledere har nytte av å forstå manglende samsvar, fordi det hjelper dem med å nå teamets mål på en effektiv måte.
- Samarbeid med lederen din for å identifisere oppgaver som passer bedre for andre team. Forklar hvorfor enkelte oppgaver bør overføres, og hvordan dette bidrar til organisatorisk skalerbarhet. Ta initiativ til samtaler med relevante team for å legge til rette for overføring av ansvar.
- Sørg for en smidig overføring av oppgaver til de riktige teamene. Gi nødvendig kontekst og støtte til de nye teamene som overtar ansvaret. Følg jevnlig opp for å sikre en vellykket integrering og håndtere eventuelle problemer som oppstår.
- Oppnå et tydeligere fokus på det sentrale produktansvaret, noe som fører til mer betydningsfulle resultater. Få mer tid til å engasjere deg grundig i kunder, design, utvikling og forretningsstrategier. Opplev et klarere sinn og bedre produktivitet ved å delegere oppgaver som ikke er sentrale, på en effektiv måte.
- Sett av tid spesielt til å utforme strategier og planlegge en bærekraftig arbeidsmengde. Ta i bruk en tilnærming med to roller, der den ene rollen er dedikert til å utføre oppgaver, og den andre til å utforme strategier og planlegge. Erkjenn betydningen av personlige interessentbehov for å fremme effektiv produktledelse.
Møt gjesten vår
Clement Kao er grunnlegger av Product Teacher, et selskap som tilbyr opplæring i produktledelse og utvikler produktkompetanse gjennom bedriftsinterne opplæringsworkshoper, videokurs på forespørsel og ledercoaching. Før han grunnla Product Teacher, lanserte Clement mer enn 10 produkter til flere millioner dollar som produktsjef for en gruppe i flere selskaper, og bidro til vellykkede salg og børsnoteringer verdt milliarder av dollar samlet sett. Clements tekster har blitt publisert på Amplitude, Mixpanel, Gainsight og andre ledende publikasjoner.
Noe produktledere ofte glemmer, er at de selv er kritiske interessenter og ikke kan forsømme dette aspektet når de utfører rollene sine.
Clement Kao
Ressurser fra denne episoden:
- Abonner på nyhetsbrevet til The CPO Club
- Ta kontakt med Clement på LinkedIn
- Se nærmere på Product Teacher
Relaterte artikler og podkaster:
Les transkripsjonen:
Vi prøver ut et dataprogram for å transkribere podkastene våre. Tilgi eventuelle skrivefeil, siden roboten ikke er korrekt 100 % av tiden.
Hannah Clark: Før vi setter i gang, vil jeg presisere nøyaktig hva jeg mener med helter innen produktledelse. Jeg snakker ikke om tankeledere som Marty Cagan eller Lenny Rachitsky, jeg snakker om DEG. Jeg snakker om personen produktteamet ditt støtter seg på for å redde dagen når noe begynner å brenne. Jeg snakker om helten som bærer mange hatter, men aldri en kappe. Jeg snakker om grunnen til at du ikke ser ut til å kunne jobbe mindre enn 50 timer i uken, samtidig som du fortsatt føler at du ikke har kommet lenger enn du var uken før.
Og hvis dette høres ut som deg, har vi gode nyheter – dagens gjest er Clement Kao, grunnlegger av Product Teacher. Etter å ha veiledet produktledere i alle typer miljøer, fra nystartede selskaper i tidlig fase til Fortune 500-selskaper, har han sett mye forskjellig når det gjelder dynamikken i produktteam, inkludert mange team som trengte alvorlig redningsarbeid.
Vi skal diskutere hvorfor det å være helten i et produktteam i seg selv kan være farlig. Og hvis dette treffer deg, bør du følge med helt til slutten for å finne ut hvordan du kan få den overmenneskelige styrken som skal til for endelig å snu situasjonen. La oss sette i gang.
Velkommen tilbake til podkasten for produktledere. I dag sitter jeg sammen med Clement Kao. Han er grunnleggeren av Product Teacher.
Clement, tusen takk for at du blir med oss i dag.
Clement Kao: Ja, tusen takk for invitasjonen.
Hannah Clark: Vi begynner som alltid. Kan du fortelle oss litt om bakgrunnen din og hva som førte til at du grunnla Product Teacher?
Clement Kao: Ja, veldig godt spørsmål. Jeg begynte faktisk ikke innen produktledelse da jeg var ferdig på universitetet.
Jeg begynte som en slags administrasjonskonsoll. Deretter ble jeg ved et uhell UX-forsker. Så ble jeg ved et uhell dataanalytiker. Og etter det ble jeg ved et uhell produktleder. Så jeg har en svært utradisjonell bakgrunn. Etter hvert som jeg fortsatte karrieren som produktleder – først som assisterende produktleder nederst på stigen, deretter som produktleder, senior produktleder, gruppeleder for produkt og ledende produktleder – la jeg merke til at mange andre slet på samme måte som jeg hadde gjort.
De hadde ikke nødvendigvis de riktige ressursene tilgjengelig. Hvordan håndterer man et bestemt problem? Hvordan arbeider man seg gjennom en konkret feil? Hva betyr alle disse ulike begrepene, og hvorfor er de viktige?
Etter hvert som jeg ble mer erfaren som individuell bidragsyter innen produktledelse, begynte jeg å spørre meg selv hvordan jeg kunne skape størst mulig effekt. Jeg innså at den største effekten jeg kunne ha, ikke nødvendigvis var å fortsette med produktledelse i ett enkelt selskap, men å hjelpe hundrevis, om ikke tusenvis, av andre produktledere med å lykkes når de først begynner som produktledere.
Det kan være en svært forvirrende overgang, og jeg ønsket også å hjelpe dem med å klatre videre. Derfor bestemte jeg meg for å grunnlegge Product Teacher. Product Teacher har hjulpet mer enn 7 000 produktledere med å lykkes i jobben, enten det handler om å komme inn i produktledelse for første gang, få en forfremmelse eller, som produktsjef, etablere produktstrategien og sørge for tydelige prosesser for alle medarbeiderne våre.
Det har vært en utrolig givende reise.
Hannah Clark: Fint. Og det høres ut som den mest bevisste delen av karrierereisen din, ikke den…
Clement Kao: Ja. Det var den ene tingen jeg ikke gjorde ved et uhell.
Hannah Clark: I dag skal vi utforske ideen om heltemot innen produktledelse, som du på mange måter har tatt avstand fra. For å være tydelig: Hva betyr dette i denne sammenhengen, og hvordan ser du at det kommer til uttrykk i organisasjonene du har arbeidet med?
Clement Kao: Det er et godt spørsmål. La meg presisere noe: Jeg sier ikke at heltemot alltid er negativt. En av kjerneoppgavene til en produktleder er at ansvaret til syvende og sist ligger hos deg.
Det er ditt ansvar å sørge for at produktet lykkes, og du må være villig til å ta i et tak når det er nødvendig. Det kan være at vi ikke har en person som arbeider med kvalitetssikring, men plutselig må sørge for at alt er godt testet før det settes i produksjon. Det kan være at designeren vår er syk, og at vi må få fremdrift slik at utviklerne kan komme videre.
Det kan også være at kundene våre har problemer med å forstå en del av produktet, og at du må ta rollen innen produktdrift for å rulle det ut og sørge for at folk lykkes. Uansett hva det gjelder, må produktlederen kunne tre inn.
Men kjerneproblemet jeg ofte ser med heltemot innen produktledelse, oppstår når dette blir noe du forventes å gjøre hele tiden, i stedet for noe du bare gjør når det dukker opp et svært uvanlig unntak.
En produktleder skal altså kunne tre inn og få ting til å skje når det er nødvendig, men bør ikke være personen som gjør alt hele tiden. Når folk sier at «denne produktlederen er virkelig en helt», betyr det ofte at produktlederen faktisk tar mange av arbeidsoppgavene fra andre kolleger for å få produktet til å fungere.
Det fører til at resten av organisasjonen svekkes. Folk utfører ikke nødvendigvis det som kreves fra et produktmarkedsføringsperspektiv, et produktanalyseperspektiv, et kundesuksessperspektiv eller et salgsperspektiv.
Alle disse områdene blir svakere og mindre gjentakbare når man bare er avhengig av én person som gjør alt. Jeg har sett dette rundt meg. Når produktlederen blir syk, tar ferie eller forlater organisasjonen, står alle andre i en svært vanskelig situasjon.
Produktledere bør selvsagt være villige til å ta ansvar når behovet oppstår. Men hvis behovet oppstår daglig eller ukentlig, er det sannsynligvis noe dypere som må håndteres.
Hannah Clark: Vi kan se for oss noen av de logiske konsekvensene av at en produktleder hele tiden befinner seg i en slik situasjon. Men hvorfor tror du at så mange produktledere fortsatt ender der?
Clement Kao: Jeg tror mange produktledere fortsetter å havne i denne posisjonen fordi arbeidet har endret seg over tid. Alle forventes å kunne håndtere mange ulike ting samtidig, på tvers av funksjoner.
Tidligere kunne man for eksempel ha én UX-designer som fokuserte på ett initiativ. Nå kan den samme personen støtte fem produkter. En forretningsanalytiker som tidligere fokuserte på ett kjerneinitiativ, kan nå støtte sju ulike team.
På grunn av denne organiseringen på tvers av team blir det mindre tydelig hvem som egentlig har ansvaret. Når noe går galt, er det uklart hvem som skal tre inn. Og når det er uklart, blir det som regel produktlederen som må gjøre det.
Hvis det var tydeligere hvem som skulle håndtere ulike situasjoner, ville ikke produktlederen trengt å tre inn. Men med fremveksten av teknologiske oppstartsbedrifter og mindre, mer selvstendige team finnes det ofte ikke tydelige retningslinjer for hvem som skal gjøre hva.
Hver gang noen sier «vi er ikke sikre på hvem som skal gjøre dette», blir det produktlederens jobb. Og når produktlederen har gjort det én gang og gjort det bra, oppstår det en selvforsterkende sirkel: Produktlederen gjorde det jo sist, og gjorde det bedre enn vi kunne ha gjort det. Hvorfor ikke bare la dem gjøre det igjen?
Jeg har sett produktledere ta over all analyse, all markedsundersøkelse, alle kundesamtaler, alle salgssamtaler og til og med avslutningen av salgene. Slik oppstår denne situasjonen stadig oftere.
Hannah Clark: Finnes det tidlige tegn på at en organisasjon ikke har gjort arbeidet som kreves for å beskytte produktlederne mot å måtte være helten, eller ikke har forberedt seg godt nok prosessmessig?
Clement Kao: En måte å tenke på det på er: Hvis du må tre inn én gang, er det helt greit og forventet. Men hvis du merker at du gjør det ofte – nesten hver måned, hver gang dere skal lansere noe eller hver gang det oppstår en feil – har det oppstått et mønster.
Hvis den samme typen hendelse skjer to ganger på rad, trenger dere sannsynligvis en dypere samtale. Organisasjoner som verdsetter etterarbeid, bør bruke etterarbeid for å undersøke hvorfor problemet oppsto. Organisasjoner som ikke gjør dette, bør innføre slike møter.
Hvis dere gjør dette første gang, bør problemet ideelt sett ikke gjenta seg andre gang. Hvis det skjer igjen, bør etterarbeidet undersøke hvorfor det har blitt et mønster. Slik kan man oppdage at produktfolk jevnlig gjør ting utenfor ansvarsområdet sitt, noe som ikke bør være målet.
Hannah Clark: Når det gjelder slike etterarbeidsmøter, høres dette ut som den lite sexy løsningen på et slikt problem.
Clement Kao: Det er veldig lite sexy.
Hannah Clark: Dessverre. Hvilken prosess bør en produktleder bruke for å gjennomføre et godt etterarbeid som får alle med på de nødvendige endringene?
Clement Kao: Det viktigste er at etterarbeidet er fritt for skyld, og at vi snakker om systemet, ikke menneskene. Vi ønsker ikke å gå gjennom alt og peke på hvem som var for opptatt eller hvem som ikke klarte å gjøre noe.
La oss si at en stor bedriftskunde er frustrert over produktopplevelsen. Produktlederen kan kode, mens programvareutviklerne på grunn av stramme tidsfrister ikke får gjort en liten tekstendring. Produktlederen skriver derfor koden selv, slår den sammen og setter den i produksjon.
Etterarbeidet bør ikke begynne med at utvikleren var så opptatt at produktlederen måtte gjøre jobben. Det bør heller spørre hvorfor kunden tok opp problemet for seks måneder siden uten at vi fulgte det opp. Hvorfor ventet vi til kunden var svært frustrert og nesten skulle si opp avtalen før produktlederen grep inn?
Vi må se på systemet. Det handler ikke om at en bestemt person unnlot å ta opp noe på et bestemt tidspunkt. Spørsmålet er hva vi som system og prosess kunne gjort bedre dersom den samme situasjonen oppsto igjen.
Jeg leste nylig om flygeledere. De skal sørge for at fly tar av og lander, og at det ikke skjer ulykker. Når en ulykke skjer, var flygelederen til stede, men det er ikke nødvendigvis 100 prosent vedkommendes skyld. Det finnes mange andre forhold som kan føre til at systemet får ett enkelt feilpunkt.
Vi ønsker ikke å gjøre én person til et enda tydeligere feilpunkt. Vi ønsker flere steder der vi kan bidra til å forhindre feilen tidligere. Ansvaret skal ikke bare ligge hos personen med tittelen produktleder.
Det viktigste tankesettet i ethvert etterarbeid er derfor: «Vi går gjennom dette sammen. Vi peker ikke på noen. Vi sier ikke at én bestemt person har skylden. Vi undersøker systemet. Hva var galt med systemet, og hvordan kan vi gjøre det litt bedre for alle neste gang?»
Dette kan være svært kraftfullt for å sikre at vi har de riktige støttefunksjonene og prosessene, slik at det ikke hver gang er produktlederen som må slå sammen kode eller hindre at en kunde avslutter forholdet.
Hannah Clark: Det gir mening. Man må nærmest rekonstruere problemet og finne løsningen derfra. Har du personlig sett organisasjoner lykkes med å håndtere et slikt problem?
Clement Kao: Ja. Jeg kan først fortelle om en erfaring fra meg selv. En gang endte jeg opp med å gjøre alt arbeidet innen produktdrift, selv om jeg ikke burde ha gjort det.
Vi lanserte et helt nytt produkt i en B2B-programvarevirksomhet. Siden jeg hadde gjennomført all kundeundersøkelsen og forsto kundenes problemer, sørget jeg også for produktnotater, opptak, demonstrasjoner og opplæring. Det fungerte da tre kunder brukte produktet. Men da vi nådde kunde nummer 70, innså jeg at jeg burde ha sagt fra mye tidligere.
Jeg burde ha sagt ved kunde nummer ti eller femten at det ikke var min jobb å gjennomføre hver eneste demonstrasjon og opplæring. Noen andre burde eie dette. Jeg tenkte at produktlederen hadde ansvaret for at produktet skulle lykkes, uansett hva som måtte til.
Men jeg tok samtidig fra kundesuksess- og produktmarkedsføringsteamene muligheten til å eie noe fra start til slutt og få en helhetlig forståelse av hva kundene opplevde. Jeg underminerte kollegene mine, selv om intensjonene mine var gode.
En fantastisk produktsjef påpekte at jeg var overbelastet og gjorde mye som egentlig ikke var mitt ansvar. Jeg svarte at ansvaret til syvende og sist lå hos meg. Han sa at jeg dermed hindret oss i å bygge et robust system for å støtte kundene på lang sikt.
Jeg kunne støtte én til ti kunder, men ikke 70, og vi ønsket å doble til 140 året etter. Da måtte vi fordele ansvaret.
Det første som gjorde forskjell, var støtte fra ledelsen i produktteamet. Hvis ledelsen bare sier «du må gjøre det», er det vanskelig å flytte ansvaret til riktig person. Det andre var hvordan vi formulerte endringen. Det handlet ikke om å gi noen mer kjedelig arbeid, men om å gi dem mer eierskap og muligheten til å kontrollere et område fra start til slutt.
Deretter fulgte vi jevnlig opp. Vi avtalte møter hver uke eller annenhver uke for å overføre informasjon, forklare hva jeg tidligere hadde gjort og sørge for en smidig overgang. Man kan ikke bare kaste ansvaret over en vegg og forvente at den andre personen vet hva som har skjedd.
Vi måtte forstå hvordan arbeidet hadde blitt gjort tidligere, og deretter gi de nye eierne frihet til å finne en bedre måte å gjøre det på.
Hannah Clark: Jeg liker hvordan du beskriver dette som å gi teamet tilbake handlekraft og dele arbeidsbelastningen. Har du et nyere eksempel?
Clement Kao: Ja, faktisk et pågående eksempel. Jeg arbeider med en stor organisasjon der produktteamet er relativt nytt. Mange av dem hadde tidligere arbeidet som løsningsarkitekter.
Organisasjonen hadde tidligere en IT-avdeling som spesialbygde løsninger for hver kunde. Det var ikke et skalerbart produkt. Ledelsen bestemte derfor at de trengte et produktteam, fordi de ulike kundeløsningene hadde mange fellestrekk.
Noen av løsningsarkitektene gikk over til produktsiden og skulle bidra til å bygge skalerbar teknologi i stedet for enkeltstående løsninger. Men fordi de hadde bakgrunn som løsningsarkitekter, fortsatte produktteamet å gjøre løsningsarkitektarbeid.
De begynte å bestemme hvordan kundene skulle konfigurere systemene og hvilke prosesser de skulle bruke. De faktiske løsningsarkitektene begynte å lure på hva deres rolle egentlig var.
Produktteamet ønsket å sikre at produktet ble tatt i bruk på en god måte, men de forsøkte også å løse alle andre deler av kundeøkosystemet. Det var feil. Løsningsarkitekten skulle undersøke kundens eksisterende systemer og finne ut hvordan alt skulle kobles sammen.
Produktteamet måtte fokusere på kjernen: å bygge en robust plattform. Da kunne løsningsarkitektene koble plattformen til kundens konkrete behov. Slik går man fra et én-til-én-forhold mellom én produktleder og én kunde til en én-til-mange-modell.
Det tok flere samtaler å få dette på plass. Produktlederne ønsket å gjøre en god jobb, men hvis de også tok over løsningsarkitektens ansvar, ville de ikke få tid til å utvikle neste byggestein som kunne hjelpe alle løsningsarkitektene.
Teamet fanget dette opp tidlig, før arbeidsmåten rakk å feste seg. Produktlederen eier produktet, og løsningsarkitekten eier løsningen. Det var en viktig og lærerik erfaring.
Hannah Clark: Jeg vil gjerne snakke mer om tankesett, men også om organisasjonens modenhet og hvordan den påvirker arbeidet. Når organisasjoner vokser, blir regler og prosesser mer kompliserte, og overbelastningen tar over. Man kan bli sittende fast i en situasjon som ikke er bærekraftig, men som føles som den eneste mulige.
Hva kan en person som allerede har bidratt til organisatorisk svekkelse, og som føler seg overveldet av ansvar de egentlig ikke eier, se frem til hvis vedkommende gjør arbeidet som kreves for å frigjøre seg? Og hvordan kan man argumentere for seg selv i en organisasjon som befinner seg på dette stadiet?
Clement Kao: Det første er å innse at du er overbelastet på en måte du ikke selv har valgt. Mange oppdager ikke dette fordi de er så overbelastet. Hvis du arbeider 70 eller 80 timer i uken, har du knapt tid til å tenke over om dette egentlig er produktledelse.
Sett av ti minutter i begynnelsen eller slutten av uken til å reflektere. Hvordan føler jeg meg med arbeidet jeg gjør? Er dette faktisk produktarbeid? Flytter jeg de riktige målene? Gjør jeg ting som ikke har høyest verdi, men som jeg av en eller annen grunn likevel må gjøre?
Produktlederens kjerneansvar er å forstå kundeproblemet, samarbeide med design og utvikling om hvordan det skal bygges, og samarbeide med virksomheten om utrullingen. Hvis du gjør mye annet, må du undersøke hvorfor.
Deretter må du få støtte fra lederen din. Ledere vet ofte ikke at du gjør alt dette, fordi de har egne mål og mange andre medarbeidere å følge opp. Når du sier at du bruker ti timer i uken på arbeid som ikke tilhører deg, kan lederen spørre hvorfor du ikke sa fra tidligere.
Dette hjelper også lederen med å nå sine mål, fordi dine mål delvis er lederens mål. Presenter hva du gjør, hvor mye tid det tar og hvorfor du tror du har endt opp med å gjøre det.
Deretter kan du sammen med andre team finne ut hva som egentlig hører hjemme hvor. Kanskje du lager alle UX-skissene selv, selv om dere har en designer. Kanskje du skriver tilfeldige SQL-spørringer, selv om dere har et analyseteam som kunne bygget et dashbord som automatiserte arbeidet.
Når du opptrer som helten, hindrer du organisasjonen i å skalere. Forklar hva du gjør, hvorfor du tror det tilhører et annet team, og hvordan det andre teamet kan skape bedre skalerbarhet, synlighet og integrasjon med resten av prosessene.
Når ansvaret er overført, følger dere opp først ofte og deretter sjeldnere. Sørg for at de nye eierne forstår konteksten, og at de er satt opp for å lykkes.
Det som finnes ved enden av tunnelen, er mer tid til selve produktarbeidet: å forstå kundene, samarbeide kreativt med design og utvikling, bygge produkter som er gode og skalerbare, skape lønnsomhet over tid og samarbeide med virksomheten om posisjonering, markedsstrategi og nye kundesegmenter.
Du får et klarere hode og kan fokusere på kjerneansvaret. Det er krevende, men svært verdifullt. Jeg har selv gått gjennom dette, og det gjorde at jeg kunne utvikle produkter med langt større effekt og forstå kundene mye bedre.
Et annet råd er å ikke nedprioritere deg selv. Produktledere ønsker ofte at andre skal lykkes, og bruker derfor all tiden sin på andre. Sett av tid til å planlegge hvordan du skal arbeide bærekraftig.
Jeg har hatt nytte av å dele meg selv i to. Den ene delen er Clement, produktlederen som utfører arbeidet. Den andre er en produktleder som krever at Clement lager en plan for å arbeide mer bærekraftig. For meg brukte jeg mellomnavnet Richard og sa: «Richard, produktsjefen, forventer at du lager en plan for bedre skalerbarhet.»
Da ble det en avtale i kalenderen for å gjennomgå planen. Det hjalp meg å komme ut av rollen som den som alltid bare utfører, og huske at jeg også eier strategien. Produktlederen selv er en viktig interessent og kan ikke neglisjeres.
Hannah Clark: Jeg liker ukonvensjonelle metoder, særlig noe som gjør det mulig å se sin egen verdi og sitt eget bidrag tydeligere. Det mest heroiske du kan gjøre i en organisasjon, er kanskje å myndiggjøre andre – og dermed også deg selv.
Clement, tusen takk for at du ble med oss. Dette har vært fantastisk. Hvor kan folk følge deg på nettet?
Clement Kao: Du finner meg på LinkedIn. Jeg er sannsynligvis den eneste Clement Kao. Du finner meg også på productteacher.com, uten mellomrom eller bindestreker. Det er hovedsakelig der jeg holder til og hjelper andre produktfolk med å lykkes.
Hannah Clark: Flott. Vi sees der.
Clement Kao: Takk for at jeg fikk være med.
Hannah Clark: Takk for at du lyttet. For flere gode perspektiver, veiledninger og verktøyanmeldelser kan du 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 henter podkastene dine.