Prosessen for produktoppdagelse

Produktoppdagelse er prosessen med å forstå brukerne dine, identifisere problemene deres og finne løsninger som du vet vil hjelpe dem.

Avhengig av kvaliteten på oppdagelsesarbeidet du gjør, vil du enten lykkes eller mislykkes med virksomheten din. Logikken er enkel. Med god produktoppdagelse ender du opp med å bygge funksjoner som folk trenger og betaler for. Dårlig produktoppdagelse antar derimot stadig nye funksjoner som ingen trenger.

Dette kan virke svært overveldende, særlig med tanke på mengden innspill i produktoppdagelsen. Men det finnes et godt system for å håndtere denne kritiske oppgaven, med en rekke verktøy og rammeverk.

La oss derfor forstå hva produktoppdagelse er, og hvordan du kan gjøre det på en god måte.

Hva er produktoppdagelse?

Produktoppdagelse er prosessen med å forstå brukernes problemer og finne gjennomførbare løsninger for å dekke behovene deres.

Denne prosessen er vanligvis svært forskjellig fra det interessentene dine forestiller seg. For mange av dem handler det om kreativ tenkning og å komme opp med en liste over kule funksjonsideer én gang, for deretter å bygge produktet basert på denne listen.

Denne tankegangen er feil på to viktige områder:

• Oppdagelse er en kontinuerlig og iterativ prosess. Du blir ikke ferdig med oppdagelsen; du avslutter én syklus og starter den neste.
• Oppdagelse handler ikke om å finne på kule ideer på en kreativ måte. Det handler om å forstå brukernes behov, utvikle løsninger som kan løse dem, og deretter validere at disse løsningene faktisk fungerer.

En annen vanlig misforståelse handler om forholdet mellom oppdagelse og leveranse. Mange interessenter ser på dem som to separate faser som kommer etter hverandre. I virkeligheten gjennomfører effektive produktutviklingsteam oppdagelse og leveranse parallelt. Mens teamet ditt leverer funksjonene dere oppdaget for to måneder siden, gjennomfører dere oppdagelse for det neste settet med funksjoner.

Visuelt:

• Diagram med delt bane for «Oppdagelse kontra leveranse». Visualiser denne ideen: Team gjennomfører oppdagelse og leveranse parallelt. Mens teamet ditt leverer funksjonene dere oppdaget for to måneder siden, gjennomfører dere oppdagelse for det neste settet med funksjoner.
• Alternativ tekst: «Parallelle spor som viser kontinuerlig oppdagelse og leveranse.»
• Bildetekst: «Produktoppdagelse er ikke en engangshendelse – den foregår parallelt med leveransen.»

Selv om du befinner deg i et marked der fossefallsutvikling er normen og oppdagelse kommer før leveranse, er det alltid viktig å vie oppdagelsen all oppmerksomhet, ettersom kvaliteten på den vil påvirke produktets suksess direkte.

Hvorfor oppdagelse er et konkurransefortrinn

Det korte svaret er dette: Med oppdagelse forstår du personaene og brukerbehovene dine bedre, og du finner frem til effektive løsninger. Effektive løsninger gjør deg til en sterk konkurrent i markedet, ettersom du raskt skaffer deg kunder og enkelt beholder dem.

For det lange svaret kan vi se på Marty Cagans Inspired. I boken påpeker Marty at effektiv oppdagelse kan hjelpe deg med å redusere fire typer risiko:

• Verdirisiko viser til risikoen for at folk ikke bruker produktet ditt fordi det er meningsløst for dem.
• Brukervennlighetsrisiko viser til at folk har problemer med å bruke produktet ditt.
• Gjennomføringsrisiko viser til at teamet ditt ikke er i stand til å bygge det.
• Levedyktighetsrisiko viser til produktets evne til å hjelpe virksomheten din med å overleve og vokse.

Hvis vi antar at du kan redusere alle disse risikoene, og konkurrentene dine mislykkes med én eller flere av dem, får du et sterkt konkurransefortrinn og muligheten til å ta en større del av markedet.

Tiny Speck er et godt eksempel på denne ideen. Det var et spillutviklingsselskap som laget et nettbasert MMORPG-spill som mislyktes totalt. Problemet var at de bygde et spill ved ganske enkelt å kopiere ideer fra andre (også kalt fabrikkfellen) uten å forstå spillernes behov tydelig.

