6 måter å prioritere produktfunksjoner på (+ tips & eksempler)

Hvis du spør meg, er to av de viktigste ferdighetene innen produktledelse å kjenne prioriteringene dine og å si «Nei.»

I dag skal vi gå i dybden på førstnevnte (ettersom sistnevnte fortjener en egen veiledning) og hjelpe deg med å prioritere arbeidet ditt og sørge for at alle er samkjørte med prioriteringene dine.

En viktig merknad om rammeverk for prioritering av produktfunksjoner

Før vi begynner å utforske måtene du kan prioritere etterslepet ditt på, er det ett viktig tips jeg må dele med deg.

Prioriteringsrammeverk er ikke ment å tas bokstavelig.

Nei, du trenger ikke å bruke det nøyaktig slik det er skrevet i boken (eller denne veiledningen). Produktet du leder, kan være helt forskjellig fra produktene forfatteren ledet da de skrev boken sin. Ulike produkter betyr ulike realiteter og behov. Derfor er det helt greit å tilpasse rammeverket til dine egne behov. Et godt rammeverk er tross alt det som fungerer for deg.

Rammeverk for produktprioritering du kan prøve

Visste du at det finnes et Thanos-prioriteringsrammeverk? Du sletter ganske enkelt halvparten av alle funksjonene i etterslepet ditt, helt tilfeldig!

Vel, det fant jeg på. Men du skjønner poenget mitt. Det finnes rett og slett altfor mange rammeverk der ute. Så mange at jeg definitivt ikke vil kunne dekke dem i denne veiledningen. For å være ærlig tror jeg heller ikke at du er her for å memorere en million rammeverk.

Derfor skal jeg i stedet gå gjennom dem jeg personlig har brukt i min daglige produktledelse, og dele et par praktiske tips med deg for hvert av dem. Det er også verdt å vurdere hvordan du kan bruke KI i prioriteringen av funksjoner sammen med disse rammeverkene.

1. Kano-modellen

Denne prioriteringsmetoden har fått navnet sitt etter den talentfulle japanske forfatteren og ledelseskonsulenten Noriaki Kano. Det fine med tilnærmingen hans er hvor enkel den er.

Kano foreslo å kategorisere funksjonene dine i disse gruppene:

• Må-ha: Dette er grunnleggende funksjoner i produktet ditt, og fraværet av dem vil skape en dårlig kundeopplevelse (dårlig kundebevaring og frafall er garantert). Et godt eksempel på dette er chattefunksjonen i Intercom eller søk etter kundetilbakemeldinger i G2.
• Ytelse: Disse funksjonene skaper brukerverdi basert på hvor utbredte de er. Flere av dem betyr mer verdi. Se bare på batterikapasiteten og rekkevidden til en moderne elbil. Bedre rekkevidde skaper (generelt) mer verdi for sjåførene. Et annet eksempel er antallet integrasjoner i Zapier.
• Attraktive: I stedet for å tilføre direkte verdi og løse brukernes problemer fokuserer disse funksjonene på å gjøre produktene dine mer elskverdige. Vakkert utformede deler av produktvisjonen i et prosjektstyringsverktøy eller skinnseter i en bil er eksempler på dette.

Hvis vi skulle visualisere forholdet mellom utbredelsen av disse typene funksjoner og kundetilfredsheten de skaper, ville det sett omtrent slik ut.

Her kan vi se at ytelsesfunksjoner er lineære av natur (derfor gir flere av dem mer verdi). Må-ha-funksjoner skaper derimot ikke mye ekstra verdi. I stedet skal de fjerne misnøyen hos brukerne dine.

Til slutt er den attraktive kategorien der for å gi deg et ekstra løft i tilfredshet. Men den vil ha null effekt hvis du har gjort en dårlig jobb med noen av «må-ha»-funksjonene dine.

Kano i praksis

Hvordan bruker du Kano-modellen i praksis? Etter min erfaring brukes Kano sjelden i prioriterings- eller idémyldringsmøter. Grunnen er at dette er noe svært intuitivt, og du trenger ikke å tegne det på en tavle og be folk klassifisere funksjonene sine basert på disse tre kategoriene.

I stedet lærer du vanligvis interessentene dine å tenke på Kano-måten. Takket være dette vil de, før de kommer til deg med en forespørsel om en ny funksjon, vurdere ideen gjennom dette rammeverket i hodet og avgjøre om det er noe det er verdt å utforske eller ikke.

På denne måten delegerer du noe av arbeidet med prioritering av funksjoner til interessentene dine og sparer masse tid på lange idémyldringsøkter.

2. MoSCoW-metoden

MoSCoW-metoden er blant de mest populære metodene for å prioritere funksjoner. De to grunnene til populariteten er enkelhet og effektivitet.

For å bruke denne metoden trenger du bare å se på hver funksjon i listen din og gi den én av disse fire prioritetene:

• Må ha
• Bør ha
• Kan ha
• Skal ikke ha

Du tildeler vanligvis disse prioritetene basert på en kombinasjon av faktorer, blant annet verdien det skaper for brukerne, forretningsverdien, strategisk samsvar, implementeringskompleksitet og andre faktorer.

Slik vil en typisk funksjonsliste for en musikkstrømmetjeneste se ut hvis du bruker MoSCoW på den.

• Her har vi gitt frakoblet modus prioriteten «må ha», fordi vi regner med at mange av brukerne våre vil lytte til musikk om bord på et fly.
• VR-opplevelser fikk derimot prioriteten «skal ikke ha», fordi det er ganske vanskelig å implementere, og svært få brukere har VR-briller som de kan oppleve det med.

MoSCoW i virkeligheten

Selv om du fint kan bruke MoSCoW til å hjelpe deg med å lede prioriteringsmøtene, finnes det en ulempe som gjør metoden mindre effektiv i slike tilfeller.

Ettersom prioriteten er basert på en kombinasjon av flere faktorer, blir det ganske tidkrevende for hvert teammedlem å forklare begrunnelsen bak produktbeslutningene sine. Etter min erfaring er MoSCoW-økter ganske langsomme og ineffektive sammenlignet med andre rammeverk.

Men det betyr ikke at jeg ikke liker MoSCoW. Faktisk er det rammeverket jeg bruker oftest. Favorittområdet mitt for å bruke MoSCoW er funksjonslisten i et PRD.

Jeg gir vanligvis leserne kontekst om brukerverdien, teknisk kompleksitet og andre faktorer i dokumentet før jeg begynner å liste opp funksjonene. Når de ser «Må ha» ved siden av en av dem, har de derfor konteksten de trenger for raskt å forstå begrunnelsen bak beslutningen min.

På denne måten gir MoSCoW meg en lettfattelig funksjonsliste i et produktkravsdokument.

3. RICE-metoden

I motsetning til de to foregående metodene er RICE-poengmodellen litt mer strukturert og mindre avhengig av beslutningstaking basert på intuisjon. Den identifiserer fire ulike prioriteringsfaktorer og lar deg kvantifisere og evaluere hver av dem separat. Disse faktorene er:

• Rekkevidde: Dette representerer andelen av brukerne dine som funksjonen vil påvirke.
• Påvirkning: Omfanget av selve påvirkningen.
• Sikkerhet: Viser om du er sikker på at personene som nås, vil få denne påvirkningen.
• Innsats: Dette er tidsrammen utviklings- og produktteamet ditt trenger for å gjøre funksjonen klar.

Det du vanligvis gjør, er å velge en funksjon og deretter gi en poengsum mellom 0 og 10 for hver av disse fire faktorene. Etterpå beregner du RICE-poengsummen med denne formelen.

Til slutt sorterer du funksjonslisten etter hovedmålet i dette rammeverket – RICE-poengsummen (høyere poengsum = høyere prioritet). Slik ser resultatet av en RICE-prioritering ut.

• I denne listen ser vi at det nye brukergrensesnittet har fått høyest poengsum takket være lav innsats og høy rekkevidde/påvirkning.
• Skysynkroniseringsfunksjonen ligger derimot nederst på listen på grunn av den høye innsatsen teamet ditt må legge ned for å implementere den.

RICE-poengsum i virkeligheten

Jeg har stadig nevnt at verken MoSCoW eller Kano passer best til prioriterings- og idémyldringsmøter. Men hvilket rammeverk bruker jeg i slike tilfeller? Det er RICE!

Ved å gi separate poengsummer for hver faktor gjør du det enklere for folk å presentere begrunnelsen bak beslutningene sine under disse møtene (noe som mangler i MoSCoW). I tillegg kan du delegere poengsettingen av hver faktor til de teammedlemmene som har mest kunnskap på området.

Produktutviklingsteamet ditt er for eksempel best egnet til å gi en poengsum for innsats. Dataanalytikerne dine har derimot den beste forståelsen av den potensielle rekkevidden til denne funksjonen.

4. Kartlegging av brukerhistorier

Teknisk sett er kartlegging av brukerhistorier ikke et prioriteringsrammeverk. I stedet brukes det til å organisere arbeidet som skal gjøres for teamet ditt, og avdekke eventuelle funksjoner du må legge til for å få komplette brukerreiser.

For å lage et historiekart lister du opp de viktigste brukeraktivitetene (eller jobbene) og skriver deretter ned oppgavene brukerne må fullføre for hver av dem. Etterpå lister du opp alle funksjonene du må bygge for å la brukerne fullføre disse oppgavene. Du kan enten gjøre dette med lapper på en tavle eller bruke et av de mange dedikerte verktøyene for produktledere.

Slik ser kartet ut for en musikkstrømmetjeneste.

Du kommer sannsynligvis ikke til å prioritere så mye på dette tidspunktet.

Prosessen med å skrive ned de nødvendige funksjonene for hver jobb vil likevel hjelpe deg med prioriteringen, ettersom du vil innse at det mangler funksjoner for bestemte aktiviteter (som er viktige for deg).

