Det er mye snakk om produktorientering og hypotesedrevet utvikling. En grunnstein i dette arbeidet er målinger.

Og det skrives mye om målinger, men jeg mener det mangler stoff om hvordan team helt konkret skal forholde seg til det daglige målingsarbeidet.

Jeg er en utvikler som er over gjennomsnittet interessert i målinger. Kanskje mer beskrivende ville jeg kalt meg en produktutvikler. I de fleste teamene jeg har vært i, har jeg vært pådriver for hypotesedrevet utvikling og å måle det vi gjør.

Jeg opplever at det er stor variasjon i modenhet når det kommer til målingsarbeid, og at de færreste gjør det perfekt.

I denne bloggposten har jeg samlet det jeg mener er vanlige fallgruver i målingsarbeidet. Fallgruvene er sett fra perspektivet til en utvikler i et team, og tar ikke for seg større organisatoriske eller strategiske endringer som må til for å få til produktorientering som helhet. Det er heller en hands-on erfaringsdeling som jeg håper flere kan ha nytte av å lese.

Bloggposten er skrevet for team eller teammedlemmer som erkjenner at målinger og hypoteser er viktige, men som synes det lugger litt og lurer på hvorfor. Ha også i bakhodet at dette er én persons synspunkter, og det trengs ikke tas som en fasit. Men i alle tilfeller burde punktene under være et godt startpunkt for diskusjoner om hvordan man jobber med målinger i teamet.

Fallgruve #1: Å ikke ha et måleverktøy

Det finnes mange måter å måle på. Det kan være uttrekk fra databasen, tall vist i Grafana, logginnslag, eller et hjemmesnekret måleverktøy. Noen team tenker at “vi har jo så gode tall i disse andre systemene, så vi trenger ikke bruke tid på å sette opp enda et verktøy”.

Min tydelige oppfordring er å skaffe seg et dedikert måleverktøy for å analysere brukeradferd i frontend. Andre målinger kan være et godt supplement, men brukt alene blir innsikten ofte fragmentert på forskjellige systemer, det blir vanskelig å se data på tvers, man trenger utviklerkompetanse for å lage og forstå visualiseringer, og det er ofte tilgangsproblematikk som gjør at alle på teamet ikke får sett tallene.

Advarer mot å misforstå MVP: «Dyrt og frustrerende»

tirsdag 28. januar 2025

Dedikerte måleverktøy fikser alle problemene nevnt over, og samtidig får man verktøystøtte for vanlige brukstilfeller som å se hvordan brukeren beveger seg i produktet, A/B-testing, trakter, tidsbruk og så videre. Ikke minst får man en direkte kobling mellom frontend og målingene — hvis alt man har er backend-metrikker vil man ikke kunne fange opp bruk av f.eks. knapper og filtre som ikke resulterer i nettverkskall.

Ikke misforstå meg: Tall fra databaseuttrekk er mye bedre hvis alternativet er å ikke ha noen målinger i det hele tatt. Ikke unngå å lage målinger i påvente av det perfekte måleverktøyet. Men jeg står ved min oppfordring.

Ting å prøve:

1. Kanskje organisasjonen allerede har investert i et måleverktøy? I så fall: Bruk det.
2. En større anskaffelse av måleverktøy kan medføre mye byråkrati i forbindelse med innkjøp og personvern. Undersøk om andre team i organisasjonen allerede har gjort dette arbeidet.
3. Hvis det er ekstra viktig med personvern, vurder alternativer som Plausible.io som ikke benytter seg av cookies; det kan kutte ned på en del papirarbeid.

Fallgruve #2: Teamet kan ikke måleverktøyet sitt godt nok

Uansett hvilket verktøy man har valgt, er det alfa og omega å være komfortabel med å bruke det.

Hvis utviklerne ikke kan verktøyet godt nok, så arbeider man i motbakke. Enhver ny måling blir et ork, målinger blir satt opp feil så det blir vanskelig å trekke gode slutninger, og man lar være å bruke den mer avanserte (og veldig nyttige) funksjonaliteten i verktøyet, som A/B-testing, trakter og sammenstilling av data.