Selskapet la snart ned dette spillet og lanserte i stedet sitt interne kommunikasjonsverktøy. Ja, det var Slack.

Det samme selskapet er altså også et godt eksempel på produktsuksess gjennom grundig oppdagelsesarbeid. I motsetning til med spillet sitt gjennomførte Slack-teamet endeløse oppdagelsesiterasjoner og hadde en svært tydelig forståelse av brukernes behov.

Fire viktige spørsmål i produktoppdagelsen

Hvis vi ønsker å forstå essensen av produktoppdagelse uten å gå oss vill i detaljene, kan vi se på disse fire spørsmålene som prosessen prøver å besvare.

• Finnes det et reelt problem? Nettopp, noen ganger risikerer du å lage en løsning på jakt etter et problem. Hei, 90 % av alle oppstartsbedrifter der ute som drives av ChatGPT ;)
• Kan vi løse det? Noen ganger ligger problemet i hvor kompleks løsningen er. S.T.A.L.K.E.R. er en ukrainsk videospillserie som møtte på dette problemet. De ønsket å bygge A-life, AI-systemet sitt som simulerte livene til NPC-er og dyr i spillet fullt ut. Men problemet var rett og slett for komplekst til å løse.
• Bør vi løse det? Noen ganger finnes problemet, men det er ikke stort nok til å løses med et produkt. Google Glass er et godt eksempel på dette. Ja, det var kult, men det ville ikke gjort livet mindre praktisk for noen å ikke ha Google Glass.
• Kan vi levere det på en effektiv måte? Dette spørsmålet handler mer om den operative siden av produktutvikling og evnen din til å skalere og støtte brukerne dine. YouTube var i sine tidlige dager svært nær ved å mislykkes på grunn av manglende evne til å skalere.

Det du egentlig gjør under produktoppdagelsen, er å bruke ulike verktøy og rammeverk for å få innsikt, slik at du kan besvare disse spørsmålene.

Rammeverk for å strukturere oppdagelsen

Man kan argumentere for at en erfaren produktsjef kan gjennomføre oppdagelsen uten å bruke noen veiledning eller rammeverk. Det stemmer. Men det er en grunn til at vi har rammeverk for produktoppdagelse. De gjør det mulig å tilføre struktur og forutsigbarhet til oppdagelsesprosessen.

Når det gjelder selve rammeverkene, kan vi se på disse fem:

Smidig utvikling med to spor: Dette er prosessen med å ha to parallelle prosesser i smidig utvikling. Du har et oppdagelsesspor som skaper ideer til funksjoner, og et leveransespor som utformer og bygger dem.

ProductBoard og Jira er vanligvis verktøyene jeg bruker til å administrere dette rammeverket.

Mulighets- og løsningstre: Vi skal snakke litt mer om dette senere. Kort sagt lar dette rammeverket deg lage et tre der roten er kjerneutfallet. Fra denne roten lager du muligheter for å løse smertepunkter som grener. Deretter lager du grener med mulige løsninger for hver mulighet.

Miro har gode maler for mulighets- og løsningstre som du kan bruke.

Oppdagelsessprint: Dette rammeverket er inspirert av Googles hjertebarn, designsprinten. Det legger til rette for raske iterasjoner på løsninger. Du får omtrent to uker til å gjennomføre brukerintervjuer, komme frem til en løsning, bygge prototypen og teste den.

Kontinuerlig oppdagelse: I motsetning til de tre foregående, der du har iterasjoner med en tydelig start og slutt, har kontinuerlig oppdagelse ingen slutt. Du gjennomfører ganske enkelt endeløse runder med intervjuer av målgruppen din, lager kontinuerlig løsninger og tester dem.

Her er en sammenligning av disse rammeverkene side om side.

Valget av selve rammeverket avhenger av deg. Ikke alle team vil ha like stor nytte av det samme rammeverket. Bruk tabellen ovenfor til å velge et som passer med teamets størrelse, tempo og toleranse for usikkerhet.

Roller & teamsamarbeid

Det finnes en vanlig misforståelse (og en stor fallgruve) om at produktoppdagelse bare handler om produktteam.  Selv om dette hovedsakelig er en aktivitet for produktteam, vil en god oppdagelsesprosess også involvere andre teammedlemmer og interessenter. Slik vil hvert teammedlem bidra til oppdagelsen:

• Produktsjefer: De leder oppdagelsesprosessen, samordner teammedlemmene og prioriterer løsninger og innsikt.
• Brukeropplevelsesdesign: De deltar i brukerundersøkelser, lager designkonsepter og klikkbare prototyper, og gjennomfører brukervennlighetstesting.
• Utvikling: De vurderer hvor gjennomførbare løsningene er, og peker på risikoer ved produktleveransen.
• Interessenter: De bidrar med strategisk og forretningsmessig kontekst på overordnet nivå.

Som vi kan se, er deltakelsen til hvert teammedlem viktig. Så hvis ledelsen spør deg om scrumteamet bør delta i produktoppdagelsesprosessen, er svaret ditt et klart ja!

Produktoppdagelsesprosessen

Å forstå kundenes behov og komme frem til validerte løsninger for dem minner oss om en trakt, der de øverste lagene er mye større enn de nederste.

Slik er det også i produktoppdagelse. Du starter med en mengde innsikter, klager og kommentarer fra målgruppen din, og ender opp med bare et par validerte løsninger som du vet vil skape verdi for brukerne dine.

Slik ser det ut.

La oss nå bryte ned produktoppdagelsesprosessen litt mer og forstå detaljene i hvert av elementene.

Generelt består produktoppdagelsesprosessen av disse ti trinnene.

La oss nå se nærmere på hvert trinn.

1. Gå gjennom den strategiske retningen din

Gode funksjoner dekker brukernes problemer. Utmerkede funksjoner gjør det samme, samtidig som de følger den overordnede strategiske retningen for produktet ditt. Før du begynner med produktoppdagelse, er det viktig å gå gjennom strategidokumentet på nytt og minne deg selv på hvor du ønsker å komme på lang sikt, og hvilken retning du ønsker å ta.

Dette hjelper deg med å rette oppdagelsesarbeidet mot løsninger som er i tråd med strategien din. Ellers risikerer du å fokusere på funksjoner som ikke vil føre deg noe sted på lang sikt. 

2. List opp antakelsene dine

Et annet viktig aspekt ved produktoppdagelse som du må håndtere før du kommuniserer med brukerne, er antakelsene dine. Poenget er at du sannsynligvis gjør mange antakelser om markedet eller brukerne dine, og det er viktig å dokumentere dem for å sikre at undersøkelsene dine ikke i for stor grad bygger på de dristigste antakelsene dine.

Til dette kan du lage et antakelseskart.

I kartet her kan du stole på antakelsen øverst til venstre og være på vakt mot antakelsene øverst til høyre.

3. Snakk med brukerne dine

Uten dette trinnet er produktoppdagelse bare gjetning. Snakk med brukerne dine – ellers risikerer du å bygge noe helt annet enn det du burde.

Det finnes mange ulike måter å snakke med brukerne på:

• Besøke dem (for eksempel dra til et sykehus og intervjue leger).
• Møte dem på messer (for eksempel snakke med teknologijournalister på CES).
• Delta i Zoom-samtaler med dem.

For det siste alternativet kan du bruke ulike metoder, for eksempel plattformer for deltakelse i undersøkelser, kontakte brukerbasen din eller kontakte målgruppen din på LinkedIn ved hjelp av en rekruttererkonto.

4. Analyser innsikt fra brukere og data

I tillegg til sammendrag av brukerintervjuer bør du sjekke dashbordet for produktanalyse og tilbakemeldingene som support- og salgsteamene dine har samlet inn. På den måten henter du innsikt fra flere kilder. I stedet for å lese gjennom endeløse sammendrag eller utskrifter kan du få en LLM til å behandle alt for deg.

Her er et eksempel på en ledetekst du kan bruke:

Du er en senior produktsjef for programvare med 10 års erfaring. Du er flink til å analysere utskriftene fra salgsteamet ditt og identifisere viktig informasjon som vil være nyttig for produktundersøkelsen din.
Her er utskriften fra salgssamtalen
{{sales_transcript}} 

Basert på informasjonen i salgsutskriften ber jeg deg identifisere følgende informasjon.
Identifiser følgende:
1. Viktigste utfordringer: vis til de mest fremtredende problemene og utfordringene brukeren opplever med nåværende verktøy og prosesser.
2. Hvorfor er de interessert i deg: viser til grunnen til at selskapet ser etter et nytt verktøy nå.
3. Produkt tilbakemeldinger: viser til tilbakemeldingene selskapet har gitt salgsteamet om {{your_product_name}} og funksjonene da de så demonstrasjonen.

