Å jobbe med hypoteser i produktutvikling

Marit Andreassen
Jan 13 · 7 min read

Dette er episode 5 i bloggserien “Innovasjon i store organisasjoner” som er skrevet sammen med Sveinung Dalatun .

Et team blir satt sammen for å oppnå et mål. Vårt mål var å lære barn verdien av penger når kontantene forsvinner. Helt i starten visste vi lite om barns vaner og bruk av penger, og jobbet med hypoteser for å orientere oss i dette ukjente terrenget. I dette blogginnlegget deler vi hvordan vi jobbet hypotesedrevet og gi noen helt konkrete tips til teknikker og fremgangsmåter.

Tidligere har vi blogget litt om hvor vanskelig det er for en organisasjon å innovere men samtidig beherske å optimalisere på eksisterende produkter. Vi har kommet med noen forslag til hvordan store organisasjoner kan bli litt bedre på innovasjon. Og vi har lært at godt teamarbeid er den hemmelige ingrediensen for å lage gode produkter.

Hvorfor jobbe med hypoteser?

For oss var risikoen ved å bygge feil produkt veldig høy. Siden problemet vi skulle løse var ukjent ønsket vi å jobbe etter prinsipper fra lean startup og hypotesedrevet utvikling. Utfordringen teamet ble satt til å løse var: Kontantene forsvinner og barna våre ser oss foreldre tæppe det magiske kortet hver gang vi kjøper noe. Hvordan kan vi lære våre barn verdien av penger når måten vi lærte å bruker penger på har endret seg?

Du bør vurdere å jobbe hypotesedrevet når du kan krysse av for en eller flere av de følgende:

  • Løsningen og problemet som skal løses er ukjent (og det er oftere enn du kanskje tror).
  • Du har idéer du vil verifisere og teste. Dette kan være med på å avdekke om ideen din er et problem som er verdt å løse og om markedet vil ha det.
  • For å klare å jobbe strukturert i et komplekst problemområde som kan være ukjent og i stadig endring.
  • Du skal jobbe tett med brukere for å utvikle riktig produkt.
  • Du skal utforske og utvikle nye forretningsmodeller.

Du skal ikke anta noe, du skal vite

Det er lett å forstå teorien bak hypotesedrevet utvikling: Du har en eller flere antakelser. Formuler hypoteser på disse antakelsene. Velg ut den hypotesen med størst risiko. Sett suksesskriterier. Test hypotesen. Lær av resultatene. Iterer. Om du vil lese mer om metoden forklarer Mario Ek Aparicio dette godt i denne bloggen: Why iterative innovation processes are superior. Men vi synes ikke det var rett frem å jobbe hypotesedrevet!

I Store Norske Leksikon står det: “En hypotese er en gjetning, antagelse eller forklaring som synes rimelig ut fra foreliggende kunnskap, og som du forsøker å avkrefte eller bekrefte”. Hypoteser er en vanlig metode som benyttes i vitenskapen for å utforske og få innsikt, og som videre kan utvikles til en teori. De av oss som har hatt statistikk i utdanningen husker kanskje begreper som nullhypotese, falsifisering, statistisk signifikans, kritisk nivå osv. Og det er lett få litt hetta!

I tillegg måtte vi endre innøvde måter å tenke og jobbe på. I mange år har vi jobbet med å skrive krav og brukerhistorier som typisk prioriteres av en produkteier. En hypotese og en brukerhistorie har ulik form, og skal benyttes til ulike formål, og vi hadde ingen produkteier. Derfor hadde vi behov for å lære og trene på selve metoden. Men ta det med ro, vårt råd er: Start enkelt, prøv deg frem, ikke vær for streng med deg selv og stol på intuisjonen din — så kommer læringen naturlig etterhvert.

