Mange organisasjoner lykkes med å etablere ett eller to smidige team – men møter motstand og utfordringer når produktmodellen skal skaleres. Det som fungerer i liten skala eller i noen team, fungerer ikke nødvendigvis når flere team, produktområder og ledelsesnivåer skal jobbe verdi-drevet. 
 
En av de vanligste årsakene til at overgangen stopper opp, er at vi fortsetter å måle det vi alltid har målt: leveranser, fremdrift og interne milepæler. Men i produktorganisering handler det ikke lenger om hva som leveres – men hvilken verdi som faktisk skapes. 
 
I arbeidet mitt med produktområder og avdelinger som skal skifte til outcome-fokus, har tre ulike metrikker vist seg særlig nyttige: brukernærhet, læringshastighet og skalering. 

Brukerne først – mål faktisk brukernærhet 

Når teamene ikke har direkte tilgang til brukerne, blir det vanskelig å jobbe hypotesedrevet og verdifokusert. Når du skal jobbe brukerorientert og verdi-drevet, er dette noe av det viktigste du tar tak i først som leder.  

Nyttige spørsmål å stille 

• Andel team med direkte brukerkontakt? 
• Antall dager siden siste direkte brukerkontakt? 
• Tid fra oppstart (behov) til faktisk bruk hos brukerne? 
• Antall ledd mellom utvikling (teamet) og sluttbruker? 

Eksempel fra praksis

I et produktområde jeg jobbet med, viste det seg at ingen av teamene hadde hatt direkte kontakt med brukere på over to måneder. De slet med å få tak i brukerne og til å få tid til å jobbe sammen med dem. De kalte inn til workshop, sendte ut spørreundersøkelser og satte opp innsiktsmøter, men fikk tilbakemelding fra brukerne om at de ikke hadde tid: “vi må prioritere andre ting”.

Teamet fortsatte å utvikle med den innsikten de hadde og gjorde en rekke antakelser underveis. Men med lite tilbakemelding og tid med brukerne, fikk det de utviklet begrenset effekt og bruken var ofte liten.

Brukerne på sin side stilte spørsmål ved prioriteringene og hva som ble laget, og sa det var andre ting som var viktigere å fokusere på for dem. Teamene løste feil problem, eller ikke brukernes problem i det hele tatt. Først da vi endret strukturen rundt teamene, fjernet mellomledd og fikk designere inn i teamet og til å hjelpe teamet med brukerinvolvering, da begynte vi å se endring i både atferd og resultater.  

Målinger som kan vise om du er på rett vei mot produktmodellen

• Antall dager siden siste direkte brukerinteraksjon 

• Andel team med direkte brukerkontakt 

• Tid fra innsikt til endring i løsning 

• Antall beslutninger tatt basert på brukerinnsikt 

• Antall ganger brukere har utfordret eller endret prioriteringer 

Læringshastighet og innsikts-drevet utvikling 

En vanlig misforståelse er at høy leveransetakt betyr at teamene jobber godt. Altfor ofte fokuserer vi på hvordan produktene bygges (med små, hyppige og kontinuerlige leveranser), og mindre på hvordan vi løser problemene, og om de når målene vi satte oss eller leverer på effektene vi ønsket. Vi trenger fart for å lære, men uten brukernærhet, tilbakemeldinger og systematiske målinger av effekt, er det bare aktivitet og “feature-factory”, vi leverer ikke nødvendigvis verdi. 
 
Som leder må du legge til rette for rask læring, ikke bare effektiv produksjon. Det betyr å måle hvor ofte og hvor raskt teamene får innsikt, og hvordan de bruker den innsikten videre. Ofte handler dette om å fjerne strukturelle hindringer for teamene. Det er din jobb å legge til rette for og utvikle en kultur der team får, og evner å ta, ansvar for effektene som skapes, ikke bare får en liste med leveranser eller features. 

Nyttige spørsmål å stille

• Hvor raskt kan teamene teste hypoteser? 
• Hvor ofte de får reell brukerdata (kvalitativ- og kvantitativ)? 
• Hvor mye verdi er det som faktisk når frem til brukerne (adopsjon)? 
• Er teamene organisert etter verdiskapning og brukerbehov, eller funksjon? 

Eksempel fra praksis

I en organisasjon vi jobbet med, leverte teamene hyppig – men brukerne tok ikke i bruk løsningene. Det var stort leveransefokus og mye teknisk gjeld, og teamene hadde stort arbeidspress på seg. “Det er ikke vi som har ansvar for implementering, det er linjen sitt ansvar å ta det i bruk». Vi oppdaget at teamene sjelden testet hypoteser, og at brukerdata kom sent eller ikke i det hele tatt. De hadde satt bort jobben med å følge opp leveranser, og mistet viktig læring og innsikt fra brukerne.

Det første vi tok tak i, var å legge til rette for læring og kjappere innsikt fra utviklingen. Hver uke hadde én person i teamet ansvar for å gjøre en innsiktsaktivitet med brukerne (intervju, observasjon, bruksdata), omsette det til noen antakelser og så kjøre det som et eksperiment den uken. Ved å innføre ukentlige innsiktsaktiviteter og måle tid fra idé til innsikt, fikk teamet raskere tilbakemeldinger og kunne justere retning før de havnet i “byggefella” og utviklet for mye før de testet.  

