Bör det finnas hjältar inom produktledning?

Läs transkriberingen:

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

Hannah Clark: Innan vi börjar vill jag förtydliga exakt vad jag menar med hjältar inom produktledning. Jag pratar inte om opinionsledare som Marty Cagan eller Lenny Rachitski, utan om DIG. Jag pratar om personen som produktteamet lutar sig mot för att rädda dagen när något börjar brinna. Jag pratar om hjälten som bär många hattar, men aldrig en mantel. Jag pratar om anledningen till att du inte verkar kunna arbeta mindre än 50 timmar i veckan och ändå känner att du inte har kommit längre än veckan innan.

Och om det låter som du är dagens gäst goda nyheter: Clement Kao, grundare av Product Teacher. Efter att ha coachat produktchefer i alla möjliga miljöer, från nystartade företag i tidiga skeden till Fortune 500-företag, har han sett många olika dynamiker i produktteam, inklusive gott om sådana som behövde räddas på allvar.

Vi ska diskutera varför det är farligt att vara hjälten i ett produktteam. Och om det känns bekant, stanna kvar till slutet för att få veta hur du kan få den övermänskliga styrkan att äntligen vända utvecklingen. Då börjar vi.

Välkommen tillbaka till podden för produktchefer. I dag sitter jag tillsammans med Clement Kao. Han är grundare av Product Teacher.

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

Clement Kao: Ja, tack så mycket för att jag fick komma.

Hannah Clark: Vi börjar som vi alltid börjar. Kan du berätta lite om din bakgrund och vad som ledde dig till att grunda Product Teacher?

Clement Kao: Ja, det är en fantastisk fråga. Jag började faktiskt inte inom produktledning direkt efter universitetet.

Jag började faktiskt som en administrativ konsol. Sedan blev jag av misstag UX-forskare. Därefter blev jag av misstag dataanalytiker. Och sedan blev jag av misstag produktchef. Så jag har en mycket otraditionell bakgrund. När jag fortsatte att utvecklas i min karriär som produktchef började jag som assisterande produktchef längst ner på stegen och arbetade mig sedan upp till produktchef, senior produktchef, gruppchef för produkt och slutligen huvudansvarig produktchef.

En sak jag lade märke till var att många andra kämpade på samma sätt som jag hade gjort. De hade inte nödvändigtvis rätt resurser till hands. Hur tar man itu med just det här problemet? Hur arbetar man sig igenom just det här misstaget? Vad betyder alla dessa olika begrepp och varför spelar de någon roll?

När jag blev allt mer senior i min karriär som produktchef och individuell medarbetare började jag därför fråga mig själv hur jag kunde skapa största möjliga påverkan. Jag insåg att den största påverkan jag kunde skapa inte nödvändigtvis var att fortsätta arbeta med produktledning inom ett företag, utan att hjälpa hundratals, om inte tusentals, andra produktchefer att lyckas när de blev produktchefer för första gången.

Det kan vara en mycket förvirrande övergång, och därefter kan man hjälpa dem att klättra i organisationen. Det var därför jag bestämde mig för att grunda Product Teacher. Product Teacher har hjälpt mer än 7 000 produktchefer att verkligen lyckas i arbetet, oavsett om det handlar om att ta sig in i produktområdet för första gången, få en befordran eller som produktchef sätta produktstrategin och se till att vi har tydliga processer för alla våra kollegor och så vidare.

Det har varit en otroligt givande resa.

Hannah Clark: Trevligt. Och det låter som den mest avsiktliga delen av din karriärresa, inte den…

Clement Kao: Ja. Det var den enda sak jag inte gjorde av misstag. Ja.

Hannah Clark: I dag ska vi utforska idén om hjältemod inom produktledning, något som du delvis har tagit ställning mot. För att vara tydlig: vad betyder det i det här sammanhanget och hur ser du att det tar sig uttryck i organisationer som du har arbetat med?

Clement Kao: Det är en fantastisk fråga. Något behöver förtydligas: jag säger inte att hjältemod alltid är något dåligt. En av kärnuppgifterna för en produktchef är att ansvaret stannar hos dig.

Det är ditt ansvar att se till att produkten lyckas, och du måste vara beredd att kavla upp ärmarna för det som behövs. Om vi inte har någon kvalitetssäkringsperson och plötsligt måste se till att allt är ordentligt testat innan det går i produktion, behöver du kliva in. Om designern är sjuk och vi verkligen måste få arbetet att röra sig framåt för att frigöra våra utvecklare, behöver du kliva in.

