Om å flytte nålen

Når julenissen farer gjennom natten med sleden sin, vet han at dersom han kjører seg vill, kan han alltids finne veien ved å sikte på Nordstjernen. Men av og til er ikke Nordstjernen synlig. Da vet julenissen at det er smart å ha noen andre, mer nærliggende stjerner å navigere etter. Slik kommer han seg alltid dit han skal til slutt.

En virksomhet sin Nordstjerne er som regel formulert i kroner og øre, og egner seg dårlig for et produktteam som skal navigere seg i riktig retning.

Akkurat som julenissen, trenger et produktteam noe som er mer nærliggende og innen rekkevidde. Noe som kan fortelle om man er på riktig vei mot Nordstjernen langt der fremme. Der kommer produktmålet inn i bildet.

Produktmålet 🔥

Et produktmål er en proxy på et mer langsiktig virksomhetsmål - hvis vi flytter nålen på produktmålet nå, tror vi at nålen på virksomhetsmålet vil flyttes senere. Produktmålene er altså mer responsive, og ettersom de skal være innenfor teamets rekkevidde, er de ofte sentrert rundt brukeratferd i det digitale produktet som teamet jobber med.

Et produktmål tjener flere viktige formål, blant annet:

1. Prioriteringsjobben blir enklere - både i forhold til hva man skal bygge, og hvordan man skal bygge det. Denne jobben er det vanskeligste jeg gjør som produktleder, og dette er sykt viktig!

2. Man bygger bro mellom team og ledelse, og unngår gnisninger mellom dem

3. Produktmålet legger basis for læring over tid. Ved å ha flere delmål å navigere etter, vil man opparbeide seg innsikt i hvilke metrikker som flytter nålen på virksomhetsmålet, og hvilke som ikke gjør det.

Det kan være skikkelig vanskelig å finne gode produktmål. Jeg har plukket med meg noen erfaringer underveis som andre forhåpentligvis kan ha litt nytte av.

En rotete virkelighet 🤯

På skisser fremstår det ofte som at man kan finne ett produktmål, som har en direkte og tydelig link til ett virksomhetsmål. Én-til-én, ryddig og fint. Men virkeligheten er ofte langt mer rotete enn det. Mål henger sammen med mål, og har gjensidig påvirkning på hverandre.

En aktør jeg arbeidet med i underholdningsbransjen ønsket å redusere abonnementsoppsigelser. Etterhvert som vi dukket ned i materien, identifiserte vi en rekke mulige produktmål: andel brukere som ser innhold >X ganger per uke, tid fra sign-up til første innhold blir sett, andel brukere som ser X ulike typer innhold, antall brukere som setter abonnement på pause, andel brukere som favoriserer >X innhold, og så videre.

Selv om alle disse produktmålene er mer angripelige enn virksomhetsmålet om færre oppsigelser, er noen av dem mer responsive og påvirkelige enn andre. Produktmål er ikke enten leading eller lagging - de kan plasseres inn på et spektrum. Velg et produktmål som er så leading som mulig, og visualiser hvordan de påvirker hverandre. Ved å innføre flere ledd i resultatkjeden vil man lære mer over tid.

Vi innså videre at en del features vi hadde pratet om og vurdert, trolig ville treffe flere av disse produktmålene samtidig. Det er helt greit at en feature treffer flere mål, men ta en ekstra sjekk på om det man tenker på som en feature egentlig er flere små løsninger pakketert sammen. Dersom en feature kan splittes i mindre løsninger som adresserer forskjellige mål, er det en god ting.

Hvordan det av og til føles å lete etter produktmålet.

Mangel på innsikt 📈

Det er ikke alltid tilfelle at man sitter med en meny av mulige produktmål man allerede har data på, og at man bare kan velge den man har mest lyst på. Dersom man mangler innsikt i hva brukerne egentlig foretar seg, blir jobben vanskeligere.

Jeg rådgir en virksomhet innen transport og mobilitet. De har flere virksomhetsmål knyttet til å redusere kostnader, eksempelvis rundt skader på kjøretøy og forbruk på drivstoff. Utfordringen i å sette produktmål er at vi mangler en del innsikt rundt hvordan de digitale produktene faktisk brukes. Vi har rett og slett ikke så mange gode leading metrikker å velge mellom fra start. Dette er selvsagt også en vanskeligere øvelse for en virksomhet hvor mye av det som leveres av verdi, foregår i en fysisk fremfor en digital verden.

Det som har fungert bra for oss her, er å ikke la mangelen på innsikt stoppe oss; vi jobber ut fra det vi har. Vi vet eksempelvis noe om hvordan skader rapporteres inn. Dette er noe teamet kan påvirke, og som er responsivt. Påvirker det skadekost? Trolig, ikke 100% sikkert - men vi begynner der. Samtidig erkjenner vi at vi trenger mer innsikt for å lære mer over tid, og tar en liten investering nå i å få opp mer analytics rundt det vi lager i skrivende stund.

Lett å gå seg bort 🌲

Utgangspunktet for å begynne med produktmål er ofte en backlog. Man prøver å bygge seg nedenfra og opp ved å sette noen forventede effekter på features. Dette kan være nyttig, men man må være forsiktig så man ikke går seg bort.

Da jeg arbeidet med dette hos en fintech-aktør, gikk vi oss bort. Vi hadde nærmere 200 ting i Jira-backloggen med svært varierende grad av utbrodering og forklaring. Så vi brettet opp ermene og gikk i gang. Som den årvåkne leser sikkert har skjønt lenge før vi gjorde det: det var en stor jobb. Ikke bare skulle alt forstås, man skulle også synse seg frem og tilbake om hva som var effekten man ønsket å skape. Detaljfokuset var veldig lite konstruktivt. "Dette kan man ikke vite sikkert" og "Dette måler vi jo ikke skikkelig nå" er eksempler på ting som ble sagt under arbeidet.

De fleste backlogger har et par gullkorn, men det ligger også mye der som bare har blitt plassert der en gang og som trolig aldri vil bli gjort. Jeg ville anbefalt en rask screening og lett sparring rundt produktmål basert på dette, men ikke bruk for mye tid. Kombiner det heller med en ovenfra-og-ned tilnærming der man ser på det som måles allerede og jobber ut fra det. Arbeid med produkt er litt grisete til tider, og det er greit. Jobb opp og ned, frem og tilbake, juster.

Godt nok 🥳

Uansett hvor mye man tenker og analyserer, blir man ikke kvitt all usikkerhet. En feature vil til syvende og sist alltid være en kvalifisert gjetning på at man vil flytte nålen. Poenget er at gjetningene blir bedre over tid. Derfor er fellesnevneren i alle disse situasjonene at det gjelder å si "godt nok" og komme i gang. Man har sjelden privilegiet til å sette alt på pause for å tenke seg om godt og lenge - og det tror jeg heller ikke er smart. Disse konseptene kommer til live når man jobber med dem.