Produktutforsking 101: Prosessen med å finne det som er verdt å bygge
Går kollegane dine i gangene og diskuterer den nye boken “Transformed” av Marty Cagan? Snakker de om “Product Discovery” men du får aldri noen håndfast definisjon på hva det egentlig er? Frykt ikke! I denne grunnleggende introduksjonen til Product Discovery skal vi utforske helt konkret hva målet er med produktutforsking (som det heter på norsk), aktivitetene i prosessen, hvem som bidrar, og kuraterte lenker hvor du kan lese mer.
Faglige røtter fra Design Thinking på 2000-tallet
Siden silicon valley guru-en Marty Cagan droppet sin siste bok “Transformed” i mars har IT-Norge fått fornyet interesse for “Product Discovery”. Verken sjargongen eller aktiviteten er noe nytt — se Cagans egen bloggpost fra 2007, eller boka Practical Design Discovery av Dan Brown fra 2017. Man kan til og med argumentere for at grunnpilarene kom fra Design Thinking faget på 2000-tallet.
Likevel kan det være vanskelig å sette fingeren på hva produktutforsking egentlig er for noe. Brown og Cagan unngår å legge frem en tydelig definisjon, og benytter heller vage definisjoner som “Discovery is an attitude” (Brown, 3). Årsaken til dette er trolig at det kan ha mange former og fasonger, og at mange gjør det tilnærmet ubevisst fordi det må gjøres for å i det hele tatt bygge noe.
Sagt veldig enkelt:
«Produktutforsking er alt man gjør for å komme frem til hva som er verdt å bygge.»
Med mindre du jobber et sted der slike beslutninger er tatt for deg, har du også gjort produktutforsking før, kanskje uten å tenke over at det var det du gjorde.
Derfor kan det å forklare hvordan man gjør produktutforsking være litt som å forklare noen hvordan man løper — Man gjør det bare! Og alle gjør det litt forskjellig. Likevel kan det være en stor fordel å roe ned farten, isolere konkrete steg i prosessen, og ta utgangspunkt i én måte det kan gjøres på, for å kunne løpe fortere og bedre i fremtiden.
Produktutforsking er én av to modus i produktutvikling
For å lage en levedyktig løsning (om det er en app, nettside eller tjeneste) må man gjøre to ting:
- Finne en idé som er verdt å bygge
- Bygge produktet på riktig måte
Sistnevnte (ofte kalt “kontinuerlig leveranse” i Norge) handler om å sikre at vi klarer å bygge og levere produktet på en effektiv og brukervennlig måte. I denne artikkelen skal vi fokusere på den første.
Merk at dette er to “moduser”, ikke “faser”, der den ene ikke nødvendigvis kommer etter den andre. Hvis produktet ditt er i en tidlig fase uten brukere ennå, kan det gi mening å dedikere tid utelukkende til produktutforsking før man kommer i gang med kontinuerlig leveranse. Men for oss som jobber med et produkt som er ute i markedet allerede, så går disse to modusene hånd i hånd, parallelt med hverandre. Målet da er å etablere en praksis som går løpende — der utforsking (de aktivitetene vi var innom over) informerer leveranser, og leveranser inspirerer til mere utforsking.

Målet er å sikre at vi satser på idéer som er verdt å bygge
Prosessen for å sikre at vi satser på å bygge riktig idé, eller produktutforsking som det kalles på norsk, finnes fordi det er sabla dyrt å bruke tid og penger på å bygge noe som ikke er liv laga.
Men — hvordan vet vi hvilken av idéene våre som er “liv laga”? Og ikke minst, hvilke av de gode idéene våre burde vi ta tak i først? Det finnes flere verktøy for å kartlegge dette.
Allerede på 2000-tallet la IDEO (en foregangsfigur i Design Thinking faget) frem “DVF” modellen som de fleste bruker. Her etablerte de at man kan bruke tre kriterier for å identifisere en levedyktig idé:
- Den gir verdi til brukeren: folk velger å bruke det vi lager fordi det løser et reelt behov på en ønskelig måte. (Desirability)
- Den støtter virksomhetens mål: f.eks i form av økt inntjening for et selskap, eller ved å svare på samfunnsoppdraget til en offentlig aktør. (Viability)
- Det er gjennomførbart: det går faktisk an å bygge løsningen med de tekniske, juridiske og andre viktige rammevilkårene vi har. (Feasibility)
Modellen sier at hvis idéen ikke treffer på alle kriteriene, så er den ikke verdt å bygge. Ved å bruke disse kriteriene som et prioriteringsverkøty gjennom produktutforsking, går vi alltid videre med idéene som har livets rett.
Typiske aktiviteter og metoder i produktutvikling
Som tidligere nevnt, produktutforsking kan se totalt annerledes ut om du jobber f.eks i en SaaS startup, eller en offentlig etat. Det kan være vanskelig å generalisere og lite oversiktlig dersom det ikke er en lineær prosess. Her finnes det ingen fasit. Men, for å hjelpe deg i gang: Her er noen typiske aktiviteter og metoder som er gode å starte med.

🕵️ Få oversikt over kundens smerter, oppgaver og kontekst
Produktutforskingen starter med å forstå dine brukere — uansett om brukerne dine er kunder som bruker appen din, eller ansatte i etaten som bruker løsningen din på jobb. Gjennom utforsking av brukernes behov, smerter, adferd og arbeidsoppgaver kan man forstå konteksten løsningen kommer til å eksistere i.
Målet er å samle et grunnlag for idégenerering basert på en objektiv forståelse av virkeligheten. Det fins mange innsiktsmetoder som kan hjelpe teamet å forstå kundene sine, f.eks.:
- Dybdeintervjuer med kunder, domeneeksperter og folk som har tett kontakt med mange kunder
- Analyse av data fra salgssystemer, kundeservice, og adferdsdata fra den lanserte løsningen
- Observasjon av folk som bruker løsningen, eller løser problemet på en annen måte
Hvilken metode som er “riktig” å bruke avhenger av rammene man har, og hvilke spørsmål man vil ha svar på. Det er også viktig å bruke en kombinasjon av metoder for å forstå saken fra forskjellige perspektiver — ofte kalt “triangulering” av innsikt. Usikker på hvilken metode er riktig for deg og ditt team? Da ville jeg anbefalt User Interviews sin “UX Research Field Guide”. Der beskriver de hvordan du velger riktig metode, kombinerer dem, og gjennomfører metodene for å få best mulig resultat.
UX Research Methodologies: The Complete Guide
🔬 Sammenstille og analysere innsikt
Det er også viktig å bruke tid på å analysere innsikten, trekke ut funn og organisere alt dette på en måte som gjør det lett for hele teamet å involvere seg og ta felles eierskap til innsikten. Målet er å skape en felles forståelse av innsikten i teamet ditt. Når hele teamet sitter på den samme innsikten og forståelse av brukerne sine, kan også teknologer komme med idéer til løsning. Og senere når du må ta tøffe prioriteringer på hva som bør bygges først, blir den samtalen enklere når hele teamet har vært med på læringen. “Value Proposition Canvas” fra Strategizer, og Teresa Torres sin “Opportunity Solution Tree” er fine metoder å bruke.
“Value proposition canvas” fra Strategizer er et fint format for å oppsummere det man har lært om kundene sine slik at det er enkelt for hele teamet å sette seg inn i det og ta med innsikten videre i prosessen. Print det gjerne stort og heng det opp i teamets område for å holde den top of mind.
Opportunity Solution Trees: Visualize Your Discovery to Stay Aligned and Drive Outcomes - Product…
Et Mulighetstre (en: “Opportunity Solution Tree”) funker veldig bra for å hjelpe teamet å forstå hvordan teamets mål, hva man har lært, mulige problemer å løse, og måter å løse de på henger sammen. Det blir et levende dokument som oppdateres når man lærer nye ting, og alltid representerer teamets status i produktutforskingen. Et felles Miro-board for teamet er et fint sted å ha treet.
💡 Idégenerering
Idéer til løsning kan dukke opp både før, under og etter innsiktsarbeidet. Noen ganger kommer de av seg selv etter et intervju eller observasjon, andre ganger kreves det mer dyptgående arbeid. Uavhengig av hvor de kommer fra og når i prosessen de kommer, er det viktig å få de ut av hodene til folk kontinuerlig, og få de ned på en måte slik at hele teamet kan forstå hva den foreslåtte løsningen er.
Her har ux- og tjenestedesignere mye trening og erfaring å komme med, så det aller beste er å ansette en sånn for å sikre god idégenerering. Ofte er det hjelpsomt at idéene visualiseres i form av grensesnittsskisser, eller et enkelt storyboard. Workshopfasilitering er et sterkt virkemiddel for å samle idéer fra både teamet og andre interessenter.
Google har utviklet en metode som heter “Design Sprint” — en uke med fasiliterte workshops med blant annet metoder for idégenerering. “Crazy 8’s” og “Solution Sketch” er nå brukt av veldig mange.
Mens man kan idémyldre uten noe større opplegg rundt det, hjelper det ofte å ha litt fasilitering sånn at teamet ditt kommer i riktig mindset. Her har IDEO tips for å lykkes med idémyldring, samt 12 metoder for å komme forbi åpenbare idéer og til noe faktisk nyskapende.
📈 Validering og prioritering
For hver idé man har troa på, er det viktig å validere om den er levedyktig eller ikke. For å skape disse idéne har du tatt mange antagelser på levedyktighet:
- du tror at dette vil gi verdi for folk
- du tror at det vil støtte virksomhetens mål
- du tror at dette er gjennomførbart.
Det må man nesten gjøre i en idémyldringssesjon for å komme på noe i det hele tatt, men før man tar kostnaden av å bygge en full-spekket løsning, bør vi samle mer bevis på om idéen (eller hypotesen) er levedyktig.
I praksis, er det en rekke med eksperimenter som tester idéens levedyktighet. Dette heter hypotesetesting. Det er lurt å starte med billige eksperimenter som kan gi en indikasjon. Et klassisk eksempel er en papir-prototypetest der man samler tilbakemeldinger fra en bruker kjapt. Etter at du får noen tidlige indikasjoner på at idéen virker levedyktig, kan du sette i gang dyrere, mer omfattende eksperimenter. Disse vil gi et mer tillitsverdig resultat.
Det er her vi bruker aller mest tid og krefter under produktutforskingen. Målet er å komme inn i en vane av å kontinuerlig forme idéer, samle bevis på levedyktighet, og prioritere å bare gå videre med idéene som er mest lovende. Tenk at det å lansere idéen sin til kunder er bare det dyreste, mest tillitsverdige eksperimentet. Det skal man bare gjøre etter man har fått en del bevis fra raskere, billigere tester.
Denne keynote fra produktlederen Itamar Gilad er en fin introduksjon til en hypotesedrevet tankemåte der man samler “bevis” for at idéen sin er levedyktig før man velger å bygge den.
I Transformed, snakker Cagan om hypotesetesting på en annerledes, men relatert måte. Han beskriver levedyktighetskriterier som “risikofaktorer”: hvis du er usikker på om idéen din treffer et av kriteriene, blir denne usikkerheten en risiko. Hvis du er usikker på om idéen gir verdi til brukeren, er det en risiko for at idéen ikke er levedyktig.
Den observante leseren vil også merke at han legger frem 4 risikofaktorer, løst basert på de originale 3 fra Design Thinking. Han forklarer endringen selv på bloggen sin. Kort oppsummert, forskjellen er at han har delt “verdi for brukeren” i “value risk” og “usability risk”. I min mening er “usability risk” (klarer folk å bruke det?) en del av den andre modusen i produktuvikling (bygge produktet på riktig måte), så det er ikke like viktig å hypoteseteste som en del av produktutforskingen.

Produktutforsking er et tverrfaglig samarbeid
For å komme frem til levedyktige idéer, trenger vi de riktige folka med på laget. Mange konstellasjoner kan fungere, men fellesnevneren er at de alle er tverrfaglige. Teamet trenger kompetanse for å dekke de tre kriteriene jeg nevnte over:

Det viktigste er at teamet har fullt eierskap til hva man skal oppnå, og de som sitter på denne viktige kompetansen samarbeider tett og kontinuerlig. En vanlig konstellasjon for å dekke disse faktorene er “Produkttrioen” som består av en produktleder, en designer og en teknolog. Til sammen har de kunnskapen som trengs i et “kjerneteam”, og så kan andre ressurser trekkes inn ved behov.
Mens tabellen over kan få det til å se ut som man vil ha trestykker uten kompetanseoverlapp, så er det egentlig tverrfaglighet man er ute etter. Designeren, f.eks., skal være teamets ekspert på hva som gir verdi til brukeren, men bør også strebe etter en god forståelse av virksomhetens mål og tekniske rammer, for å samarbeide best mulig. Ekte tverrfaglighet er en produktrio som jobber med samme problemstilling til samme tid og unngår overleveringer. Det er også viktig at disse folka får dedikert tid og mandat for å jobbe med problemstillingen sammen over tid, fordi produktutforsking er sjeldent noe man gjør en gang også er man ferdig, men heller en kontinuerlig prosess.
Veien til produktutforsking starter med å stille spørsmål
Mens produktutforsking så klart er enklere om organisasjonen du jobber i har en produktorientert kultur og organisering som støtter dette, det betyr ikke at man må vente til at dette er på plass for å starte med produktutforsking. Mens du venter, start med å stille spørsmål — Hvem gjør noe lignende i dag? Hvordan gjør de det? Hvordan prioriterer vi hva som skal bygges? Vet vi egentlig at idéen vår er levedyktig?
Din nysgjerrighet vekker en kollegas interesse, og dere starter å bryte ned hvordan dere har “løpt” frem til nå. Da blir det naturlig å lære mer om hvor det bør gjøres det sammen, og så er man i gang.
Så knytt løpeskoene, senk farten midlertidig, og tørr å still spørsmålet: “Hvordan vet vi hva som egentlig er verdt å bygge?”
Del kunnskapen
Har du en kollega som også hadde dratt nytte av denne artikkelen?
Skrevet av
Relevant innhold
Her finner du innhold i samme gata om du vil lære mer.
Mer fra Fag i Bekk
Nå er du ved veis ende. Gå til forsiden hvis du vil ha mer faglig påfyll.
Til forsiden