Om kunderna har svårt att förstå en del av produkten och du behöver ta rollen inom produktdrift för att få den lanserad och se till att människor lyckas, behöver du kliva in. Vad det än gäller måste produktchefen kunna hjälpa till. Men kärnproblemet med hjältemod inom produktledning uppstår när det används som något du förväntas göra hela tiden, i stället för något du endast gör när ett verkligt undantag plötsligt uppstår.

För att vara tydlig bör en produktchef kunna kliva in och få saker att hända när det behövs, men personen ska inte vara den som gör allt hela tiden. När människor säger att en produktchef är en sådan hjälte tar de ofta i själva verket över många av arbetsuppgifterna från andra kollegor för att få produkten att fungera.

Det gör att resten av organisationen försvagas. Människor utför inte längre det som behövs ur ett produktmarknadsföringsperspektiv, produktanalytiskt perspektiv, kundframgångsperspektiv eller försäljningsperspektiv. Alla dessa olika områden blir svagare och mindre repeterbara när man förlitar sig på att en enda person ska göra allt.

Jag har själv sett detta omkring mig. När produktchefen blir sjuk, åker på semester eller lämnar organisationen befinner sig alla i ett mycket dåligt läge.

Produktchefer ska självklart vara villiga att ta ansvar när behovet uppstår. Men om behovet uppstår dagligen eller varje vecka finns det sannolikt ett djupare problem som behöver hanteras.

Hannah Clark: Ja, och vi kan föreställa oss några av de logiska konsekvenserna av att en produktchef hela tiden befinner sig i en sådan position. Men varför tror du att så många produktchefer fortfarande befinner sig där?

Clement Kao: Jag tror att produktchefer ofta fortsätter att befinna sig i den positionen eftersom arbetet har förändrats över tid. Alla förväntas hantera många olika saker hela tiden och arbetar tvärfunktionellt över flera områden.

Tidigare kanske man hade en UX-designer som fokuserade på ett initiativ. Nu kanske samma person stöder fem produktteam. Någon som tidigare bara behövde fokusera på en central uppsättning initiativ kanske nu stöder sju olika team.

På grund av detta blir det mycket otydligare vem som ska ta ansvar. När något går fel är det inte klart vem som ska kliva in. Och eftersom det inte är klart behöver produktchefen som standard kliva in.

Om det fanns större tydlighet kring vem som ska göra vad i olika situationer skulle produktchefen inte behöva kliva in. Men med framväxten av teknikföretag och mindre, mer självständiga team finns det ibland inga tydliga riktlinjer.

Då blir det så att när vi inte vet vem som ska göra något är det produktchefens jobb. Och så fort produktchefen har gjort det en gång uppstår en självförstärkande loop: produktchefen gjorde det tidigare och gjorde det mycket bra, så varför låter vi inte produktchefen göra det igen nästa gång?

Jag har sett produktchefer ta över all analys permanent, all marknadsundersökning och alla kundsamtal, alla försäljningssamtal och avslut. Situationen uppstår eftersom de gjorde det bättre än andra och därför förväntas fortsätta göra det.

Hannah Clark: Finns det några tidiga tecken på att en organisation inte har gjort det arbete som krävs för att skydda sina produktchefer från att behöva vara hjälten, eller inte har förberett sig tillräckligt processmässigt?

Clement Kao: Ett sätt att tänka på det är att man märker det när det händer. Om du behöver kliva in en gång är det helt okej och helt förväntat. Men om du märker att du gör det ofta, nästan varje månad, varje gång något ska lanseras eller varje gång det uppstår ett fel, finns det ett mönster.

Om samma sak händer två gånger i rad behöver ni sannolikt ha ett djupare samtal. Om organisationen värdesätter efterhandsanalyser bör ni använda dem. Om den inte gör det bör du införa dem genom att diskutera varför problemet uppstod.

Om ni gör detta första gången bör problemet helst inte upprepas andra gången. Om det ändå händer igen måste efterhandsanalysen ta upp varför det finns ett mönster. På så sätt kan ni upptäcka när produktpersoner regelbundet gör saker utanför sitt ansvarsområde, vilket inte är vad vi vill.

Hannah Clark: När det gäller att genomföra sådana efterhandsanalyser låter det som en ganska osexig lösning.

Clement Kao: Den är mycket osexig.

Hannah Clark: Tyvärr. Vilken process bör en produktchef använda för att genomföra en ordentlig efterhandsanalys som får alla att stödja de förändringar som krävs för att lösa en sådan situation?

Clement Kao: Det är mycket viktigt att efterhandsanalysen är skuldfri och att vi pratar om systemet, inte om människorna. Vi vill inte säga att en viss person misslyckades. Vi vill undersöka varför systemet tillät situationen att uppstå.

