6 måder at prioritere produktfunktioner på (+ tips & eksempler)

Hvis du spørger mig, er to af de vigtigste kompetencer inden for produktledelse at kende dine prioriteter og at sige "Nej."

I dag går vi i dybden med førstnævnte (da sidstnævnte fortjener sin egen guide) og hjælper dig med at prioritere dit arbejde og holde alle afstemt efter dine prioriteter.

En vigtig bemærkning om rammeværk til prioritering af produktfunktioner

Før vi begynder at undersøge måder at prioritere din backlog på, er der ét vigtigt tip, jeg gerne vil dele med dig.

Rammeværk til prioritering skal ikke tages bogstaveligt.

Nej, du behøver ikke bruge det på præcis den måde, det er skrevet i bogen (eller denne guide). Det produkt, du leder, kan være helt anderledes end dem, forfatteren ledede, da de skrev deres bog. Forskellige produkter betyder forskellige virkeligheder og behov. Derfor er det helt fint at tilpasse rammeværket til dine egne behov. Når alt kommer til alt, er et godt rammeværk det, der fungerer for dig.

Rammeværk til produktprioritering, du kan prøve

Vidste du, at der findes et Thanos-rammeværk til prioritering? Du sletter bare tilfældigt halvdelen af alle funktioner i din backlog!

Det fandt jeg på. Men du forstår min pointe. Der findes simpelthen for mange rammeværk derude. Så mange, at jeg bestemt ikke vil kunne dække dem i denne guide. For at være ærlig tror jeg heller ikke, at du er her for at memorere en million rammeværk.

Så i stedet vil jeg gennemgå dem, jeg personligt har brugt i min daglige produktledelse, og dele et par praktiske tips med dig til hvert af dem. Det er også værd at overveje, hvordan du kan bruge AI til prioritering af funktioner sammen med disse rammeværk.

1. Kano-modellen

Denne prioriteringsmetode har fået sit navn efter den talentfulde japanske forfatter og managementkonsulent Noriaki Kano. Det smukke ved hans tilgang er dens enkelhed.

Kano foreslog at kategorisere dine funktioner i disse grupper:

• Skal være der: Dette er grundlæggende funktioner i dit produkt, og deres fravær vil skabe en dårlig kundeoplevelse (dårlig fastholdelse og kundefrafald er garanteret). Et godt eksempel på dette er chatfunktionen i Intercom eller søgningen efter kundefeedback i G2.
• Ydeevne: Disse funktioner skaber brugerværdi baseret på deres omfang. Flere af dem er lig med mere værdi. Se blot på batterikapaciteten/rækkevidden for en moderne elbil. Bedre rækkevidde skaber (generelt) mere værdi for bilister. Et andet eksempel er antallet af integrationer i Zapier.
• Attraktive: I stedet for at tilføre direkte værdi og afhjælpe brugernes problemer fokuserer disse funktioner i stedet på at gøre dine produkter mere elskelige. Smukt designede sektioner om produktvisionen i et projektstyringsværktøj eller lædersæder i en bil hører blandt disse.

Hvis vi skulle visualisere forholdet mellem udbredelsen af disse typer funktioner og den kundetilfredshed, de skaber, ville det se nogenlunde sådan her ud.

Her kan vi se, at ydeevnefunktioner er lineære af natur (derfor giver flere af dem dig mere værdi). Funktioner, der skal være der, skaber derimod ikke en masse ekstra værdi. I stedet skal de fjerne utilfredsheden hos dine brugere.

Endelig er den attraktive kategori der for at give dig et ekstra tilfredshedsløft. Men den vil have nul effekt, hvis du har rodet med nogle af dine "skal-være-der"-funktioner.

Kano i virkeligheden

Hvordan anvender man Kano-modellen i virkeligheden? Efter min erfaring bruges Kano sjældent i prioriterings- eller brainstormingsmøder. Årsagen er, at det er noget, der er meget intuitivt, og du behøver ikke tegne det på whiteboardet og bede folk om at klassificere deres funktioner ud fra disse tre kategorier.

I stedet vil du normalt lære dine interessenter at tænke på Kano-måden. Takket være dette vil de, før de kommer til dig med en anmodning om en ny funktion, køre idéen gennem dette rammeværk i hovedet og beslutte, om det er noget, der er værd at undersøge, eller ej.

På denne måde uddelegerer du noget af arbejdet med prioritering af funktioner til dine interessenter og sparer masser af tid på lange brainstormingssessioner.

2. MoSCoW-metoden

MoSCoW-metoden er blandt de mest populære metoder til prioritering af funktioner. De to årsager til dens popularitet er enkelhed og effektivitet.

For at anvende denne metode skal du blot se på hver funktion på din liste og give den én af disse fire prioriteter:

• Skal have
• Bør have
• Kan have
• Vil ikke have

