Har du en produktorientert modell?

Et viktig mål med produktorientering er å få myndiggjorte teknologer

Mange virksomheter ønsker å bli kundeorienterte. «Vi skal sette kunden i fokus» er et mantra de fleste av oss har hørt. I praksis viser dette seg å være mer krevende enn antatt: Måten vi har rigget oss på gjør at vi gjentatte ganger sub-optimaliserer på en måte som ikke kommer kunden til gode. Typisk er vi omgitt av komplekse verdikjeder og store, digitale porteføljer. I sum kan det virke som om denne konteksten gjør det umulig å få et kundefokus.

I digitaliseringens spede barndom var det mange prosjekter som hadde åpenbar verdi, både for kundene og virksomheten. Tenk eksempelvis på den første gangen du kunne logge inn i en nettbank, heller enn å dukke opp i skranken. Offentlige selvbetjeningsløsninger er en annen klassiker. Når den digitale porteføljen var såpass umoden, var det enkelt å finne de løsningene som ville gi stor verdi. En rimelig antakelse er at porteføljen vokser proporsjonalt med tid (se Figur 1). Ettersom porteføljen vokser, blir det vanskeligere å finne løsninger som gir verdi (se Figur 2). Dette handler blant annet om at man tar de åpenbare gevinstene først, samt at kompleksiteten i porteføljen og bruksmønstrene øker.

Siden porteføljen vokser med tiden, kan vi bytte ut porteføljestørrelse med tid (Figur 3).

Ergo: Jo mer moden porteføljen med digitale produkter er, jo vanskeligere er det å finne løsninger som gir stor verdi. Jeg tror at mange norske virksomheter har krysset en terskelverdi, og opplever at dette begynner å smerte skikkelig. Fremgangsmåten de har benyttet for digital produktutvikling så langt strekker ikke til, fordi porteføljene har blitt for store.

Hva kan vi gjøre med dette? Vi må flytte beslutningsmyndigheten ned til operativt nivå, til de som kjenner produktene best:

- Marty Cagan, Transformed (min fremheving)

For moderne, digitale porteføljer med komplekse verdikjeder, er det svært krevende å finne de løsningene som gir mest verdi. Teamene som jobber med dette daglig, er best posisjonert for å finne de verdifulle løsningene. Spesielt teknologene er sentrale: De kjenner det tekniske mulighetsrommet best, og fanger kundens bruk i sanntid. Dette kan de agere på kontinuerlig, og hele tiden vurdere kost/nytte for nye idéer. Produktorientering handler dermed i et nøtteskall om å gi dem verktøyene og støtten for å lykkes med dette. Dette gir den beste innovasjonen, og følgelig de produktene som gir mest verdi for både kundene og virksomheten.

Vi kan visualisere en modell for produktorientering med tre spørsmål

La oss starte med blanke ark, og tenke på hvordan en virksomhet tilnærmer seg digital produktutvikling. Vi kan formulere utfordringene som tre spørsmål, som virksomheten skal svare ut.

Et produkt skal løse et problem, eller utnytte en mulighet. Det første spørsmålet blir da: Hvordan prioriterer virksomheten hvilke problemer man skal løse? Det påfølgende spørsmålet blir videre: Hvordan løser vi disse problemene? Avslutningsvis får vi spørsmålet: Hvordan bygger vi løsningene på disse problemene?

Hvordan prioriterer man hvilke problemer som skal løses?

Dette spørsmålet er langt større enn det umiddelbart ser ut som. Finansiering og bemanning er vesentlige faktorer i denne prioriteringen. La oss ta et enkelt eksempel: Du har fem team, som jobber med å løse fem forskjellige problemer. Det kommer et budsjettkutt på 20%, og etter tett dialog med teamene kommer du frem til at det ikke kan kuttes «litt overalt». Et helt team må avvikles. De fire teamene du står igjen med, representerer en implisitt prioritering av hvilke problemer du ønsker å løse.

I den produktorienterte modellen rapporterer ikke teamene på oppgaveprogresjon. De rapporterer på effekt og måloppnåelse, på en måte som er forståelig for beslutningstakerne som rår over finansiering og bemanning. Dersom samtlige team gjør dette, kan man legge til grunn en eksplisitt sammenligning av hva som tilfører virksomheten mest verdi. For å prioritere problemer i den produktorienterte modellen trenger man gode produktstrategier med en tydelig kommunisert retning, samt myndiggjorte og målstyrte team.

Hvordan løser man de problemene som er prioritert?

En svært sentral rolle i et produktteam er produktlederen. Hele essensen med denne rollen, slik jeg ser det, er inversion of control: En god produktleder har en proaktiv dialog med samtlige nøkkelinteressenter. I en klassisk modell er nøkkelinteressentene direkte involvert, eksempelvis som medlemmer av en styringsgruppe for et prosjekt. En dyktig produktleder i den produktorienterte modellen ivaretar derimot deres interesser uten at de trenger å være direkte involvert. Dette er en kritisk faktor for at de skal gi fra seg beslutningsmyndighet og mandat til produktteamet.

Videre er teamet som helhet, med produkttrioen (product trio) i spissen, ansvarlig for å finne de gode løsningene. Denne prosessen er kjent som product discovery, og dette er en kontinuerlig aktivitet. I tråd med at det blir vanskeligere å finne gode løsninger som gir verdi når den digitale porteføljen vokser, ser vi behovet for å sette av godt med kapasitet i teamet til å jobbe med product discovery. Dersom dette nedprioriteres, vil de resulterende løsningene ikke bli like gode.