Anta att en företagskund är mycket frustrerad över hur produktupplevelsen fungerar. Produktchefen kan skriva kod och de andra utvecklarna har på grund av hårda tidsplaner inte möjlighet att genomföra en textändring. Produktchefen skriver därför koden, sammanfogar den och får ut den i produktion.

Efterhandsanalysen ska inte börja med att säga att utvecklaren var för upptagen. Den bör i stället fråga varför kunden tog upp problemet för sex månader sedan utan att vi uppmärksammade det bättre, och varför vi väntade tills kunden var mycket frustrerad och nästan skulle säga upp avtalet innan produktchefen ingrep.

Vi behöver ta ett steg tillbaka och fråga ur systemets perspektiv vad vi kunde ha gjort bättre nästa gång som system och process.

Jag läste nyligen om flygtrafikledning. Flygledarens uppgift är att se till att flygplan lyfter och landar utan olyckor. När en olycka inträffar var flygledaren där, men det är inte till 100 procent flygledarens fel. Det finns många andra kedjande faktorer som kan skapa en enda felpunkt.

Vi vill inte att en enda person ska vara den enda felpunkten. Vi vill ha många olika platser där vi kan förebygga felet tidigare. Det handlar inte bara om personen som har titeln produktchef.

Den viktigaste inställningen i varje efterhandsanalys är att vi går igenom detta tillsammans. Vi pekar inte ut någon. Vi säger inte att en viss person bär skulden. Vi granskar systemet och frågar hur vi kan göra det bättre för alla nästa gång.

Det kan vara mycket kraftfullt för att skapa rätt stödjande roller och processer, så att det inte alltid är produktchefen som måste sammanfoga kod eller hindra en kund från att lämna.

Hannah Clark: Det låter rimligt. Man behöver bakåt konstruera problemet och sedan hitta lösningen utifrån den utgångspunkten. Har du personligen sett organisationer lyckas lösa ett sådant problem?

Clement Kao: Ja. Jag berättar först om mig själv. En gång blev jag personen som gjorde allt arbete inom produktdrift, trots att jag inte borde ha gjort det.

För en produkt som jag ansvarade för inom B2B-programvara lanserade vi en helt ny produkt som låg nära vår befintliga produkt. Eftersom jag redan hade genomfört all kundresearch förstod jag kundernas problem. Jag såg till att vi hade rätt lanseringsanteckningar och inspelningar och att kunderna kunde lyckas med att konfigurera och använda produkten.

Det fungerade när vi bara hade tre kunder. Men när vi nådde kund nummer 70 hade jag gjort ett dåligt jobb genom att inte tidigare säga att det inte var mitt jobb att genomföra varje demonstration och utbildning. Det borde någon annan ha ägt.

Jag tänkte att det var mitt jobb eftersom jag var produktchef och behövde se till att produkten lyckades, oavsett vad. Men jag tog samtidigt bort möjligheten för kundframgångs- och produktmarknadsföringsteamen att få en helhetsbild av vad kunderna upplevde.

Jag hoppade in och gjorde allt eftersom jag tänkte att det bara var en gång till. Även om mina avsikter var goda underminerade jag mina kollegor. Jag gav dem aldrig möjlighet att äga något från början till slut.

Min chef uppmärksammade att jag höll på att drunkna i arbete och gjorde saker som egentligen inte tillhörde mig. Jag svarade att ansvaret stannade hos mig. Han sa att jag därigenom hindrade oss från att bygga ett robust system för att stödja kunderna på lång sikt.

Vi kunde stödja tio kunder, men vid 70 var systemet redan överbelastat, samtidigt som vi ville fördubbla antalet året därpå. Då samlade vi de berörda personerna och diskuterade vem som skulle äga vad.

Det viktiga var att ledningen stödde förändringen och tydligt visade att produktchefen inte skulle göra allt. Dessutom behövde vi rama in förändringen som mer ägarskap, inte mer arbete. Vi gav människor möjlighet att kontrollera ett område från början till slut.

Efter att ansvaret hade delegerats följde vi regelbundet upp hur det gick, vilken information som behövde överföras och vilka saker jag tidigare hade gjort som de nu skulle ta över. Vi ville inte bara kasta ansvaret över en mur utan hjälpa dem att lyckas.

Hannah Clark: Jag tycker om hur du beskriver det som att ge teamet tillbaka sin handlingskraft och dela på arbetsbelastningen. Har du något annat exempel?

Clement Kao: Ja, ett mycket aktuellt exempel. Jag arbetar just nu med en stor organisation där produktteamet är relativt nytt. Tidigare hade många av dem arbetat som lösningsarkitekter.

