Ta sjanser med god samvittighet

Først var vi innom Cynefin-modellen, som handler om at måten vi gjør beslutninger på, henger sammen med hvilken kontekst vi er i. Bruker vi feil tilnærming til feil kontekst, kan det gå galt. Prosjekter passer best når vi er i det klare eller kompliserte hjørnet. Når vi driver med produktutvikling, befinner vi oss derimot som oftest i det komplekse hjørnet av modellen. Vi må omfavne usikkerheten, og god produktutvikling handler ikke om å ha rett hele tiden, men finne ut i tide at vi tar feil.

De to fellene

Deretter var vi innom analyse- og byggefella. Analysefella er når vi bruker for mye tid på å lære og analyse uten å realisere verdi. Byggefella er når vi har bygget masse og pumpet ut features, men ikke skapt noe verdifullt. I begge ender gjør vi masse, men vi skaper ingen verdi. Det kjipe ved å være i en av fellene er alternativkostnaden ved alle de andre tingene vi kunne gjort i stedet som ville skapt verdi for brukerne våre. For å unngå analysefella må vi tåle å leve med litt usikkerhet. For å unngå byggefella må vi erkjenne hvor lite vi egentlig vet.

Risikoer og antagelser

Marty Cagan nevner fire risikoer innen produktutvikling som produktteam må jobbe med å minimere:

• Gjennomførbarhet: klarer vi å lage det?
• Brukbarhet: klarer brukerne å bruke det?
• Brukerverdi: får brukerne noe ut av det?
• Forretningsverdi: er det lønnsomt for bedriften?

Ida Aalen utvider denne lista med tre til:

• Lover og regler: har vi lov til å lage det?
• Levedyktighet: får vi det til å funke i praksis?
• Etikk og bærekraft: er det riktig av oss å lage det?

Deretter gikk vi gjennom teknikker for å senke risikoen og finne antagelsene vi gjør når vi lager produkter.

Pre-Mortem

Pre-Mortem er en teknikk for å finne antakelser, og baserer seg på konseptet post-mortem, bare før det går galt. Konseptet er: spol frem 6 måneder i tid, forestill deg at alt har gått skeis under utviklingen av produktet, og prøv å finne ut akkurat hva som gikk galt. Formuler bekymringene som “for at dette skal gå, er vi avhengige av …”. Bruk deretter dette til å formulere antakelsene deres.

Hva-hvis-regnestykke

For å regne ut hvilke konsekvenser antakelsene våre vil ha, kan man gjøre et hva-hvis-regnestykke. Tegn opp alle steg i en ideell brukerreise, og for hvert steg spør dere selv hvor mange prosent av brukere som i bestcase og worstcase klarer å gjennomføre steget. Gang sammen alle bestcase-estimatene og worstcase-estimatene. Tallene her er ikke viktige, det er bare gjetninger fra teamet, men å se på hvor stort spennet av usikkerhet er kan være nyttig. Der det er stort spenn, finnes det risikable antakelser, så dette kan brukes til å kartlegge hvilke antagelser man burde undersøke nærmere.

Mulighetstrær

Et mulighetstre er en teknikk som kan brukes for å minne produktteam på at det vi lager skal dekke et behov hos brukerne. Man kan skrive en egen artikkel om mulighetstrær, så her velger jeg heller å referere til Teresa Torres dersom du ønsker å lese mer om hva et mulighetstre er. Aalen ga derimot noen praktiske tips vi kunne ta med oss:

• Sørg for at det faktisk er et tre
• Ikke lag treet pent, men bruk det som et arbeidsverktøy for teamet der man driver løpende tankearbeid (f.eks. i digitale verktøy som Miro, Mural eller lignende)
• Hvis det bare er én løsning til en mulighet, er muligheten bare kamuflert som en løsning

Målstyring

Neste på agendaen var målstyring og OKR. Aalen trakk frem ting hva norske produktteam som likte å bruke OKR gjør:

• Ha én tydelig ambisjon (Objective) av gangen.
• Bruk nyttige indikatorer (Key Result).
• Se på ambisjonen hver uke.
• Bruk OKR i kombinasjon med en helsesjekk/helsemetrikker.

Hun nevnte noen gode teknikker for å finne en god ambisjon:

• Den bør være tidsbestemt, for eksempel for et kvartal eller tertial.
• Den bør inneholde eller handle om brukeren.
• Den må være innenfor teamets innflytelse.
• Hvis ambisjonen dere ender opp med er for konkret, spør dere selv “hvorfor skal vi gjøre dette”. Hvis den er for overordnet, spør dere selv “hvordan skal vi gjøre dette”.

Etterhvert gikk vi også inn på ulike indikatorer man kan bruke.