Det viktigste prinsippet er: Du skal ikke anta eller tro, du skal vite før du bygger noe. Og det er det mest befriende med hypotesedret utvikling! Hvis du har jobbet i noen år, har du mest sannsynlig erfart å ha en produkteier som prioriterer og beslutter uten å ha et grunnlag for dette. Kanskje du også har kjent frustrasjon over å lage ny funksjonalitet som ikke gir kunden verdi? Med riktig bruk av hypotesedrevet utvikling skal ikke dette forekomme.

Hvordan vi jobbet med hypoteser

Tidlig i prosjektet utarbeidet vi noen langsiktige hypoteser som hadde utgangspunkt i forskning om barn og økonomi. Vi valgte å jobbe med en til to hovedhypoteser samtidig, noe som gjorde at vi hadde fokus på å teste og innhente innsikt innen et avgrenset område.

De første hypotesene handlet om å fjerne de største risikoene: Vil foreldre at barna skal bruke appen vår? Er verdiforslaget bra nok slik at barna vil bruke appen vår? Bryter vi norsk lov i tjenestene vi tilbyr barna?

I begynnelsen var mye ukjent og det var vanskelig å vite om vi gjorde de rette tingene. Etter hvert som vi lærte mer om problemområdet og vi ble mer erfarne med å jobbe hypotesedrevet, ble det mye lettere.

Helt overordnet jobbet vi i fire steg som illustrert her:

Steg 1: Lag en liste over alle hypoteser du tror vil være relevante for suksessen til produktet

Her kan du stille deg spørsmålene: Hva lurer du på? Hva er usikkert? Hvilke ukjente variabler kan ha konsekvenser for veien videre?

I dette steget hadde vi workshops med hele teamet hvor vi tegnet, diskuterte, spiste seigmenn og lekte oss gjennom tanker og ideer. Ut ifra dette satt vi igjen med en liste med hypoteser. Dette var en aktivitet for hele teamet for få frem ulike perspektiver og meninger. Dette medførte at risikoen ble redusert, og etter vår mening var dette en suksessfaktor.

Når du skal formulere hypoteser kan det hjelpe å ha en mal å jobbe ut fra. Det finnes mange eksempler på internett som du kan søke opp, og vi har gitt deg et lite tips nederst i bloggen. Et eksempel på en hypotese vi hadde var: “Vi tror at barn ofte lurer på hvor mye penger de har på kortet ”.

Steg 2: Velg hypotesen som kan ha størst konsekvenser for produktet og forretningsmodellen

En hypotese som bare påvirker bakgrunnsfargen på en nettside har lav risiko. Men en hypotese som “Vi tror at foreldre ønsker at barna deres skal bruke en banktjeneste” har høy risiko. Om markedet ikke vil ha produktet, bør det kanskje ikke bygges? Derfor var det viktig for oss å teste ut om foreldre ville at barna deres skal bruke en tjeneste fra banken, og hva barna hadde behov for. Derfor startet vi å teste dette.

Vi hadde et ukentlig teammøte hvor vi jobbet strukturert med hypotesene. Vi hadde en digital tavle som bildet under viser, med oversikt over alle hypotesene: hvilke hypoteser vi jobbet med nå, hvilke som var i test og hvilke som var verifisert eller avkreftet. Alle i teamet var med på det ukentlige hypotesemøtet. Dette var viktig for å sikre at alle hadde den samme informasjonen, den samme læringen og ble enige om veien videre.

Steg 3: Gjør det minste som trengs for å redusere usikkerheten ved denne hypotesen

Utfør en hypotesetest! Eksempler på dette er å gjøre research, utføre et eksperiment, snakke med potensielle brukere eller lage en MVP som testes på reelle brukere.

I starten er ofte de billigste testene brukerintervjuer, eksperimenter, brukertester, spørreundersøkelser o.l. Vi gjennomførte noen spørreundersøkelser og hadde jevnlige brukertester med foreldre og barn. Vi stilte spørsmål til både barn og foreldre om pengevaner for å få mer innsikt og barna fikk testet prototyper. Brukertestene ga oss innsikt som vi benyttet videre og vi kunne validere om vi var på rett vei eller i et feilspor.