Men utviklerkompetanse er ikke nok; hele teamet burde forstå verktøyet minst godt nok til å finne fram til grunnleggende informasjon selv. Produktleder og designer kan også ha god nytte av å grave seg ned i tallene og lage egne illustrasjoner.

Ting å prøve:

1. Først og fremst må minst én utvikler, gjerne flere, ha god innsikt i det tekniske i måleverktøyet. Ellers kommer man ingen vei. Derfor er verdt å investere tid i å ta noen tutorials og å lære seg verktøyet i seg selv, uten teamets data, først. Da kan man plukke opp konvensjoner og vanlige måter å gjøre ting på. Mange verktøy har sandbox-varianter der man kan prøve seg frem. Hvis det bare er én utvikler som gjør dette, burde vedkommende få anledning og oppmuntring til å dele det de har lært med de andre.
2. Øvrige teammedlemmer kan også ha nytte av sandbox-miljøer og å lese om hvilken funksjonalitet som er tilgjengelig.
3. Teamet burde jobbe sammen om målinger. Hvis man ofte går inn og ser på tallene sammen som team, så vil mye kunnskap smitte over automatisk. Kanskje prøv “måletirsdag” annenhver uke der teamet ser på de viktigste målingene sammen?

Fallgruve #3: Måleverktøyet er for vanskelig

Det finnes et mylder av måleverktøy der ute. Alle kan ikke velge verktøyet sitt fritt, men hvis man kan det er det verdt å tenke over hvilke behov og begrensninger man har, og finne et passende enkelt verktøy som innfrir.

Man trenger ikke sette opp Adobe Analytics hvis alt man trenger er å telle knappetrykk og sidevisninger, som gjøres mye enklere med f.eks. Plausible. Jo mer komplekst måleverktøyet er, jo vanskeligere er det å kunne verktøyet godt nok, se forrige fallgruve.

Ting å prøve:

1. La brukervennlighet telle høyt når man velger måleverktøy.
2. Husk på både teknisk brukervennlighet, og på det å funksjonelt enkelt kunne lage grafer og dashboards.
3. Har organisasjonen et Innkjøpt Analyseverktøy™️ de vil at alle skal bruke, men som teamet synes er vanskelig å jobbe med? I noen tilfeller er det beste å ta en spansk en og bare installere en enklere variant på egen kappe. Pass selvfølgelig på personvern.

Fallgruve #4: Manglende interesse for målinger

Noen ganger er målingsarbeidet vanskelig eller ikke-eksisterende fordi det rett og slett ikke er noen som har interesse nok til å sette det opp eller se på tallene. Det er i utgangspunktet ikke et problem at en enkeltperson ikke er interessert — man er ikke forpliktet til å like alt. Men det blir et problem når ingen er interesserte.

Grunnen til at det er ekstra problematisk når det kommer til måling, er fordi målingsarbeid ikke er en obligatorisk del av å lage et produkt. Du må ha noen som kan skrive frontend-kode for å lage en nettside. Men du trenger ikke sette opp målinger på den siden for at den skal fungere.

Dette er et problem med team-sammensetningen. Målingsarbeid burde erkjennes som en essensiell del av det å gjøre produktutvikling, og det burde gjenspeiles når man setter sammen et team. Samtidig må noen ting bare gjøres, selv om ingen synes det er gøy. Når ingen rekker opp hånda for å ta ansvar for målingene, mener jeg det er produktlederens ansvar som leder å identifisere at teamet har et problem, og å sørge for at det blir løst.

– Lett å bli oppgitt over produkt­eiere som bestemmer for mye

fredag 31. mai 2024

Ting å prøve:

1. Ta kompetanse på målingsarbeid med i betraktningen neste gang man er på utkikk etter et nytt teammedlem.
2. Be om hjelp fra andre team som er drevne på målinger. Kanskje organisasjonen har et støtteteam som er rå på målinger, eller et annet produktteam som har kommet lenger i målingsarbeidet? Spør om de vil tegne og forklare litt!
3. Alle er ikke nødvendigvis så gira på å sette opp et system for målinger. Men hvis man har vært med på å lage noe, så tør jeg påstå at de aller fleste vil være nysgjerrige på hvordan det brukes. Ta tak i denne nysgjerrigheten. Og hvis den ikke er der: Kanskje alle teammedlemmene ikke blir inkludert i nok av prosessen til å føle eierskap?

