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

Lasse Olsen
Aug 17 · 5 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 1 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 (du er her)
Del 2:
Organisering av små teams i stor organisasjon
Del 3:
Erfaringer på hypotesearbeidet og måling av suksess

Hvorfor hypotese-basert utvikling?

Jo flere bøker og artikler jeg leser om optimalisering og bygging av produkter, jo mer komfortabel blir jeg med å si at jeg vet ikke hva den perfekte måten er.

Med all sannsynlighet er det en all-inclusive buffett som bruker litt av scrum, agilt, sprint eller annet — basert på hva slags produkt og team du har. Med andre ord som en slags cabaret, bare i positiv forstand.

Selv om metodene for å bygge et produkt er mange, er prinsippene få:

  1. Du har et produkt du vil gjøre bedre.
  2. Da bør du ha noen mål du vil oppnå.
  3. For å nå målene bør du ha noen flinke folk som kan bygge/forbedre produktet.
  4. Hvis alt går bra så oppnår de flinke folkene målene, og produktet blir bedre. PS: gitt at målene er gode, folkene har det gøy og den psykologiske tryggheten gjør at man kan ha ambisiøse eksperimenter innenfor trygge rammer.

I snart ett år har teamet jeg er den del av jobbet hypotesedrevet. Vi har prøvd masse, feilet mye, vunnet mer og kommet med utrolig gode løsninger.

Hva er en hypotese?

En hypotese er en gjetning på at en endring man gjør, vil resultere i noe. Nedenfor kan dere se et bilde der vi testet å endre tekst, som vi trodde ville resultere i at flere klikket på det vi ville de skulle trykke på.

Det vakre med å jobbe hypotesebasert er at man vet egentlig ikke hvordan en endring vil bli. Man kan gjøre en antagelse, basert på tidligere kunnskap og (helst) analyse, men det er egentlig det.

Det er først når vi kan analysere dataen at vi vet resultatet. Gikk hypotesen som vi ønsket er det flott fordi da ble produktet bedre. Var hypotesen feil er det bra fordi da har vi lært. win-win.

Siden vi er 15 banker kan vi teste hypotesene rett i produksjon for 2–3 banker av gangen. En stor luksus som minimerer risikoen, men gir oss reel data. Bankene synes også det som regel er veldig kult å få teste ut nye ting på sine sider.

Vurderte vi andre løsninger enn hypoteser?

Det viktigste for oss når vi diskturte hvordan vi skulle jobbe var ikke nødvendigvis hvilken metoder vi skal bruke, men hva er det vi ønsker og har lært:

a) Vi har lært at OKR er ikke noe vi kan gjøre i ny og ne. Vi må få opp et rammeverk der folkene kan jobbet fokusert i en lengre periode mot våre mål. (her kan du lese mer om hva OKR er)

b) Vi vil at teamet skal ha eierskap til nettsidene (produktet vårt) og målene vi har, så de selv kan bestemme hva vi burde gjøre.

c) Vi vil at produktet vårt skal være det beste for våre brukere, som er store deler av norges befolkning.

b) Vi vil at folk skal ha det gøy på jobb! Dette høres kanskje flåsete ut for noen, men vi bruker mye tid av våre liv på en jobb. Vi jobber med individer som er smarte, har følelser, egne mål og ambisjoner samt ønsker over hva de vil gjøre på jobben. Vårt produkt er et produkt som konstant skal forbedres gjennom tiden, og jo lengre vi kan holde på en god kjerne av mennesker jo bedre. Med andre ord, vi er ikke i en sprint, men et raskt maraton der vi sprinter noen ganger.

Vi har prøvd å bruke hypoteser sporadisk, men det er vanskelig å gjøre ordentlig hvis man ikke har systemet for oppfølgning. I en kombinasjon med at vi fikk to dyktige designere med hypoteseerfaring på teamet og at vi så at andre selskaper og team har suksess med hypotesearbeid, valgte vi å teste dette ut.

Grunnlaget for hypotesearbeidet

Det varierer hva slags produkt man har, men sparebank1.no har et veldig bredt ansvarsområde. Stort sett alle forretningsområder i SpareBank 1 treffer nettsidene på en eller annen måte. Skulle vi derfor prøvd å fikse alt for alle hele tiden, fikser vi ingenting.

Å ha en solid forankring i et stort firma som SpareBank 1 Utvikling er viktig. Hadde alle team laget sine egne løsninger basert på subjektive meninger om hva som er viktigst for deres produkt, ville brukeren fått en fragmentert brukeropplevelse.

Det som foreløpig har fungert for oss er å sette OKR (Objective Key Results) basert på ett forretningsområde (f.eks. daglig bruk som vi kaller det), som varer en viss tid. I det området har man kunne presentere 3 store problemstillinger, og ut ifra det sette OKR som et team.

Hypoteseteamet har da klare mål som sitt anker. Det gjør at de kan velge hva de skal jobbe med, men kanskje viktigere: ha en grunn til å nedprioritere ting som ikke passer til det vi prøver å oppnå.

I del 2 av 3 jeg skriver om organisering av små teams i stor organisasjon.

SpareBank 1 Utvikling

Vi jobber med digitale løsninger hos SpareBank 1.