Produktteam må bli bedre på målinger!

Top-down eller bottom-up?

Det skrives mye om produktorientering og målstyring på overordnet nivå. Effektmåling og hypotesetesting nevnes som viktige byggestener. Dessverre nevnes ofte selve målingsarbeidet i en bisetning: “Målstyring, blabla, strategi, blabla, og så må man passe på at resultatet måles.” Passe på at resultatet måles, som om det er en triviell oppgave man bare må huske på å få gjort. Selvfølgelig trenger vi å tenke strategisk for å få til produktorientering i det store. Men ofte underkommuniseres kompleksiteten i målingsarbeid, og realiteten er at mange team sliter med målinger, selv om de erkjenner at hypoteser og kvantitativ innsikt er viktig.

Jeg tillater meg å stjele et sitat fra bloggposten Hvordan kan vi koble produktteam mot verdiskaping? av min kollega

Jarle Svendsrud Hagset:

Nå snakker vi. Jarle påpeker at vi må jobbe fra bunnen av, med teamets evne til å måle. Og det trengs. Her er noen få eksempler på problemstillinger jeg har møtt i team:

• Vi har ikke tid til å måle.
• Vi har en del tall, men forstår ikke hvordan vi kan bruke dem til å sette mål.
• Vi sliter med grunnleggende bruk av måleverktøyet.
• Målingene har ingen effekt på prioriteringene. “Målinger er greit nok, men vi må jo uansett gjøre A, B, C og D, uavhengig av hva tallene viser.”

Dette er ikke uvanlige problemer — les gjerne bloggposten min om vanlige fallgruver i målingsarbeid. Jeg anser målingsarbeid som en egen akse et produktteam må utvikle seg på for å fungere godt, i likhet med psykologisk trygghet, kontinuerlige leveranser, design og koding. Dette er helt innenfor teamenes evne til å påvirke, så la oss fokusere på å bygge måleferdighetene bottom-up.

Krever modning, men blir ofte nedprioritert

Vi er enige om at målinger er en essensiell del av produktutvikling. Ironisk nok er det ikke noe man må gjøre. Det kan føre til at målingsarbeid blir nedprioritert i teamets daglige gjøremål. Det kan også være grunnen til at kompetanse på målingsarbeid ofte glemmes når man setter sammen team. Derfor er det desto viktigere å løfte behovet for kompetanse i teamet: Manglende frontend-kompetanse blir oppdaget automatisk når teamet ikke leverer funksjonalitet, mens manglende målekompetanse kan gå helt under radaren med mindre noen sier i fra.

Når målingsarbeid går fra å være ikke-eksisterende til å få prioriteten det fortjener, starter teamet på en modningsreise. En grov skisse av hvordan denne reisen foregår kan være i tre deler: Å få til det grunnleggende, å bli trygg på målingsarbeid, og deretter å løfte blikket. I de neste seksjonene beskriver jeg dette i mer detalj.

Steg 1: Få til det grunnleggende

For å lykkes med målingsarbeid, må man kunne det grunnleggende. For det første må man ha et måleverktøy. Allerede her er det noen team som kommer til kort: Man har kanskje noen grafer i Grafana her og databaseuttrekk der, men ingen helhetlig måte å samle innsikt om brukeradferd i frontend.

For det andre må man kunne bruke måleverktøyet sitt. Vite hvordan man sender eventer og visualiserer dem. Skal man sende eventer ved alle knappetrykk og sidevisninger? Hva skal man sende med av metadata i eventene? Og hva skal eventene hete? Dette er helt grunnleggende spørsmål, men likevel diskuteres det for første gang på mange team jeg kommer inn i.

Hvis ikke det grunnleggende er på plass, er det særdeles dårlige vilkår for å ta i bruk OKR som målstyringsrammeverk. Det er vanskelig å sette gode OKR-er, og mulighetsrommet for disse er ganske snevert når alt man har er målinger på et par-tre knappetrykk og et databaseuttrekk.

Steg 2: Bli trygg på målingsarbeid

Neste steg er å bruke målingene aktivt. Dette handler om den klassiske “bygge, måle, lære” beskrevet i blant annet The Lean Startup. Her er noen forslag:

1. Mål hvorvidt ny funksjonalitet blir brukt. Dette er enkelt å få til, og teamet pleier å være veldig interesserte.
2. Gjør en A/B-test. Vurderer dere å legge til en illustrasjon, eller flytte en knapp? Legg ut to varianter og mål hvilken som gjør det best. Første gang dette gjøres er det noen tekniske ting som må gås opp, men det er vel verdt det. Neste gang blir enklere. A/B-tester skaper ofte mye engasjement, og man får svar på et konkret spørsmål, så det illustrerer for teamet at målinger kan være nyttige.
3. Noen målinger er viktigere enn andre. Finn ut av hvilke metrikker som er spesielt viktige for akkurat deres produkt. Det kan være antall nye brukere, tid det tar å utføre en oppgave, eller antall sider vist per sesjon. Et utvalg av slike metrikker kan fungere som gode KPI-er.
4. Samkjør kvalitativ og kvantitativ innsikt. Har dere identifisert et mulig problem gjennom brukerintervjuene deres? Prøv å bekrefte eller avkrefte problemet med målingene dere har. Hvis det ikke er mulig, diskuter hvilke målinger som skulle vært på plass for å finne ut av det.
5. Snakk om målingene. Målinger som støver ned gir ingen verdi. Bruk litt tid på å lage et dashboard med relevante metrikker som alle på teamet forstår, og sett opp et fast punkt hver uke der man ser på tallene. Snakk om hvordan ny funksjonalitet skal måles før det blir bygget ferdig.

Steg 3: Løft blikket

Når teamet har lært det grunnleggende, blitt rutinerte på sjargongen rundt målinger og hypoteser, og fått en del erfaring med hvordan produktet fungerer som en baseline, er det på tide å løfte blikket. Først nå er teamet i stand til å se hvordan målinger kan brukes på en strategisk måte for sitt spesifikke produkt. Her er noen fiktive utsagn fra team som har klart å løfte blikket:

1. Fra KPI til OKR: “Det er et strategisk mål for virksomheten å posisjonere seg som den enkle leverandøren. Til tross for det har vi lenge fått tilbakemeldinger om at brukerne synes onboardingen er for kronglete. Gjennomsnittstiden det tar å gjennomføre løpet er en KPI for oss, og den er på 3 minutter og 21 sekunder. Vi vet fra andre målinger at steg X er et særlig problem. La oss ha som mål for Q2 å redusere denne tiden til under 3 minutter.”
2. Effektmåling: “Vi skal nå utføre et lenge etterspurt tiltak for å gjøre saksbehandlingen mer effektiv: Vi henter automatisk opp informasjon fra Fagsystem X, så saksbehandlerne slipper å kopiere og lime inn manuelt. De andre tiltakene vi har gjort på effektivisering har bare skjært sekunder av saksbehandlingstiden, men vi tror dette tiltaket vil redusere tiden med hele 5%. Vi kan gjøre støttemålinger ved å se at antall klikk til eksterne systemer går ned.”
3. Hypotesedrevet utvikling: “Vi tror at landingssiden blir for overveldende for brukerne våre, og at det er derfor så mange som 29% går ut igjen. Vi vil prøve å dele opp landingssiden i to steg med mindre informasjon per side: Det gjør at brukeren må gjøre flere klikk, men hver side blir enklere å forholde seg til. Vi tror gevinsten av det vil gjøre opp for det ekstra klikket. Vi gjør en A/B-test med forbedret fullføringsrate som mål, og forventer at den nye onboardingen er bedre enn den gamle.”
4. Tekniske metrikker er selvfølgelig også viktige i strategisk arbeid: “Brukerne klager over at internsystemet er treigt, og det gjenspeiles i målingene våre som sier at de lukker og åpner applikasjonen mye oftere enn det som burde vært nødvendig. Vi tror vi har identifisert en mulig synder i kallet til Api X, som stort sett tar under 200 millisekunder, men der 95-persentilen er på hele 5400 millisekunder. Dette kallet burde ikke ta så lang tid, så la oss ha som mål å redusere 95-persentilen til under ett sekund.”

Leve samarbeid og delingskultur!

Alle team er i forskjellige stadier på denne modningsreisen. Og det går ikke bare framover: Når teammedlemmer skiftes ut, må kompetansen og målekulturen overføres til de nye. For å lykkes med produktorientering må vi ha en konstant kraft i organisasjonen som dytter team videre på modningsreisen. Og den kraften kommer fra teamene, fra deg.

Synes du ikke teamet ditt gjør godt nok målingsarbeid? Ta det opp i teamet. Å snakke om problemet er første steg. Det pleier å være støttespillere der som kjenner på det samme. Når utviklere, designere og produktleder sammen ser forbedringspotensialet og er ivrige på å gjøre noe, tror jeg modningsreisen kan gå veldig fort.

Hvis teamet fortsatt sliter — eller hvis det går bra også, for den saks skyld — så oppfordrer jeg til å dele det med resten av organisasjonen. Ha innlegg på fagdager om hvor vanskelig (eller enkelt) dere synes målingsarbeidet er. Skriv blogginnlegg om konkrete problemer, eller hvordan dere brukte målinger for å sette retning. Det kan være til inspirasjon for andre, eller det kan være med på å løfte et behov som andre team i organisasjonen også føler på. Produktutvikling og målinger er vanskelig; erfaringsdeling gjør det enklere.

Vi må snakke mer om målinger i praksis. Hvis dette innlegget resonnerer med deg, så håper jeg du også tar det første steget og deler dine egne måleerfaringer — med teamet, med organisasjonen, eller med resten av IT-Norge!