Vi må snakke om produktsjefrollen!

Den produktorienterte modellen (POM) definerer tre akser

…og disse tre aksene er svært forskjellige: Den første er politisk, mens den andre er analytisk (du kan lese mer om modellen her). Den tredje aksen er utenfor scope for denne artikkelen.

Hva mener jeg med at den første aksen er politisk? Jo, det finnes ingen “matematisk fasit” på hva som er de rette problemene for en virksomhet å angripe. Man forsøker å svare på spørsmålet “hvilke problemer er det verdt å løse, nå?”. Å gå opp dette handler om å forstå hva virksomheten i stort forsøker å oppnå, samt hvilke kapabiliteter man rår over. Noen sentrale egenskaper:

• Man har en internalisert forståelse av virksomhetens verdier og posisjon i markedet
• Man evner å bruke data, innsikt og læring fra team
• Man har en god forståelse for toppmål og virksomhetsstrategi
• Man er flink til å håndtere nøkkelinteressenter. Man har en svært god evne til å navigere og håndtere det politiske landskapet
• Man har inngående kunnskap om folk og team på tvers (god oversikt over de totale ressursene man har tilgjengelig)

Å løse problemene, derimot, er noe helt annet. Gitt et definert problem vi skal løse, med tilhørende strategisk kontekst, så er det plutselig et langt mer analytisk arbeid vi har foran oss. Ja, det er i noen grad forankring her også, selvfølgelig, men av natur er ikke dette på langt nær like politisk som å prioritere hvilke problemer som skal løses her og nå.

Å finne de gode løsningene på problemene, gjøres ved hjelp av produktutforsking. Litt forenklet kan vi beskrive det som to steg:

1. Kartlegg mulighetsrommet, innenfor de rammene man har fått. Her bruker man gjerne Opportunity Solution Tree.
2. Vurder løsningsforslagene man finner fra steg 1 opp mot hverandre, og velg ut de man har størst tro på at vil gi verdi (dette blir da hva teamet skal lage).

Jeg kan ikke få fremhevet nok hvor kritisk det er å lykkes med produktutforsking. Alt annet innenfor produktorientering, handler om å gi teamet dette handlingsrommet. Den kanskje aller største forskjellen på å jobbe produktorientert sammenlignet med å jobbe i for eksempel et prosjekt, er at teamet selv skal finne løsningene. Men å utnytte dette handlingsrommet, å finne de gode løsningene, det er veldig vanskelig. Det er her vi ansvarliggjør produktlederen (som sammen med produktdesigneren og tech lead utgjør produkttrioen). Jeg var nylig på Y Oslo, hvor Teresa Torres holdt et foredrag. Hun er herlig konkret og tydelig, og et av hennes poeng omhandlet omfanget for produktutforsking:

Å prioritere de riktige problemene (akse 1 i POM) krever helt andre ferdigheter enn å finne løsningene på disse problemene (akse 2 i POM). Videre er arbeidet med å finne løsninger på problemene omfattende, og en produktleder har andre, teamnære oppgaver og forpliktelser som tar tid, også. Konklusjonen blir da at vi har et udekket behov på nivået over produktlederen, på nivået over hvert enkelt team.

Det er her produktsjefrollen kommer inn.

Produktsjefen er ansvarlig for at vi har motiverte folk, som jobber med de rette problemene

Det høres så enkelt ut, men det er likevel svært krevende. I tillegg er dette en helt ny rolle når man jobber produktorientert, som ikke har en naturlig 1:1-sammenligning med noen av rollene i en klassisk modell. Jeg skrev en lengre artikkel i juni om hvordan et målbilde for den produktorienterte modellen kan se ut. La oss se nærmere på akse 1 i POM fra den artikkelen, nemlig den som en produktsjef er ansvarlig for:

På den venstre siden ser vi noen kjente verktøy for å gi teamene den konteksten de trenger for å jobbe myndiggjort. En klassisk felle som mange går i, er å forsøke å implementere OKR på teamnivå, uten å gi teamene det de trenger for å bruke OKR på en meningsfull måte. Dette er et kritisk ansvar for produktsjefen: Dersom vi skal ha motiverte teammedlemmer som skjønner sin rolle i virksomheten, og som virkelig ønsker å bidra, så må vi destillere de høytsvevende virksomhetsmålene til noe som gir mening for dem. En produktvisjon skal gi eierskap, en produktstrategi skal gi kontekst, og mål for teamet skal tydeliggjøre hvilke problem teamet skal løse.

Netflix er kjent for mantraet lead with context, not control. Når vi snakker om produktteam, så er det å sette retning den konteksten teamet trenger. Syretesten på om du har lykkes med å skape den konteksten, er at teamet finner den matnyttig og hensiktsmessig, og føler på et økt eierskap til det de er satt til å løse. Videre er målene vi skal oppnå, som regel så omfattende at det må flere team til for å nå dem. Hvis man har 25 team, skal man da ha 25 produktstrategier, og 25 produktvisjoner? (jeg anbefaler å se videoen fra 29:00 → 34:40)

Ansvaret for å bygge denne konteksten ligger på nivået over teamene. Det handler om å se helhet. Dersom man skulle lagt dette ansvaret på produktlederne så ville man fått suboptimaliserende effekter (hvor man prioriterer ens eget team og ens egne interesser). I tillegg kommer utfordringene med kapasitet (produktledere skal prioritere produktutforsking, og dette er omfattende) og kompetanse (dette arbeidet krever helt andre ferdigheter).

Kompleksiteten i å jobbe med de rette problemene handler om langt mer enn hva ett team kan løse

En annen foredragsholder på Y Oslo var Petra Wille (som også gjorde en fantastisk figur). Hun har en veldig god analogi for produktsjefrollen sett opp mot produktlederrollen, nemlig skipsverftanalogien. Denne liker jeg godt, fordi den lar seg utbrodere på flere måter: En produktsjef er ansvarlig for at verftet fungerer helhetlig, at man lager skip som løser de problemene verftet er satt til å løse, og at disponeringen av ressurser er i tråd med de prioriteringene som verftet har gjort. Produktlederne er ansvarlig for å faktisk bygge skipene, herunder finne ut hvordan skipene skal se ut (= produktutforsking).

Basert på dette forstår vi hvor sentral produktsjefrollen er på tvers av team, og hvordan ansvaret er ganske annerledes fra en produktleders ansvar.

Det digitale landskapet er komplekst i de aller fleste moderne virksomheter. Gitt denne kompleksiteten trenger vi en struktur som skalerer, og vi trenger en tilnærming som ser systematisk på hvordan vi skal fordele ansvar og utøve ledelse. Wille sier det veldig fint i artikkelen jeg lenket over:

Jeg er overbevist om at man må mestre produktsjefrollen, for å lykkes med produktorientering

Min erfaring er at det er krevende nok å bygge gode produktledere som skal lykkes med det teamnære. Å legge et ytterligere ansvar på dem for det som går over og på tvers av team, og forvente at de skal levere på dette i tillegg, fremstår urealistisk for meg.

I Transformedbeskriver Marty Cagan hva han og hans kollegaer ser at går igjen på tvers hos virksomheter som lykkes med produktorientering. Det er verdt å merke seg at dette er verdens aller, aller beste virksomheter, innenfor sine respektive områder. Formodentlig har de også noen av verdens skarpeste hjerner hos seg, med høy arbeidskapasitet. Når disse virksomhetene gjennomgående satser på produktsjefrollen, i tillegg til produktledere, så mener jeg at man skal tenke seg særdeles godt om, før man legger alt på produktlederne i stedet.

I Norge er min oppfatning at den vanligste måten å operasjonalisere produktsjefrollen på, er å innrette produktområder med en tilhørende produktområdeleder. En fallgruve ved dette, som er utenfor scopet for denne artikkelen, er at det fort kan bli en administratorrolle. Jeg vil derfor advare mot å automatisk sette likhetstegn mellom disse. For et lite selskap vil det sannsynligvis være naturlig at en Chief Product Officer (CPO) utøver produktsjefrollen.

Produktsjefrollen handler om hva du gjør, ikke hvilken tittel du har.