Du tildeler normalt disse prioriteter baseret på en kombination af faktorer, herunder den værdi, det skaber for brugerne, forretningsværdi, strategisk tilpasning, implementeringskompleksitet og andre faktorer.

Sådan vil en typisk liste over funktioner for en musikstreamingtjeneste se ud, hvis du anvender MoSCoW på den.

• Her har vi tildelt offlinefunktionen prioriteten “skal have”, fordi mange af vores brugere vil lytte til musik om bord på et fly.
• VR-oplevelser fik derimod prioriteten “vil ikke have”, fordi de er ret svære at implementere, og meget få brugere har VR-headset til at opleve dem.

MoSCoW i virkeligheden

Selvom du sagtens kan bruge MoSCoW til at styre dine prioriteringsmøder, er der en ulempe, som gør metoden mindre effektiv i sådanne situationer.

Da prioriteten er baseret på en kombination af flere faktorer, bliver det ret tidskrævende for hvert teammedlem at forklare rationalet bag sine produktbeslutninger. Efter min erfaring er MoSCoW-sessioner ret langsomme og ineffektive sammenlignet med andre rammeværk.

Men det betyder ikke, at jeg ikke kan lide MoSCoW. Faktisk er det det rammeværk, jeg bruger oftest. Mit foretrukne sted at bruge MoSCoW er funktionslisten i et PRD.

Jeg giver normalt læserne kontekst om brugerværdi, tekniske kompleksiteter og andre faktorer i dokumentet, før jeg går videre til at liste funktionerne. Så når de ser “Skal have” ved siden af en af dem, har de konteksten til hurtigt at forstå rationalet bag min beslutning.

På denne måde giver MoSCoW mig en letforståelig funktionsliste i et produktkravsdokument.

3. RICE-metoden

I modsætning til de to foregående metoder er RICE-scoringsmodellen lidt mere struktureret og mindre afhængig af intuitiv beslutningstagning. Den identificerer fire forskellige prioriteringsfaktorer og lader dig kvantificere og evaluere hver af dem separat. Disse faktorer er:

• Rækkevidde: Det repræsenterer den andel af dine brugere, som denne funktion vil påvirke.
• Effekt: Størrelsen af selve effekten.
• Tillid: Viser, om du er sikker på, at de personer, der nås, vil få denne effekt.
• Indsats: Det er den tidsramme, som dit udviklings- og produktteam har brug for, før denne funktion er klar.

Det, du normalt gør, er at vælge en funktion og derefter tildele en score mellem 0-10 for hver af disse fire faktorer. Bagefter beregner du RICE-scoren med denne formel.

Til sidst sorterer du din liste over funktioner efter dette rammeværks primære måleenhed – RICE-scoren (højere score = højere prioritet). Sådan ser resultatet af en RICE-prioritering ud.

• På denne liste kan vi se, at den nye brugergrænseflade har fået den højeste score takket være den lave indsats og den høje rækkevidde/effekt.
• Skysynkroniseringsfunktionen ligger derimod nederst på listen på grund af den store indsats, det vil kræve for dit team at implementere den.

RICE-score i virkeligheden

Jeg har flere gange nævnt, at hverken MoSCoW eller Kano er de bedste valg til prioriterings- og brainstormingmøder. Men hvilket rammeværk bruger jeg i sådanne situationer? Det er RICE!

Ved at give separate scorer for hver faktor gør du det lettere for folk at fremlægge rationalet bag deres beslutninger under disse møder (noget, der mangler i MoSCoW). Desuden kan du uddelegere vurderingen af hver faktor til de teammedlemmer, der har mest viden om det pågældende område.

For eksempel er dit produktudviklingsteam bedst egnet til at give en score for indsatsen. Dine dataanalytikere har derimod den bedste forståelse af den potentielle rækkevidde for denne funktion.

4. Kortlægning af brugerhistorier

Teknisk set er kortlægning af brugerhistorier ikke en prioriteringsramme. I stedet bruges den til at organisere det arbejde, der skal udføres af dit team, og afdække eventuelle funktioner, som du skal tilføje for at skabe komplette brugerrejser.

For at opbygge et kort over brugerhistorier oplister du de vigtigste brugeraktiviteter (eller opgaver) og skriver derefter de opgaver ned, som brugerne skal gennemføre for hver af dem. Bagefter oplister du alle de funktioner, som du skal udvikle, for at give dine brugere mulighed for at gennemføre disse opgaver. Du kan enten gøre det med post-its på en whiteboardtavle eller bruge et af de mange dedikerede værktøjer til produktchefer.

Sådan ser kortet ud for en musikstreamingtjeneste.

Du kommer sandsynligvis ikke til at prioritere ret meget på dette tidspunkt.

Processen med at skrive de nødvendige funktioner ned for hver opgave vil dog stadig hjælpe dig med prioriteringen, da du vil opdage, at der mangler funktioner til bestemte aktiviteter (som har høj prioritet for dig).