Organisationen brukade specialbygga lösningar för enskilda kunder, vilket inte var skalbart. Ledningen bestämde därför att skapa ett produktteam som kunde bygga robusta och skalbara produkter med gemensamma funktioner.

Eftersom de nya produktcheferna tidigare varit lösningsarkitekter fortsatte de ibland att göra lösningsarkitektarbete. De försökte hjälpa kunderna att konfigurera processer och system, medan lösningsarkitekterna undrade vad deras egen roll egentligen var.

Produktteamets ansvar borde vara att bygga den skalbara produktkärnan. Lösningsarkitekterna bör sedan anpassa och koppla produkten till kundens övriga system. På så sätt går man från en relation mellan en produktchef och en kund till en modell där en produktchef kan stödja många kunder.

Det krävde flera samtal, men teamet förstod snabbt att produktchefen äger produkten och lösningsarkitekten äger lösningen. Det var bra att upptäcka problemet tidigt, innan arbetssättet hann stelna.

Hannah Clark: Jag vill tala lite mer om tankesätt och om organisationens mognad och hur det påverkar arbetet. När organisationer blir mer mogna blir roller och processer ofta mer komplicerade och känslan av att vara överväldigad tar över. Man fastnar i en situation som inte känns hållbar men ändå känns som den enda möjliga.

Hur kan någon som redan har bidragit till att organisationen försvagats och som känner sig överväldigad av ansvar frigöra sig? Hur förespråkar man sig själv i en organisation som befinner sig i det stadiet?

Clement Kao: Det första steget är att inse att du håller på att drunkna i arbete som du inte har åtagit dig. Den insikten kanske inte ens uppstår eftersom du arbetar 70 eller 80 timmar i veckan och inte har tid att tänka.

Ta tio minuter i början eller slutet av veckan för att reflektera: Hur känner jag inför arbetet jag gör? Är det jag gör faktiskt produktarbete? Flyttar jag de måtttal jag ska påverka? Finns det sådant jag gör som inte har högt värde men som ändå har blivit mitt ansvar?

Det andra steget är att få med sig sin chef. Chefer vet ofta inte att du gör allt detta, eftersom de själva har egna måtttal och andra medarbetare att leda. När du berättar att du lägger tio timmar i veckan på uppgifter som inte tillhör dig hjälper du chefen att bli mer effektiv.

Beskriv vad du gör, hur mycket tid det tar och varför du tror att du hamnat i situationen. Därefter kan du och chefen arbeta med andra team för att hitta rätt ägare.

Om du gör alla dessa tillfälliga SQL-frågor kanske analysteamet kan bygga en instrumentpanel som automatiserar arbetet. Om du gör all design trots att det finns en designer bör designern äga den uppgiften.

När ansvaret har flyttats ska ni först följa upp ofta och sedan minska uppföljningen. Se till att de nya ägarna förstår sammanhanget och är rustade för att lyckas.

Vad finns då i slutet av tunneln? Du får tillbaka tiden du borde ha haft från början för att fokusera på kärnan i produktarbetet: förstå kunderna, samarbeta kreativt med design och utveckling, bygga skalbara och uppskattade produkter och arbeta med verksamheten kring positionering och strategi.

Jag vill också ge ett närliggande råd. Produktchefer vill ofta att andra ska lyckas och prioriterar därför bort sig själva. Dela i stället upp dig själv i två roller. Det finns Clement produktchefen som utför arbetet, men också Clement produktledaren som kräver en plan för att arbeta hållbart.

För mig fick den andra rollen namnet Richard, efter mitt mellannamn. Richard, produktchefen, förväntar sig att du nästa vecka har en plan för att arbeta mer skalbart. Det gjorde det lättare att avsätta tid för strategin.

Produktchefer glömmer ofta att de själva är en viktig intressent. De får inte försumma denna intressent medan de utför produktarbetet.

Hannah Clark: Jag älskar okonventionella metoder, särskilt sådana som hjälper dig att synliggöra ditt eget värde och ditt bidrag till teamet. Det mest hjältemodiga du kan göra i en organisation är att stärka andra människor och därigenom även dig själv.

Clement, stort tack för att du var med oss. Det här har varit fantastiskt. Var kan människor följa dig på nätet?

Clement Kao: Du hittar mig alltid på LinkedIn. Jag är förmodligen den enda Clement Kao. Du hittar mig också på productteacher.com, utan mellanslag och utan bindestreck. Det är främst där jag arbetar och hjälper andra produktpersoner att lyckas.

Hannah Clark: Fantastiskt. Vi ses där.

Clement Kao: Tack för att jag fick vara med.

Hannah Clark: Tack för att du lyssnade. För fler 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, var du än lyssnar på poddar.