• Sene (lagging) resultatindikatorer: Dette kan eksempelvis være det faktiske forretningsresultat vi ønsker å forbedre. Ettersom de er sene vil det være vanskelig for teamet å styre etter disse indikatorene, og de burde derfor kombineres med andre typer indikatorer.
• Tidlige (leading) resultatindikatorer: Disse indikatorene kommer i forkant av forretningsresultatet, og kan dermed styres etter underveis. De beskriver gjerne hva som må på skje før vi klarer å nå det sene resultatet, og kan hjelpe oss med å vite om vi er på riktig kurs.
• Kvalitetsindikatorer: Brukes for å balansere resultatindikatorene, og fokuserer på kvaliteter som feks ytelse, kundehenvendelser eller brukervennlighet. De kan også inngå i teamets helsemetrikker/KPIer i stedet for som en del av indikatorene for ambisjonen man har satt.
• Fremdriftsindikatorer: Måler fremdrift i aktiviteter som skal til for å nå ambisjonen. Disse kan være nyttige når vi vet at det vi skal levere krever mange måneder arbeid og det tar lang tid før vi kan styre etter noen av de andre indikatorene. Her er det viktig å ikke definere indikatoren som rene TODOs eller gjøremål, ettersom et gjennomført gjøremål ikke sier noe om man har oppnådd ambisjonen man satt seg. Fokuser i så fall på hensikten med gjøremålene, og utform indikatoren slik at den handler om resultatet av gjøremålene. En fremdriftsindikator bør alltid kombineres med en av de andre type indikatorene, ettersom at faren for å havne i bygge- eller analysefella øker dersom vi kun har fremdriftsindikatorer.

Aalen poengterte også at enkelte ting er ikke et mål bare fordi det er viktig, og det er her helsemetrikkene kommer inn. Definer hva som er viktig for produktet og teamet, og når teamet skal agere på det. Eksempler på ting man kan måle er trivsel i teamet, oppetid eller svartid i løsningen, eller reviews fra brukere. Disse tingene er også viktige, men trenger nødvendigvis ikke å være en del av OKRen. Definer grenseverdier for disse målingene, og fordel inn i “soner” (feks en trafikklysmodell) på når man ønsker å agere på de. Hvis helsemetrikken er grønn trenger man ikke å gjøre noe, hvis den er gul burde man undersøke, og hvis den er rød blir dette plutselig den viktigste prioriteringen for teamet, og man slipper alt man har i hendene for å få målingene grønne igjen.

Prioriteringer

Prioriteringer er vanskelig fordi det er vondt å velge bort ting, og fordi vi gjør prioriteringene på usikkert grunnlag. For å prioritere de riktige oppgavene, kan vi kartlegge de i et diagram med innsats og verdi på to akser. Fordi vi ofte undervurderer innsatsen en oppgave krever, og overvurderer verdien den kommer til å skape, ser egentlig diagrammet litt annerledes ut. Her er det viktig å gjøre en miks av lavthengende frukter og større satsninger. Hva man skal gjøre når avhenger av produktstrategien og rammene til teamet.

Vanlige feller når man prioriterer:

• Vi glemmer at prioritering er gjetninger, ikke vitenskap. Vi klarer ikke å tallfeste presist hva som har høyest prioritet.
• Ikke gjør prioritering til en avstemning i teamet, da utviklere ofte er i overtall i et team.
• Ikke løp etter trender, eller kopier de funksjonalitetene konkurrentene våre har blindt. Det er ikke sikkert konkurrentene tilbyr det brukerne egentlig er opptatt av.
• Ikke la brukerne bestille en løsning. Finn behovet bak bestillingen, og løs heller dette.

Veikart

Når man prioriterer på lengre sikt, er ofte roadmaps eller veikart brukt. Tradisjonelle veikart er konkrete på tid og funksjonalitet. Dette fører til at man stadig justerer og endrer deadlines, eller ender opp i byggefella fordi man fokuserer mer på om vi klarte å bygge funksjonaliteten i tide, enn om funksjonaliteten hjalp oss med å oppnå noe.

Det er derimot mulig å lage veikart som er konkrete uten å være detaljerte. Dette kan man gjøre ved å ha veikart over muligheter (opportunities), over ambisjoner eller produktmål (OKRs) eller ved bruk av “Nå, Neste, Senere-veikart”. Felles for alle disse er at de sier noe om hva man ønsker å oppnå eller hvilke problemer man ønsker å løse, ikke hvilken funksjonalitet man skal implementere. I tillegg tillater de å gi en rekkefølge på ting, uten å konkretisere datoer og tidsfrister. Aalen oppsummerte veikart-delen av workshoppen med setningen “det riktige veikartet er det som forventningsstyrer på en måte som gir riktig forventninger.”

Sluttord

Jeg håper dette var en grei gjennomgang av de viktigste temaene fra boka for deg som har lest den før, og en spennende inngang til produktfaget for deg som ikke har gjort det. Det er nå ca 1 år siden jeg leste Bedre Produkter og ca 6 mnd siden jeg deltok på workshoppen. Jeg lærte masse nytt av å lese boka første gang, fikk gjentatt de viktigste poengene på workshoppen, og oppfrisket mange gode poenger nå som jeg har jobbet med å skrive denne oppsummeringen. Disse temaene er fine å komme tilbake til i ny og ne, ettersom man hele tiden gjør seg nye erfaringer fra teamhverdagen som man kan knytte opp til teorien. Personlig legger jeg merke til noe nytt hver gang produktutviklingsteori blir gjentatt. Kanskje leser du denne oppsummeringen på nytt neste jul også, etter et år med nye inntrykk, erfaringer og flere knagger å henge ting på? God jul!