Derefter kan du hurtigt tilføje disse manglende funktioner til din backlog og flytte dem øverst op for at sikre, at du har dækket den specifikke aktivitet fuldt ud for dine brugere.

I eksemplet ovenfor har vi et MVP-kort over brugerhistorier, der er under aktiv udvikling (færdige historier har et flueben ud for deres navn). Når vi ser på det, kan vi se, at aktiviteten Kontostyring er ufuldstændig, da vi endnu ikke har udviklet login med sociale medier.

Så før vi begynder at arbejde på søgningen efter kunstnere/albums, bør vi først færdiggøre aktiviteten Kontostyring.

Kort over brugerhistorier i virkeligheden

Ligesom RICE passer kort over brugerhistorier godt til dine prioriterings- og brainstormingsmøder. En af de største fordele ved at bruge denne ramme er dens evne til at bringe brugerperspektivet ind i mødelokalet.

Ved at se på brugeraktiviteterne og -opgaverne vil dine teammedlemmer være mindre tilbøjelige til at foreslå funktionsidéer, der er irrelevante for dine kunders behov og udfordringer. Selv hvis de foreslår dem, kan du nemt give dem lav prioritet, eftersom disse funktioner ikke hjælper brugerne med at gennemføre deres opgaver.

5. Scoring af muligheder

Strukturelt minder scoring af muligheder om RICE. I modsætning til sidstnævnte er kriterierne i systemet til scoring af muligheder dog ikke mejslet i sten, og det er op til dig at vælge dem.

Hvis du eksempelvis vil afstemme din overordnede køreplan med ledelsen, kan du overveje at bruge overensstemmelse med produktstrategien, gennemførlighed og potentiel omsætning som dine kriterier. Sådan ser en køreplan prioriteret med denne ramme ud.

Her har vi brugt en skala fra 0-5 til at score hver faktor og beregnet summen af alle faktorer for hvert punkt på listen.

Scoringskort i virkeligheden

Da du selv kan vælge kriterierne, er scoringskort perfekte til møder, hvor flere teams skal afstemme deres prioriteringer.

Hvis du eksempelvis har brug for at afstemme din køreplan med dine juridiske teams og sikkerhedsteams og høre deres syn på prioriteringerne, vælger du kriterier, der er relevante for dem (f.eks. risiko for retssag over for forretningsværdi). Med dit marketingteam kan du derimod bruge indsats, prisniveau, overensstemmelse med forretningsmål, markedsrækkevidde og sikkerhed som dine kriterier.

6. Indsatsmatrix

Kan du huske Eisenhower-matricen, der bruges til at prioritere dine personlige initiativer? Indsatsmatricen er en version af den, som er mere målrettet arbejdet med nye produktfunktioner.

Dens fulde navn er matricen for værdi kontra indsats, da den kan visualisere forholdet mellem disse to faktorer for hver af dine opgaver. Sådan ser den ud.

Du placerer indsats på Y-aksen og kundeværdi på X-aksen. Bagefter opdeler du den ligesom Eisenhower-matricen i 4 kvadranter og placerer dine funktioner i hver af dem afhængigt af deres værdi og indsats. Derefter prioriterer du dine opgaver i følgende rækkefølge:

1. Hurtige gevinster (funktioner med stor effekt, som du kan udføre nu)
2. Store projekter (dine strategisk vigtige funktioner)
3. Udfyldninger (potentielle funktioner med en enkel implementering, som du kan overveje senere)

Funktioner i kvadranten med tidsrøvere vil du normalt kassere, da der slet ikke er nogen grund til at have dem i din backlog.

Indsatsmatrix i virkeligheden

Både den største fordel og ulempen ved denne model ligger i dens enkelhed.

Det er en fordel, fordi du nemt kan forklare prioriteringsprocessen for de personer, der er til stede, og straks begynde at vælge de rigtige funktioner ved hjælp af den.

Ulempen er, at indsatsmatrixen ikke viser de forskellige faktorer, der spiller en afgørende rolle i prioriteringen (sikkerhed, rækkevidde, afhængigheder osv.).

Derfor er den bedste anvendelse af denne model korte afstemningsmøder, hvor detaljerne ikke betyder noget (da du som regel vil have en mere dybdegående session med RICE som opfølgning).

Få dine interessenter på linje med din produktkøreplan

Det er vigtigt at prioritere dit arbejde. Men det vil være uden værdi, hvis du ikke har fået alle til at samles om dine prioriteter. Mange af de modeller, vi har gennemgået i dag, er samarbejdsbaserede og skaber automatisk denne fælles forståelse.

Men hvis du beslutter dig for at vælge den model, der ikke kræver, at du samler alle dine interessenter i samme rum, skal du sørge for, at du har delt din prioriterede liste med de relevante personer og afstemt den med deres forventninger og behov.

Glem ikke at tilmelde dig vores nyhedsbrev med flere ressourcer og vejledninger om produktstyring samt de seneste podcasts, interviews og andre indsigter fra brancheledere og eksperter.