Etter å ha sett på tilbakemeldingene og sammenholdt dem med innsikter fra brukerintervjuer og analyser, vil du begynne å se trender og gjennomgående temaer som dukker opp.

5. Identifiser brukernes utfordringer i funnene dine

Det er ikke alltid så enkelt å identifisere utfordringer. Ja, det finnes tilfeller der 80 % av alle brukerne forteller deg at en bestemt del av arbeidet deres er en utfordring, men det betyr ikke nødvendigvis at det er et problem det er verdt å løse. Du bør også forstå «intensiteten» i denne utfordringen.

Se for deg at 70 % av brukerne av plattformen din for sosiale medier sier at de irriterer seg over antallet varsler, og over at de ikke kan markere alle som sett.

Når du sammenholder tilbakemeldingene deres med analyser som viser at 90 % av dem i gjennomsnitt har 2–3 varsler om dagen, kan du vurdere at denne klagen ikke er «intens» nok til å prioriteres fremfor andre punkter på listen din.

6. Finn løsninger på disse problemene

Dette trinnet handler om å finne mulige løsninger på problemene du har identifisert som et resultat av kundeintervjuene og analysen av tilbakemeldingene.

Du kan ganske enkelt sette deg ned med design- og utviklingsteamene dine og idémyldre. Men for å sikre at løsningene dine er direkte knyttet til et større forretningsmål eller et ønsket resultat, kan du bruke rammeverket mulighetsløsningskart av Teresa Torres. Slik ser det ut for Spotify-brukernes utfordring: «Jeg vet ikke hva jeg skal lytte til».

Ved hjelp av kartleggingen så vi at det å fjerne barrieren «hva skal jeg lytte til» kunne øke antallet daglig aktive brukere (DAU), noe som gjør dette til et problem med stor effekt å løse.

7. Test løsningene dine med prototyper

Å analysere brukerinnsikt og omsette den til en liste over mulige funksjoner er bare utgangspunktet. Produktoppdagelse er forankret i den vitenskapelige metoden, noe som betyr at du bør teste og validere ideer før du legger dem til i produktplanen din.

Du kan validere løsninger på ulike stadier i livssyklusen – fra å beskrive ideen for en bruker under et intervju og samle inn tilbakemeldinger, til å lage enkle skisser, til å spørre fokusgrupper og samle inn brukertilbakemeldinger på tidlige prototyper. Du kan gå så langt som å bygge og lansere et minimum levedyktig produkt (MVP).

Validering i en tidlig fase, for eksempel å diskutere ideen i et intervju, er raskt og rimelig, men kvaliteten på kundetilbakemeldingene kan være lav fordi brukerne kan ha problemer med å forstå konseptet fullt ut.

Testing med et MVP gir derimot rikere og mer presise tilbakemeldinger fordi brukerne kan samhandle med produktets faktiske funksjonalitet. Denne tilnærmingen er imidlertid langsommere og dyrere på grunn av utviklingsarbeidet den krever.

Når jeg tar denne avveiningen i betraktning, er min favorittmetode for validering klikkbare prototyper, siden de både er relativt rimelige å lage og viser faktiske brukere et reelt UX-design av det nye produktet eller den nye funksjonen din.

For å fremskynde opprettelsen av prototyper kan du bruke Figma AI eller de innebygde AI-funksjonene i andre UX-designverktøy.

8. Dokumenter testresultatene

Når testene er fullført, samler du all lærdom og alle resultater i ett enkelt dokument. Gruppér dem etter løsningen og hypotesen som testes.

På denne måten har du alt du trenger på ett sted når det er på tide å evaluere en løsning, slik at du kan ta en velinformert beslutning.

9. Valider eller avkreft løsningene dine

Det er på dette tidspunktet du ser på alle funnene fra testene dine og avgjør om:

• Du anser løsningen som validert og legger den til i den eksisterende produktkøen din.
• Du forstår at løsningen er på riktig vei, men trenger omarbeiding. Da tar du den tilbake til idéfasen for å gjøre forbedringer basert på testresultatene.
• Du forkaster løsningen fordi den ikke løser brukerproblemene den skulle løse.

Alle de tre utfallene er forventede. Når du forkaster et produkt, bør du se på det som en stor suksess, siden du nettopp unngikk å bygge produkter og kaste bort tid og ressurser på noe som ikke løser brukernes problemer.