Målinger som kan vise om du er på rett vei mot produktmodellen

• Antall hypoteser eller eksperimenter testet per kvartal 
• Tid fra idé til første brukerdata/tilbakemelding 
• Andel beslutninger basert på data vs. antakelser 
• Andel leveranser med tilhørende effektmål 
• Antall iterasjoner før ønsket effekt oppnås 

Skalering – fra ett team til flere 

Når produktmodellen skal skaleres, er det ikke nok at enkelt-team lykkes. Du må måle om organisasjonen faktisk bygger kapasitet for verdi-drevet arbeid på tvers. Og du må gjøre det sammen med teamene og hele organisasjonen, og bygge strukturer som balanserer teamets evne til problemløsning og innovasjon, og som samtidig sikrer at dere har noen felles retninger og kjøreregler for å gå i takt. 
 
Start med å stille deg spørsmålet om hvorfor du ønsker å etablere flere produktteam og å skalere produktmodellen i din organisasjon. Hva er effekten du ønsker å oppnå, og hvordan ser det ut når du lykkes? Ta med forretningen, dette er ingen øvelse som gjøres i alene i IT-avdelingen. Hvilke problemer er det dere som ledergruppe forsøker å løse? Hva kan dere få til sammen, hvilke felles mål kan dere jobbe mot?

Her er det viktigere å få med hele organisasjonen og gjøre dette sammen med forretningen, enn at man går fort frem. Bygg erfaringer fra ett team til flere, og fra ett produktområder og til flere områder. Bruk tiden på å få med deg folk, utforsk sammen, og skaler organisk fra det som dere lære funker hos dere.  

Nyttige spørsmål å stille

• Har vi en felles forståelse av produktorganisering? 
• Har dere et tydelig oppdrag til produktområdet? 
• Hvordan støtter strukturen vår verdiskaping på tvers? 
• Hvordan vet vi at flere team jobber i samme retning? 

Eksempel fra praksis

I en organisasjon vi jobbet med, hadde teamene ulike måter å jobbe på. De kjørte separate prioriteringsmøter, jobbet mot ulike og til tider konkurrerende mål, og hadde mange avhengigheter seg imellom. Det var uklart hvordan tjenestene og produktene burde deles opp for å støtte skalering.

Etter hvert som de skulle utvide produktområdene til flere områder, satte de opp flere prioriteringsmøter med ulike interessenter og de utvidet styringsgruppen for produktområdet med ledere fra de ulike forretningsområdene. Teammedlemmer rapporterte om høy kognitiv belastning, store ansvarsområder og hyppig kontekstbytter. Det var lite struktur, ingen tydelig felles måte og jobbe på og vanskelig å komme inn som ny.  
 
Det første vi tok tak i, var å gå tilbake til ledergruppen og etablere en tydelig visjon for produktområdet. Hvilke brukeren var vi til for og hvilke problemer skulle vi løse, og enda viktigere hvilke skulle vi prioritere vekk.

Med en tydelig visjon for området, inviterte vi teamene til å sammen utarbeide en felles strategi for området – hvor organisering av teamene var del av dette. Først da vi etablerte felles visjon, og strategi, prinsipper for produktorganisering og satte noen felles effektmål, begynte teamene å jobbe mer koordinert og med lavere friksjon. 

Målinger som kan vise om du er på rett vei mot produktmodellen

• Tid fra oppstart til første verdiskapende leveranse per team 
• Antall team som jobber etter samme produktprinsipper 
• Andel team med felles effektmål og OKR 
• Antall avhengigheter mellom team i samme produktområde 
• Antall strukturelle endringer gjort for å støtte produktorganisering 

Hva betyr dette for deg som leder? 

Når du skal utforske produktmodellen i din organisasjon, enten du har kommet i gang med noen team, eller har skalert til flere produktområder, er det ikke nok å snakke om effekter- og verdiskapning. Du må systematisk jobbe med strukturene og rammebetingelsene til teamene, og skape gode betingelser for at teamene faktisk kan jobbe bruker- og verdi-drevet. Vært forsiktig hva du måler – din rolle er å sikre at metrikken driver riktig atferd – ikke at alle rapporterer status pent inn til deg. 

Fire grep som gjør en forskjell

• Gjøre metrikken synlige (plakat på veggen!) og sett mål sammen 
• Sett målene sammen, bruk teknikker som målsafari og workshops
• Fjerne strukturer som blokkerer for brukernærhet (hint: bygg tverrfaglighet) 
• Belønne læring og vær en rollemodell – ikke bare fokuser på levering og fart 

Disse fire metrikkene for å følge opp brukernærhet, læringshastighet og skalering gir deg innsikt i hvor teamene står, og hva du som leder kan gjøre for å støtte dem i å jobbe verdi-drevet i praksis.

Vil du vite mer? 

I Novanet jobber vi med organisasjoner som skal skalere produktmodellen – og som trenger støtte til å utvikle struktur, kultur og praksis som faktisk fungerer.