Før eller siden må du riktignok begynne med å bygge noe. Men når du først går i gang med å bygge noe bør du utsette alt som kan utsettes. Bygg det minste som skal til for å teste hypotesen og ikke skam deg over snarveier. Det kan være vanskelig for mange! Mest sannsynlig vil de aller fleste av hypotesene dine ha negative resultater. Da er det bortkastet å bruke tid på kodekvalitet og perfekt design på funksjonalitet som enda ikke er validert. Men når hypotesen faktisk har blitt validert bør du rydde opp.

En vanlig unnskyldning for å jobbe mye med kodekvaliteten før validering er at du er redd for at du ikke får tid til det etterpå. Dessverre lurer du bare seg selv og det medfører unødvendig arbeid.

Vi hadde en fysisk tavle, som vist i bildet under, hvor vi hadde standup tre ganger i uken. Tavlen hadde en swimlane med hypotesene vi jobbet med. Vi fulgte opp enkle overordnede lapper for utvikling og design. I tillegg hadde vi en egen swimlane som inneholdt oppgaver som skulle gjøres i forbindelse med pilotene våre. De mer detaljerte oppgavene som skulle gjennomføres hadde folk styr på selv, enten i hodet, på GitHub eller på papir.

Steg 4: Vurder resultatet fra testen

Hvordan påvirker det retningen på produktet? Kan vi fortsette i samme retning? Må vi snu? Kom det noen nye hypoteser ut av dette?

I det ukentlige teammøtet gikk vi gjennom hypotesene som ble testet og vurderte suksesskriterier og målingene vi hadde gjort underveis. Målingene var både kvantitative, som for eksempel brukerstatistikk, og kvalitative, som oppsummerte tilbakemeldinger fra brukere. Typiske diskusjoner var: Reduserer testen usikkerheten godt nok, eller burde vi teste samme hypotese ytterligere? Burde vi gå videre til en annen hypotese som nå er mer risikabel?

I møtet kunne vi ofte bekrefte eller avkrefte at løsningen fungerte, eller om den skulle endres. Vi lagde nye hypoteser og prioriterte hva vi skulle jobbe med i neste periode. Møtene hadde ofte mange gode diskusjoner og det var her mesteparten av læringen skjedde.

Konklusjon

Benytt hypotesedrevet utvikling når du skal jobbe strukturert i et problemområde du vet lite om og som er komplekst. Det vil avdekke usikkerhetene ved produktet du lager uten at det koster for mye.

Jobb tverrfaglig med hypoteser for å få opp flere perspektiver. Sett opp faste møter, kommuniser rundt og hold oversikt over hypotesene på en synlig tavle.

Ikke vær for streng med valideringen i starten. Start enkelt og test deg frem!

Lykke til :-)


Et eksempler på et testkort: Osterwalders testkort https://assets.strategyzer.com/assets/resources/the-test-card.pdf

Smidigalliansen

Vi ønsker at historiene skal være til inspirasjon! De kan romme alt fra psykologi, gruppedynamikk, prosessforbedring, prosjektstyring, programmering, testing, design, arkitektur, coaching, systemtenkning, budsjettering til ledelse mm. Vi vil stoppe sløseriet (i Norge). Først.

Marit Andreassen

Written by

Er opptatt av livets mysterier og små gleder. Er en observatør, deltaker og drømmer. Agil coach, mamma, blid og jobber i Vipps.

Smidigalliansen

Vi ønsker at historiene skal være til inspirasjon! De kan romme alt fra psykologi, gruppedynamikk, prosessforbedring, prosjektstyring, programmering, testing, design, arkitektur, coaching, systemtenkning, budsjettering til ledelse mm. Vi vil stoppe sløseriet (i Norge). Først.

Welcome to a place where words matter. On Medium, smart voices and original ideas take center stage - with no ads in sight. Watch
Follow all the topics you care about, and we’ll deliver the best stories for you to your homepage and inbox. Explore
Get unlimited access to the best stories on Medium — and support writers while you’re at it. Just $5/month. Upgrade