10. Bygg de validerte løsningene og begynn på nytt

Det siste logiske steget i produktoppdagelsesprosessen er å legge løsningene til i produktkøen, prioritere dem og bygge dem.

Det er imidlertid svært viktig å forstå at du ikke egentlig avslutter produktoppdagelsen her. I stedet avslutter du denne iterasjonen og starter umiddelbart på den neste. Vellykkede produkter er produkter der oppdagelsesprosessen aldri tar slutt.

Her kan teamene ta de riktige produktbeslutningene basert på det de har lært fra tilbakemeldinger fra brukerne, brukervennlighetstesting og A/B-testing.

Verktøy for produktoppdagelse

Her er noen verktøy det er verdt å utforske for å hjelpe deg med å komme raskere gjennom produktoppdagelsen og oppnå bedre resultater, organisert etter hvilken fase du er i.

• Brukerundersøkelser: Hotjar for opptak av økter, UserTesting for brukervennlighetstester og Figma for design av brukeropplevelser og klikkbare prototyper.
• Kartlegging av brukerreiser og visuelt samarbeid: Miro er det universelle verktøyet her. Du kan også vurdere å prøve den fremvoksende konkurrenten FigJam eller andre alternativer til Miro.
• Konkurrentundersøkelser: Similarweb for konkurrentenes trafikkkanaler, Builtwith for teknologistakker.
• Produktanalyse: GA4 for kanaler og trafikk. Amplitude for atferd og viktige produktmåltall. Når det gjelder programvare for varmekart, er HotJar et populært alternativ.
• Sporing og prioritering: RICE-poengmodellen for enkel prioritering, Aha! eller ProdPad for veikart og lagring av produktideer.

Dette er verktøyene jeg bruker og anbefaler til kollegene mine. Hvis du vil se flere alternativer, kan du også ta en titt på vår kuraterte liste over verktøy for produktoppdagelse.

Hvis du har lagt merke til det, nevnte jeg heller ingen AI-løsninger her. Det er fordi jeg ønsker å snakke om dette separat og mer detaljert.

Hvordan AI forandrer oppdagelsesprosessen

Oppdagelse har sannsynligvis vært området innen produktledelse der AI har skapt mest verdi. Grunnen er at LLM-er er gode på den typen oppgaver du vanligvis finner innen produktoppdagelse. Dette gjelder spesielt transkribering, oppsummering og uthenting av innsikt.

Vi har omtalt AIs innvirkning på produktoppdagelse i en av episodene av podkasten vår. Gjesten vår, Craig Watson, tok oss gjennom sin egen erfaring og delte mange verdifulle innsikter.

Han påpeker spesielt at AI har vært til stor hjelp for produktledere på følgende områder:

Transkribering og oppsummering av brukerintervjuer: Produktledere trenger ikke å ta notater under samtalen og lytte til opptakene etterpå. Alt de trenger, er at AI-roboten deltar i samtalen og tar den opp. Roboten gjør deretter opptaket om til en transkripsjon og oppsummering – og fremhever de viktigste funnene fra intervjuet. Gode verktøy for dette er Dovetail, Krisp og GreatQuestion.

Oppdage gjentakende mønstre i kvalitative data: Det er svært tidkrevende å lytte til alle intervjuene og finne problemer eller prosesser som gjentar seg. LLM-er kan håndtere denne oppgaven svært godt og gå gjennom hundrevis av intervjuer på jakt etter mønstre. Etter min erfaring er Dovetail best på dette.

Klynging, opptelling og poengsetting av tilbakemeldinger: Igjen vil det ta produktteam timer eller til og med dager å manuelt gjøre kvalitative data om til kvantitative data. LLM-er trenger bare noen sekunder på å telle og se hvilke tilbakemeldinger som er vanligst i dataene. De kan også utføre poengsetting ved hjelp av modellen for vektet poengsetting eller RICE.

Til tross for all verdien du får fra disse automatiseringene, anbefaler Craig fortsatt at du ikke stoler for mye på AI når du gjennomfører oppdagelsesarbeid.

«AI vil ikke erstatte intuisjonen din – den hjelper deg med å ta raskere, kunnskapsbaserte beslutninger.»

Jeg er enig med ham. La AI i produktoppdagelsen gjøre det manuelle arbeidet for deg. Men ikke stol på at AI tar de riktige beslutningene uten å kontrollere dem selv først.