Fallgruve #5: Målingene eies av en enkeltperson

Og denne enkeltpersonen er sannsynligvis en utvikler. Noen team er heldige og har en utvikler som interesserer seg ekstra for målingsarbeid, og tar på seg oppgaven med å sette opp målinger for produktet man jobber med. Men det er med målinger som det er med all annen kode: Hvis det bare er én person som har eierskap til koden, vil det stadig være den som må inn for å gjøre endringer, og all den gode kunnskapen om målinger hoper seg opp.

Målingsarbeid gjøres best sammen som team. Hvis vi skal lykkes med hypotesedrevet utvikling, så må teamet som helhet ha begrepsapparatet og mulighetsrommet i orden. Vi må snakke om grafer, A/B-testing og konverteringsrate på en naturlig måte i samtaler om løsninger og prioriteringer. Dette samspillet faller bort når det er én person sitter som en målefaglig silo.

Dessuten burde målinger være en innbakt del i ny funksjonalitet man lager, og da burde alle utviklerne som rører frontend også vite hvordan de setter opp tilhørende målinger.

Ting å prøve:

1. Engasjementet til personen som liker målinger, må utnyttes. Foreslå en delings- eller opplæringssesjon.
2. For utviklernes del kan parprogrammering fungere som god kompetanseoverføring.
3. Jobb for at hele teamet tenker i retning av målinger og hypoteser.
4. Bruk tid på å lage et godt hoved-dashboard som viser de viktigste tallene for produktet. Det burde være så enkelt at alle teammedlemmene kan gå inn og forstå tallene. Få teamets innspill på brukervennligheten, av dashboardet, særlig designeren.

Fallgruve #6: Dårlig gjennomtenkte eventnavn

Når man først begynner å måle, vil man gjerne bare få noe på plass så man kan begynne å se tall. Spesielt hvis man ikke har mye erfaring med oppsett av målinger fra bunnen av.

Resultatet er ofte eventnavn som er vanskelige å forutse, som er inkonsekvente, og som ikke skalerer godt. Man klarer kanskje å sette opp et greit utgangspunkt av grafer med slike eventer, men det kommer med en stor endringskostnad hver gang man skal legge til noe nytt, enten teknisk i koden, eller funksjonelt i å sette opp nye grafer.

Dette er greit i en oppstartsfase når man først begynner å måle, men lignende en voksende kodebase burde også eventnavn refaktoreres når man har kommet ut av startarbeidet.

Ting å prøve:

1. Hvis organisasjonen din allerede har en godt definert taksonomi, bruk den.
2. Se an måleverktøyet ditt: Forskjellige måleverktøy har forskjellige begrensninger, og trenger forskjellige taksonomier for å fungere optimalt. Eventet klikk på "Send inn"-knapp er kanskje et helt fint navn hvis man ikke har begrensning på antall eventnavn, og man ikke har mulighet til å legge til egendefinerte felt på eventet. I andre systemer er kanskje navnet button_click med ekstrafelt {text: “Send inn"} det beste.
3. Les om best practices for ditt spesifikke måleverktøy.
4. Se til inspirasjon hvordan NAV koblet taksonomien sin i Amplitude til designsystemet sitt, på bakgrunn av en begrensning på antall eventnavn i Amplitude.

Fallgruve 7: #Teamet har ikke øvet nok på målingsarbeid

Målingsarbeid tar tid. Men det trenger ikke ta så lang tid. Hvis teamet vegrer seg for å prøve A/B-testing fordi man tenker det tar minst dobbelt så lang tid som å lage en vanlig feature, så er det et tegn på at man ikke har gjort det noe særlig før.

Det samme gjelder utviklere som stadig må legge til målinger etter en feature er ute i produksjon, enten fordi det ble glemt eller fordi det ble ansett som noe såpass vanskelig at de ville ta det ved en senere anledning.

I team som er ordentlig drevne på målinger, er det ikke et spørsmål om man skal legge til målinger på ny funksjonalitet: Det gjøres automatisk, fordi hele teamet vil forvente å se tallene kort tid etter lansering. A/B-testing sees ikke på som en stor oppgave, fordi man har gjort alt av oppsettet titalls ganger før — det eneste man må gjøre ekstra er å lage en liten variasjon av noe som allerede er kodet opp. Forarbeidet med bl.a. skisser er også ukomplisert, fordi teamet helt fra starten av oppgaven har tenkt i form av hypoteser og latt testbarhet være en del av oppgaven.

Den ekstra kognitive lasten ved målinger blir fjernet når man har gjort det mange ganger før.

Har du også fått ansvaret? Sånn kommer du i gang!

mandag 15. april 2024

Ting å prøve:

1. Lag rutiner for å alltid måle ny funksjonalitet. Snakk om det når dere lager brukerhistorier. Kanskje legg det inn i en sjekkliste for PR-er i GitHub?
2. Følg opp målingene jevnlig.
3. Ikke la dere demotivere hvis målingsarbeidet går sakte i starten. Start med å måle noe, selv om det tar lang tid og gir tvilsomme resultater. Gjør det igjen og igjen. Til slutt blir det enklere.

Fallgruve #8: Man samler mye data, men ser ikke på det

For noen år siden var Google Analytics veldig populært å bruke. Det hadde en god gratisvariant, og man fikk veldig mye ut av boksen: Sidevisninger, diverse tidsmålinger, hvor trafikken kommer fra, og så videre.

Det var veldig mye data, og få som visste hvordan man skulle bruke den.

Nå som vi har personvern i høysete og miljøaspektet ved bruk av lagringsplass har kommet tydeligere frem, er det ikke lenger en tid for å lagre uhorvelige mengder med data “bare i tilfelle”. Og de dataene som samles inn, burde brukes til det de er ment for: Å gi innsikt om produktet som teamet kan agere på.

Ting å prøve:

1. La et teammedlem med interesse for måling grave seg ned i tallene man har, og vise fram funnene til resten av teamet. En slik første utforskning kan gi mye gull som teamet kan jobbe videre med.
2. Finn en konkret ting å måle: Bruk av en ny funksjonalitet, en A/B-test, tiden det tar å utføre en oppgave. Det skaper engasjement og kan åpne teamets øyne for andre ting å måle.

Fallgruve #9: Målingene blir ikke brukt til å prioritere

Det er bra å ha gode målinger, men hvis det aldri fører til endring i teamets prioriteringer kunne man like gjerne latt være. Noen team har fine dashboards med oversikt over antall brukere og hvordan de beveger seg på nettsiden, men alt det brukes til er å sjekke innom en gang i blant fordi det er “fint å se hvor mange brukere vi har”.

Hvis man virkelig erkjenner kjernen i hypotesedrevet utvikling, nemlig at vi ikke vet om noe gir verdi før vi får det bevist, så blir målingsarbeid en essensiell del av produktutviklingsløpet.

Ting å prøve:

1. Ikke si dere ferdig med en funksjonalitet før målingene har vist at den gir verdi. Bruk verktøy som hypotesekort.
2. Bruk A/B-testing.
3. Hvis man ser på tallene innimellom fordi det er “fint å følge med”, så kan et godt neste steg være å bemerke seg når tall går opp og ned. Når er brukerne aktive? Hvilke ukedager får man flest og færrest nye brukere? Å reflektere over disse tingene kan gi ny innsikt.
4. Definer noen langsiktige KPI-er som sier noe om produktets verdi. Det kan være antall brukere, tid brukt i produktet, hvor fort et søk fører til et treff, og så videre. Bruk KPI-ene til å prioritere satsningsområder.
5. Bruk målingene i OKR-arbeidet, hvis dere bruker OKR. Gjerne i sammenheng med KPI-ene.
6. Snakk mye om målinger. Se på tall og grafer under faste møtepunkter som Monday Commitments og Friday Wins; gjør det til en del av teamets måte å operere på.

– Kjære tech lead: Jeg håper du innser at du er essensiell!

torsdag 30. mai 2024