Deretter legger du raskt til disse manglende funksjonene i oppgavekøen og flytter dem til toppen for å sikre at du har dekket den aktuelle aktiviteten for brukerne dine.

I eksempelet ovenfor har vi et MVP-historiekart under aktiv utvikling (ferdige historier har et hakemerke ved navnet). Når vi ser på det, vil vi se at aktiviteten Kontoadministrasjon er ufullstendig, siden vi ennå ikke har bygget innlogging med sosiale medier.

Før vi begynner å arbeide med søk etter artister/album, bør vi derfor først fullføre aktiviteten for kontoadministrasjon.

Historiekart i virkeligheten

Akkurat som RICE passer historiekart godt til prioriterings- og idédugnadsmøter. En av de største fordelene ved å bruke dette rammeverket er evnen til å bringe brukerperspektivet inn i møterommet.

Ved å se på brukeraktivitetene og oppgavene er det mindre sannsynlig at teammedlemmene dine foreslår funksjonsideer som er irrelevante for kundenes behov og smertepunkter. Selv om de gjør det, kan du enkelt gi dem lav prioritet, med tanke på at disse funksjonene ikke hjelper brukerne med å fullføre oppgavene sine.

5. Mulighetspoengberegning

Strukturelt ligner mulighetspoengberegning på RICE. I motsetning til motstykket er imidlertid kriteriene i systemet for mulighetspoengberegning ikke hugget i stein, og det er opp til deg å velge dem.

For å samordne veikartet på høyt nivå med ledelsen kan du for eksempel vurdere å bruke samsvar med produktstrategien, gjennomførbarhet og potensielle inntekter som kriterier. Slik ser et veikart prioritert med dette rammeverket ut.

Her har vi brukt en skala fra 0 til 5 for å gi poeng til hver faktor og beregnet summen av alle faktorene for hvert element på listen.

Poengkort i virkeligheten

Ettersom du kan velge dine egne kriterier, er poengkort perfekte for møter der flere team skal samordnes.

Hvis du for eksempel trenger å samordne veikartet med juridisk- og sikkerhetsteamene dine og høre deres syn på prioriteringer, velger du kriterier som er relevante for dem (f.eks. risiko for søksmål kontra forretningsverdi). Med markedsteamet kan du derimot bruke innsats, kostnad, samsvar med forretningsmål, markedsrekkevidde og trygghet som kriterier.

6. Innsatsmatrise

Husker du Eisenhower-matrisen som brukes til å prioritere dine personlige initiativer? Innsatsmatrisen er en versjon av den som er bedre tilpasset arbeid med nye produktfunksjoner.

Det fulle navnet er matrisen for verdi kontra innsats, siden den kan visualisere forholdet mellom disse to faktorene for hver av oppgavene dine. Slik ser den ut.

Du plasserer innsats på Y-aksen og kundeverdi på X-aksen. Deretter deler du den, akkurat som Eisenhower-matrisen, inn i 4 kvadranter og plasserer funksjonene dine i hver av dem basert på verdi og innsats. Deretter prioriterer du oppgavene i følgende rekkefølge:

1. Raske gevinster (funksjon med stor innvirkning som du kan gjøre nå)
2. Store prosjekter (dine strategisk viktige funksjoner)
3. Utfyllinger (potensielle funksjoner med enkel implementering som kan vurderes senere)

Funksjoner i kvadranten for tidstyver vil du vanligvis forkaste, siden det ikke finnes noen grunn til å ha dem i oppgavekøen i det hele tatt.

Arbeidsmatrisen i praksis

Både den største fordelen og ulempen med dette rammeverket ligger i enkelheten.

Det er en fordel, ettersom du enkelt kan forklare prioriteringsprosessen til personene i rommet og umiddelbart begynne å velge de riktige funksjonene ved hjelp av den.

Ulempen er at arbeidsmatrisen ikke viser de ulike faktorene som spiller en viktig rolle i prioriteringen (sikkerhet, rekkevidde, avhengigheter osv.).

Derfor er dette rammeverket best egnet for korte avklaringsmøter der detaljene ikke er viktige (ettersom dere vanligvis vil ha en mer grundig økt med RICE som oppfølging).

Sørg for at interessentene dine er samkjørte med produktveikartet ditt

Det er viktig å prioritere arbeidet ditt. Men det vil være uten verdi hvis du ikke har fått alle til å samles rundt prioriteringene dine. Mange av rammeverkene vi har diskutert i dag, er av samarbeidende art og sørger automatisk for at alle er samkjørte.

Men hvis du velger det som ikke krever at du samler alle interessentene dine i samme rom, må du sørge for at du har delt den prioriterte listen din med relevante personer og samkjørt den med forventningene og behovene deres.

Ikke glem å abonnere på nyhetsbrevet vårt for flere ressurser og veiledninger om produktledelse, samt de nyeste podkastene, intervjuene og annen innsikt fra bransjeledere og eksperter.