Product discovery - Hvordan finner vi ut om det vi lager har verdi?

Når vi lager digitale produkter, er det et mylder av muligheter. Det er fryktelig mye spennende teknologi og gjerne mange mål som virksomheten skal nå. I andre artikler (og så ofte som mulig ellers), har vi i Team Agile snakket om viktigheten av å styre på effekten dere ønsker å oppnå og ikke det som skal lages. De tverrfaglige teamene myndiggjøres til å velge hva de skal lage selv. Men hvordan skal egentlig de tverrfaglige teamene velge dette? Hvordan tar vi ned risikoen for å lage feil ting?

Utforskning er moderne risikohåndtering

Først kan det være greit å se kort på hvilken risiko vi egentlig snakker om. En mye brukt inndeling er Marty Cagan sine "Four Big Risks" når vi utvikler et produkt:

• Attraktivitet: Vil kunder kjøpe det eller brukere bruke det?
• Brukervennlighet: Vil kundene klare å bruke det?
• Gjennomførbarhet: Vil vi klare å lage det?
• Forretningsrisiko: Fungerer det for virksomheten vår?

Den siste kategorien er kan omfatte flere forskjellige momenter. Vi må vurdere; om produktet passer inn i strategien, om vi klarer å tjene penger på det og om det er innenfor lover, regler og etiske prinsipper virksomheten må forholde seg til. Allikevel liker vi denne enkle inndelingen.

Håndtering av produktrisiko, dreier seg altså om å tidligst mulig og på billigst mulig måte vurdere og håndtere disse fire risikoene. En måte å tilnærme seg dette er bruke de fire risikotypene til å identifisere og prioritere antakelser. Altså først identifiserer teamet hvilke antakelser de har om en løsning innenfor de ulike typene. Deretter vurderes antakelsene etter hvor viktige eller avgjørende de er for produktets suksess og hvor sikker kunnskap de har om de ulike antakelsene. Det kan se slik ut:

Når vi snakker om utforskning i produktutvikling, er håndteringen og reduksjonen av denne risikoen vi snakker om. En oversikt over de kritiske antakelsene, gir et svært godt grunnlag for hypotesedrevet utvikling og ulike eksperimenter for å få bedre innsikt og evidens for ulike løsninger. Allikevel er det verdt å bemerke at det som oftest er mest krevende å vurdere er det som ligger utenfor virksomheten. Altså attraktivitet og brukervennlighet. Innsiktsarbeid og involvering av kundene er nødvendig for å finne ut av dette.

Her er tre kjerneteknikker alle produktteam bør bruke for å forstå mer om produktet sitt og mulige løsninger for videreutvikling:

• Kundeintervjuer
• Dataanalyse
• Prototyping

Kundeintervjuer - fundamentet for å forstå kunden

Helt fundamentalt, er det å snakke med kundene dine. Som en basis, anbefaler vi å snakke med kundene én gang i uka. Teresa Torres, som er blant de fremste på utforskning, anbefaler at du gjør et kundeintervju minst én gang i uka. Du bør altså ha dialog med kundene dine på ulike måter oftere en det.

Kundeintervjuet er en kvalitativ metode for å forstå hvem kundene dine er, og hvilke behov de har. Her dannes en sentral del av forståelsen for hvilke problemer som egentlig er verdt å løse for kunden. Det gir også en svært god anledning til å bygge empati for kunden vi jobber for. Hva er det som er skikkelig irriterende for kunden og hvordan løser de problemet i dag? Disse spørsmålene gir masse avgjørende innsikt når vi skal lage et produkt som de elsker. Da vet vi mye mer om hvilket problem som er verdt å løse og hvordan vi kan løse det på en måte som kunden elsker.

Dataanalyse (analytics)

Den neste kjerneteknikken i produktutvikling er kvantitativ analyse av brukeradferd eller analytics som vi liker å kalle det. Her er poenget å forstå hvordan kundene eller brukerne interagerer med produktet ditt. Verktøy som Google analytics, Amplitude, Mixpanel og en haug flere kan gi god innsikt i kundene dine. Analytics gir svar på spørsmål som hvor mange det er som bruker produktet, hvor ofte de bruker det og hvilke deler av produktet brukes mest. Det er viktig grunninnsikt.

Figur 1 Her er et eksempel-dashboard for et Saas-produkt. Dashboardet viser adferden til nye brukere, med konverteringsrater mm. Et felles dashboard med analyse av brukeradferd er svært nyttig for et produktteam. Bilde fra https://docs.mixpanel.com/docs/boards/overview

Men det blir aller mest nyttig om det knyttes opp mot effektmål teamet har. For eksempel om det er en salgstrakt hvor en måler hvor i flyten brukerne faller fra. Det kan også være bruken av sentrale funksjoner som selskapet har en hypotese om at vil øke inntjeningen. Et eksempel er økt bruk av en del av produktet, ettersom selskapet har en hypotese om at dette øker salget.

Vi kan også bruke analytics til å A/B-teste ulike løsninger - gjerne i kombinasjon med feature flags (for å bruke flere gode norske ord). Sistnevnte gir anledning til å skru av og på en løsning, men også å skru det på for deler av brukerbasen. Slik kan vi sammenligne dataene; hvilken løsning fører til størst andel gjennomførte kjøp? Det forutsetter riktignok et stort antall brukere for å få gode svar.

Denne demoen av produktet DoubleLoop gir en del gode eksempler på hvordan analytics kan brukes som en integrert del av målstyringen for et eller flere team. Det avanserte oppsettet er definitivt for viderekomne, men det gir et innblikk i et tankesett som mange team kan ha nytte av.

Prototyping

En helt sentral del av all god utforsking bør være prototyping. I utforskningen bruker vi protoyper til å teste en rekke antakelser vi gjør og redusere de fire risikoene ganske konkret. Det er fort gjort å tenke på en prototype som en modell som skal illustrere hele det visuelle uttrykket og brukerflyten i et produkt (high-fidelity prototype, om du vil). Disse er nyttige til sitt bruk. Men ved å bryte opp produktet og ulike antakelser vi har i produktet og bruke prototyper til å teste og lære, får vi mye raskere læring enn om vi skal lage en prototype av hele løsningen først.

Når vi snakker om prototyper, liker vi å snakke om det i mer utvidet forstand enn tradisjonelle prototyper. Noen teknikker som ikke alltid omtales som prototyper er:

• Proof of concept: En teknisk demonstrasjon av at vi klarer å bygge det vi ønsker. Her er det selvfølgelig fortrinnsvis viktig å teste den delen av den tekniske løsningen som har størst risiko knyttet til seg. Eksempelvis kan dette være å vise at vi klarer å koble løsningen til et API og få data til å flyte.
• Pitch med tegning: En fortelling og rask tegning på en tavle om hvordan et produkt vil fungere til en kunde eller mulig kunde er en fin og svært enkel måte å få innsikt. Bare vær obs på at du ikke bare spør "høres det bra ut?". Du må være bevisst på hva du egentlig prøver å finne ut av. Spørsmål som "hva ville du betalt for det?" er bedre egnet til å få en realistisk forståelse av verdien.
• Brukerflyt: En enkel skisse av rekkefølgen brukeren interagerer med produktet på. Kan bidra til viktig innsikt både for om kunden synes det gir mening, men også om det fungerer for virksomheten: Hvordan samsvarer flyten med arbeidet til andre team? Ivaretas nødvendige juridiske forpliktelser? Osv.

Protoyping, slik vi tenker på det, er altså en viktig del av utforskingsarbeidet. Her tester vi antakelsene våre og minimerer risiko effektivt. Vi får mye raskere og bedre innsikt i risikoene våre: om det vil gi verdi for kunden, om de klarer å ta det i bruk, om vi klarer å lage det og om det fungerer for virksomheten. Det kan brukes i teamet, med interessenter i organisasjonen og med kunder for å avdekke ulike typer risiko. Prototypingen kan både gjøres kvalitativt og kvantitativt.

Nå er det også stadig flere AI-verktøy som gjør at vi enkelt kan lage relativt gode prototyper svært raskt. Det gir helt andre muligheter til å ta i bruk prototyper, brukerteste og redusere risiko i en helt annen skala enn tidligere. Bare vær bevisst på hva du tester med ulike prototyper, så vil det være enklere å lage en enkel nok prototype - og teste den på en god måte.

Prototypetesting av kundeverdi i praksis - BeeZmart

Team Agiles egen Henrik Byremo stod i spissen for å teste ut verdien av et konsept for birøktere. Idéen var at en sensor i bikuben kunne hjelpe birøktere med å opprettholde gunstige forhold i bikubene uten å forstyrre biene. Dermed kunne honningproduksjonen økes. Produktet, med sensor og dashboard ble testet gjennom å promotere en prototype av produktet og se hvordan kundene responderte.

Kundene ble vist til en landingsside hvor konseptet ble presentert som en prototype. Deretter kunne de oppgi kontaktinfo for å få mer informasjon om produktet. Teamet hadde også en hypotese om at en del ville sende e-post og etterspørre mer informasjon om produktet. Gjennom målinger av antall besøkende på nettsiden, andel som meldte interesse gjennom å oppgi kontaktinfo eller sende e-post, kunne produktteamet evaluere hvor stor verdi dette ga for kundene i målgruppen.

Slik kunne teamet teste ut attraktivitetsrisikoen uten å ha laget selve løsningen. Og de kunne ta en mye mer informert beslutning på hvorvidt det var verdt å lage det.

Gjør utforskningen tverrfaglig og kontinuerlig!

I en verden med relativt faste team, har vi fordelen at vi kan jobbe parallelt med å bygge produktet og utforske ulike muligheter. Samtidig ser vi at mange team går i fella hvor dette ansvaret fordeles svært ujevnt på teamet. Typisk løper produktleder og designer i forkant og utforsker nye muligheter, mens utviklerne sitter igjen med ansvaret for å lage de tingene de har funnet frem til. Det gjør at vi hverken får teknisk kompetanse med i tidlig vurdering av gjennomførbarhet eller til å gi innspill til løsninger. Risikoen for misforståelser og overleveringer internt i teamet øker da også betraktelig.

Dermed anbefaler Team Agile alltid at hele teamet inkluderes i utforskningsarbeidet. Aktivitetene i utforskning er svært godt egnet til å fremme tverrfaglig samarbeid og dermed også utvikle teamet. Et felles eierskap til veien videre er også sentralt for felleskapsfølelsen og motivasjonen til teammedlemmene. Tidsbruken vil naturligvis være litt ulik innad i teamet, så vi anbefaler å sette en produkttrio med produktleder, designer og utvikler som har hovedansvaret for å drive dette arbeidet og rask rytme på det.

Utforskingen bør heller ikke gjøres som en "fase". Jo lenger det er siden vi snakket med kunden sist, jo større er risikoen for at vi antar ting vi tror de mener og at innsikten vår er utdatert. I produktutviklingsprosessen gjør vi hele tiden valg og vurderinger, slik at det å ha fingeren på pulsen gir et kjempefortrinn. En god tommelfingerregel er at du bør snakke med kundene ukentlig.

Team Agile jobber med utforskning som en sentral del av hvordan vi akselererer verdiskapingen. Vil du lære mer om dette og hvordan vi coacher team og ledere i produktledelse og utforskning slik at de tar ned risiko og øker verdiskapingen? Ta kontakt!