Hvordan bygger man løsningene på problemene?

For å kunne tilpasse produktet til de behovene og bruksmønstrene man ser, må man kunne snu seg raskt. Nøkkelordene her er smidig modenhet, kontinuerlig leveranse og hyppige eksperimenter. I et erfaringsutvekslingsmøte jeg deltok i nylig, var det en deltaker som kommenterte: «For noen år siden så kalte vi jo dette smidig!». Det er en skarp (og korrekt!) observasjon, og de gode nyhetene er at her har vi en haug av erfaringer, litteratur og modeller å basere arbeidet vårt på. Personlig mener jeg at Accelerate er den beste fagboken som er skrevet for vårt fagfelt: Forfatterne er svært tydelige på nøyaktig hva man bør gjøre for å bli bedre til å bygge digitale løsninger. En god oppsummering av den boka finner du her.

Avstanden fra en klassisk modell til den produktorienterte modellen er betydelig

Nå kommer vi til kjernen i det som er skikkelig vanskelig: Gapet mellom hvor vi står, og hvor vi vil. Min erfaring er at transformasjonen mot å jobbe produktorientert er svært omfattende, og krever en betydelig investering over tid. La oss se på hovedmomentene som transformasjonen må adressere, i lys av den produktorienterte modellen:

Endre hvordan man prioriterer hvilke problemer som skal løses

Endringen omhandler at vi pålegger teamene et ansvar for å ta eierskap til, vise frem, og rapportere på, hvilken verdi de skaper for virksomheten. Til gjengjeld får de økt beslutningsmyndighet og mandat til å velge fremgangsmåte. Med frihet komme ansvar: De har selv besluttet hva som skal lages, og de har selv ansvar for effektene.

Selv om det på papiret ser lett ut å gå fra prosjekter med planer og veikart, til en produktstrategi med en tydelig retning, så er implikasjonene store. Ledere må være villige til å gi fra seg påvirkningskraft, og teamene må være modne nok til å ta imot ansvar. En sterk produktleder er viktig, og tillit er helt essensielt.

Endre hvordan man løser problemer

Avstanden kommer fra at teamet selv må ta ansvar for å utforme løsningsforslag, og prioritere disse ut fra hva som gir mest verdi. Dette medfører en ganske annerledes hverdag for teamet. Som del av å finne løsningsforslag, er gjerne det beste et team kan gjøre å gå ut i feltet og møte kundene sine. Dette kan sitte langt inne for en utvikler, som helst bare vil plukke den neste oppgaven på tavla og komme i gang med programmeringen.

Der en klassisk produkteier er vant til å bestemme en backlog, må en produktleder i stedet jobbe for å involvere både teamet og eksterne nøkkelinteressenter i utarbeidelsen av løsningsforslag. Produktlederen må rett og slett ta en langt mer ekstrovert og proaktiv rolle. Teresa Torres mener at man skal snakke med kundene sine ukentlig. Dersom man som produktleder ser på både brukerne og nøkkelinteressentene som kunder av sitt team, begynner vi å ane konturene av en ganske betydelig mengde dialog, og en helt annen rolle enn å prioritere en backlog på bakgrunn av domenekunnskap.

Endre hvordan man bygger løsningene

Som nevnt har vi mye å lene oss på fra tidligere, når det kommer til hvordan vi bør bygge løsningene. Min opplevelse er at de fleste team har relativt god smidig forståelse og -modenhet. For å oppsummere kort hva endringene går ut på:

• Fra få leveranser til mange leveranser
• Fra sjeldne leveranser til hyppige leveranser
• Fra at utviklere er ferdig med å bry seg om koden når den sjekkes inn, til en «you build it, you own it!» kultur
• Fra ingen instrumentering, til løpende eksperimenter og gode data om bruk av løsningen

Å lykkes med produktorientering vil ta tid

Min gode kollega Jens Andreas Huseby var den første jeg så som tegnet opp den produktorienterte modellen med de tre spørsmålene visuelt. Det var en skikkelig aha-opplevelse for meg! De som har lest Transformedkjenner seg nok godt igjen i materien. De påfølgende diskusjonene som Jens Andreas, jeg, og resten av Bekk har hatt om produktorientering, har dratt stor nytte av denne visualiseringen. Den er forholdsvis enkel, men likevel et svært effektivt kommunikasjonsverktøy.

Det åpenbare spørsmålet er hvordan man angriper det betydelige gapet mellom en klassisk modell og den produktorienterte modellen. Det finnes det ikke et enkelt svar på. I tiden fremover kommer vi til å se nærmere på dette! For nå vil jeg påpeke at denne transformasjonen har et betydelig omfang. Marty Cagan skriver i Transformed at selv de mest motiverte virksomhetene med de rette rammebetingelsene, kan bruke alt fra seks måneder til to år på å lykkes med Product Operating Model. To år med knallhardt arbeid hvor man gjør det meste rett, er av en helt annen størrelsesorden enn å sette av noen uker til å implementere OKR i utviklingsteam (som sjeldent resulterer i suksess).

Jeg vil avslutte med et sitat fra Jens Andreas: