Hvordan hypoteser og små seire kan skape en vinnerkultur (Del 3/3)

Lasse Olsen
Aug 31 · 6 min read

Noe av det vanskeligste med å bygge produkter er det konstante spørsmålet: Gjør vi de riktige tingene nå, eller burde vi skifte fokus? Denne artikkelen er del 3 av en 3-partsserie der vi deler våre erfaringer med å gi teamet fullt eierskap til hva vi skal prioritere.

Del 1: Hvorfor hypotese-basert utvikling (start her)
Del 2:
Organisering av små teams i stor organisasjon
Del 3: Erfaringer på hypotesearbeidet og måling av suksess (du er her)

Erfaringer på hypotesearbeidet og måling av suksess

Når man tester ut nye ting er det viktig å få målt om det faktisk fungerer. Selvfølgelig kan dette være skummelt å se om resultatene blir når man har lagt inn mye energi og krefter for å få det til å fungere, men i eksperimentens ånd må man også være klar på at dette er noe vi tester, og at det ikke er et giftemål.

Jeg skulle gjerne delt alle hypotesene vi har gjennomført, men her er et lite utvalg.

Eksempelet under viser flere hypoteser vi utførte på nettsiden for boliglån. Basert på en brukertest så vi at de aller fleste synes boliglån er en veldig “skummel” ting å ta avgjørelse på, samt at produktene som vi kanskje tenkte var logisk for oss, var veldig forvirrende for brukeren.

Basert på brukertester så vi at de fleste brukerne synes boliglån er vanskelig, og at våre renter/produkter var forvirrende. Ved bruk av flere hypoteser prøvde vi å både forenkle og gjøre det tydeligere.

En problemstilling vi jobbet med var at alt for mange mobilbrukere ikke brukte appen vår, men logget seg inn via nettleser på mobil. Dette er et problem fordi appene våre gir den beste brukeropplevelsen.

Hypotesen var at hvis vi endret teksten slik at fordelen for mobilbanken var tydeligere, ville flere klikke på lenken til mobilbankappen.

Første løsning vi testet var hele teamet fornøyde med. Vi trodde vi hadde skapt et bra innsalg for mobilbankappen, bare ved hjelp av tekst. Problemet var at det motsatte skjedde: det ble mindre klikk på mobilbankappen og flere på nettbank.

Hvis vi ikke hadde jobbet hypotesedrevet kan det være at vi hadde gjort denne endringen og duret på videre for å gjøre andre endringer. Men, siden det ligger i rammeverket at vi må verifisere en hypotese etter en gitt periode, er vi tvunget til å analysere endringene når nok data kommer inn.

Noen ting jeg lærte av dette eksempelet:

  • Vi kan aldri gi garantier på resultater. Vi kan bare skape et kalkulert forslag og analysere etterpå.
  • Uansett om løsningen ikke gjorde det vi ville, har vi fortsatt lært og blitt smartere av det.
  • Små endringer som dette har store utslag siden vi har millionvis av besøk. Det er ikke alltid nødvendig å gjøre om alt for å få til det man vil.

Med det vi lærte fra løsning 1, skapte vi løsning 2 som gikk rett til poenget. Dette ga både en drastisk oppgang i klikk på mobilbanken, men også nedgang i klikk på nettbanken.

Selv om dette kan virke som en liten endring, er det en endring som forhåpentligvis vil hjelpe endre brukermønstret til brukerens levetid i SpareBank 1.

Noe av det vanskeligste med å bygge produkter er det konstante spørsmålet: Gjør vi de riktige tingene nå, eller burde vi skifte fokus?

Hypoteser og “små seire” gjør at man blir kontinuerlig bedre over tid, mens risikoen er minimert med tanke på tiden teamet bruker. Men, man kan fortsatt skape små seire som egentlig ikke løser de store problemene for brukeren. Derfor er det viktig å ta flere avsjekker for å sikre riktig fremgang.

Noen måter å sikre fremgang på er:

  1. Klarer vi å måle at vi blir bedre for brukeren over tid?
  2. Tester vi nok hypoteser, er de ambisiøse nok og jobber de mot våre OKR?
  3. Jobber hypoteseteamet bra sammen?

Hvis man har gjort OKR’ene riktig skal det i teorien være enkelt å måle suksess på løsningen basert på målet som ligger i en KR (Key Result).

For eksempel er en av våre KR’er:
Andelen som oppgir at de finner informasjonen de trenger skal være 90%

Et skyhøyt, men veldig konkret mål som vi kan følge med på over tid. Hvis tallet blir høyere (som det har gjort ganske drastisk) kan vi knytte det vi gjør med hypotesene mot de overordnede målene vi har satt.

Noe som er like viktig er å forstå om teamet fungerer bra sammen.

Glade team skaper de beste løsningene fordi de har eierskap, men det krever arbeid og tid for å skape tillit og bygge kultur. Det tok lang tid for å få hypotesearbeidet til å flyte, og selv om man aldri blir ferdig med forbedring, går det mye bedre nå.

Det er viktig å konstant ta en sjekk på hvordan folk har det, hvordan vi arbeider, om vi jobber riktig og gjør riktig arbeid. For å få til gode samtaler rundt dette er det nyttig å gjøre det innenfor et bestemt rammeverk som sikrer progresjon.

Retrospektiv er kongen her.

Det finnes gode forklaringer på hva en retro er, men over tid kan man se et tydelig tegn på at retroene vi har kjørt har gått fra store spørsmål om hvordan vi egentlig skal jobbe sammen til hvordan vi kan bli enda bedre på spesifikke problemstillinger.

Under kan dere se progresjonen fra første retro der vi hadde mye å forbedre oss på, til retro nummer 4 der vi kan jobbe med å svare på et spørsmål , i stedet for å diskutere alt. (spørsmålet var “Klarer vi skape verdi for bruker gjennom å ha hypoteseteam?”)

Eksempel fra venstre som var første retro med hypoteseteamet til nummer 4 til høyre som var siste.

I hypotesens ånd er denne måten å jobbe noe vi tester ut nå, men vi er åpne for at det kan komme bedre rammeverk med tiden.

Vårt mål er ikke å bli en slave for et rammeverk som vi liker nå, men kontinuerlig være åpne for å finne den nåværende beste løsningen som gjør at våre folk kan skape det beste produktet for våre brukere. Alt annet enn dette hovedfokuset skal egentlig være sekundert.

Med det sagt så har denne metoden både bidratt med bedre løsninger for brukeren, en tettere enhet mellom folkene våre og større eierskap til nettsidene. Tre viktige ting for å gjøre kontinuerlig suksess i det evige maratonet vi kaller produktutvikling.

Og hvis du har kommet helt til del 3 av artikkelserien (nice!) vil jeg også gi et stort takk til hele teamet. Det aller viktigste man har er de folkene som er på teamet og den ivrigheten, åpenheten og ambisjonene de har vist er noe jeg er utrolig glad jeg har fått vært en del av.

Uten om at vi deler kunnskap internt i SpareBank 1, er det mange bøker og artikler som hjelper med å bygge forståelsen. Selv om dette er en stor miks som i hver sin grad har inspirert, er dette noen bøker som har vært nyttig rundt dette temaet.

Alle lenker under går til Goodreads.com

Organisering og mål

  • Empowered — Hvordan bygge opp et team, spesielt rettet mot produkteiere.
  • Radical Focus — Min favorittbok om OKR og hvordan starte med dette.
  • Lean UX — Finnes mange fine bøker om UX, men denne er fin mtp hvordan få metoder inn i et team.

Fagbøker om nettsider

SpareBank 1 Utvikling

Vi jobber med digitale løsninger hos SpareBank 1.

SpareBank 1 Utvikling

Vi jobber med digitale løsninger hos SpareBank 1. Vi liker å skrive om det vi brenner for

Lasse Olsen

Written by

Not an expert. Product Owner at SpareBank 1

SpareBank 1 Utvikling

Vi jobber med digitale løsninger hos SpareBank 1. Vi liker å skrive om det vi brenner for