6 sätt att prioritera produktfunktioner (+ tips & exempel)
Om du frågar mig är två av de viktigaste färdigheterna inom produktledning att känna till dina prioriteringar och säga ”Nej.”
I dag ska vi gå på djupet med den förstnämnda (eftersom den sistnämnda förtjänar en egen guide) och hjälpa dig att prioritera ditt arbete och hålla alla samordnade kring dina prioriteringar.
En viktig anmärkning om ramverk för prioritering av produktfunktioner
Innan vi börjar utforska olika sätt att prioritera din backlogg finns det ett viktigt tips som jag behöver dela med mig av.
Continue Reading for Free
Create a free account to finish this article, plus get ongoing access to timely insights and practical resources.
Have an account? Log In
Prioriteringsramverk är inte avsedda att tas bokstavligt.
Nej, du behöver inte använda det exakt så som det är skrivet i boken (eller den här guiden). Produkten du leder kan vara helt annorlunda än de produkter som författaren ledde när boken skrevs. Olika produkter innebär olika verkligheter och behov. Därför är det helt okej att anpassa ramverket efter dina egna behov. Ett bra ramverk är trots allt ett som fungerar för dig.
Prioriteringsramverk för produkter som du kan prova
Visste du att det finns ett Thanos-prioriteringsramverk? Du raderar helt enkelt slumpmässigt hälften av alla funktioner i din backlogg!
Okej, det hittade jag på. Men du förstår poängen. Det finns alldeles för många ramverk där ute. Så många att jag definitivt inte kommer att kunna gå igenom alla i den här guiden. Om jag ska vara ärlig tror jag inte heller att du är här för att memorera en miljon ramverk.
Så i stället ska jag gå igenom de ramverk som jag själv har använt i mitt dagliga arbete med produktledning och dela med mig av ett par praktiska tips för vart och ett. Det är också värt att fundera på hur du kan använda AI vid prioritering av funktioner tillsammans med dessa ramverk.
1. Kano-modellen
Den här prioriteringsmetoden har fått sitt namn efter den talangfulle japanske författaren och managementkonsulten Noriaki Kano. Det fina med hans metod är dess enkelhet.
Kano föreslog att man skulle kategorisera sina funktioner i följande grupper:
- Måste finnas: Det här är grundläggande funktioner i din produkt, och om de saknas leder det till en dålig kundupplevelse (dålig kundretention och kundbortfall är garanterade). Ett bra exempel på detta är chattfunktionen i Intercom eller sökfunktionen för kundfeedback i G2.
- Prestanda: Dessa funktioner skapar användarvärde baserat på hur utbredda de är. Fler av dem innebär mer värde. Titta bara på batterikapaciteten och räckvidden hos en modern elbil. Bättre räckvidd skapar (generellt sett) mer värde för förare. Ett annat exempel är antalet integrationer i Zapier.
- Attraktiva: I stället för att skapa direkt värde och lösa användarnas problem fokuserar dessa funktioner på att göra dina produkter mer omtyckta. Vackert utformade delar som visar produktvisionen i ett projektledningsverktyg eller lädersäten i en bil är exempel på sådana funktioner.
Om vi skulle visualisera förhållandet mellan hur utbredda dessa typer av funktioner är och den kundnöjdhet de skapar skulle det se ut ungefär så här.
Här kan vi se att prestandafunktioner är linjära till sin natur (därför ger fler av dem dig mer värde). Funktioner som måste finnas skapar däremot inte särskilt mycket extra värde. I stället är de till för att undanröja användarnas missnöje.
Slutligen finns kategorin attraktiva funktioner där för att ge dig en extra nöjdhetsskjuts. Men den har ingen effekt alls om du har misslyckats med någon av dina funktioner som ”måste finnas”.
Kano i verkligheten
Hur tillämpar man Kano-modellen i verkligheten? Enligt min erfarenhet används Kano sällan i prioriterings- eller brainstormingmöten. Anledningen är att detta är något väldigt intuitivt, och du behöver inte rita upp det på en whiteboard och be människor att klassificera sina funktioner utifrån dessa tre kategorier.
I stället brukar man lära sina intressenter att tänka enligt Kano. Tack vare detta kommer de, innan de vänder sig till dig med en ny funktionsförfrågan, att pröva idén genom det här ramverket i huvudet och avgöra om den är värd att utforska eller inte.
På så sätt delegerar du en del av arbetet med prioritering av funktioner till dina intressenter och sparar massor av tid på långa brainstormingsessioner.
2. MoSCoW-metoden
MoSCoW-metoden är en av de mest populära metoderna för att prioritera funktioner. De två orsakerna till dess popularitet är enkelhet och effektivitet.
För att tillämpa den här metoden behöver du bara titta på varje funktion i din lista och ge den en av följande fyra prioriteringar:
- Måste ha
- Bör ha
- Kan ha
- Kommer inte att ha
Du tilldelar vanligtvis dessa prioriteringar baserat på en kombination av faktorer, bland annat det värde de skapar för användarna, affärsvärdet, den strategiska anpassningen, implementeringskomplexiteten och annat.
Så här kommer en typisk lista över funktioner att se ut för en musikströmningstjänst om du tillämpar MoSCoW på den.
- Här har vi tilldelat offlineläget prioriteten ”måste ha”, eftersom många av våra användare kommer att lyssna på musik ombord på ett flygplan.
- VR-upplevelser fick däremot prioriteten ”kommer inte att ha”, eftersom de är ganska svåra att implementera och mycket få användare har VR-headset för att uppleva dem.
MoSCoW i verkligheten
Även om du utan problem kan använda MoSCoW för att hjälpa dig att leda dina prioriteringsmöten finns det en nackdel som gör metoden mindre effektiv i sådana sammanhang.
Eftersom prioriteringen baseras på en kombination av flera faktorer blir det ganska tidskrävande för varje teammedlem att förklara tankegången bakom sina produktbeslut. Enligt min erfarenhet är MoSCoW-sessioner ganska långsamma och ineffektiva jämfört med andra ramverk.
Men det betyder inte att jag inte gillar MoSCoW. Faktum är att det är det ramverk jag använder oftast. Min favoritplats för att använda MoSCoW är funktionslistan i ett PRD.
Jag brukar ge läsarna kontext om användarvärdet, tekniska komplexiteter och andra faktorer i dokumentet innan jag börjar lista funktionerna. När de då ser ”Måste ha” bredvid en av dem har de den kontext som krävs för att snabbt förstå tankegången bakom mitt beslut.
På så sätt ger MoSCoW mig en lättöverskådlig funktionslista i ett produktkravdokument.
3. RICE-metoden
Till skillnad från de två föregående metoderna är RICE-poängmodellen något mer strukturerad och mindre beroende av intuitivt beslutsfattande. Den identifierar fyra tydliga prioriteringsfaktorer och låter dig kvantifiera och utvärdera var och en separat. Dessa faktorer är:
- Räckvidd: Representerar andelen av dina användare som den här funktionen kommer att påverka.
- Påverkan: Själva påverkan i omfattning.
- Konfidens: Visar om du är säker på att de personer som nås kommer att få ta del av den påverkan.
- Arbetsinsats: Den tidsram som ditt utvecklings- och produktteam behöver för att göra funktionen klar.
Det du vanligtvis gör är att välja en funktion och sedan tilldela en poäng mellan 0 och 10 för var och en av dessa fyra faktorer. Därefter beräknar du RICE-poängen med den här formeln.
Slutligen ordnar du funktionslistan efter det huvudsakliga måttet i detta ramverk – RICE-poängen (högre poäng = högre prioritet). Så här ser resultatet av en RICE-prioritering ut.
- I den här listan kan vi se att det nya användargränssnittet har fått den högsta poängen tack vare den låga arbetsinsatsen och den stora räckvidden/påverkan.
- Funktionen Molnsynkronisering ligger däremot längst ner på listan på grund av den stora arbetsinsats som krävs för att implementera den.
RICE-poäng i verkligheten
Jag har fortsatt att nämna att varken MoSCoW eller Kano passar bäst för prioriterings- och brainstormingsmöten. Men vilket ramverk använder jag i sådana sammanhang? RICE!
Genom att ge separata poäng för varje faktor blir det enklare för människor att presentera tankegången bakom sina beslut under dessa möten (något som saknas i MoSCoW). Dessutom kan du delegera poängsättningen av varje faktor till de teammedlemmar som har bäst kunskap inom området.
Exempelvis är ditt produktutvecklingsteam bäst lämpat att sätta poängen för arbetsinsatsen. Dina dataanalytiker har däremot bäst förståelse för den potentiella räckvidden för den funktionen.
4. Kartläggning av användarberättelser
Tekniskt sett är kartläggning av användarberättelser inte ett prioriteringsramverk. I stället används det för att organisera det arbete som ska utföras av ditt team och upptäcka eventuella funktioner som du behöver lägga till för att skapa fullständiga användarresor.
För att skapa en storykarta listar du de viktigaste användaraktiviteterna (eller arbetsuppgifterna) och skriver sedan ner de uppgifter som användarna behöver slutföra för varje aktivitet. Därefter listar du alla funktioner som du behöver bygga för att låta användarna slutföra dessa uppgifter. Du kan antingen göra detta med självhäftande lappar på en whiteboard eller använda något av de många särskilda verktygen för produktchefer.
Så här ser kartan ut för en musikstreamingtjänst.
Du kommer förmodligen inte att prioritera särskilt mycket i det här skedet.
Processen med att skriva ner de funktioner som krävs för varje arbetsuppgift kommer ändå att hjälpa dig med prioriteringen, eftersom du kommer att inse att vissa aktiviteter saknar funktioner (som är prioriterade för dig).
Du lägger sedan snabbt till dessa saknade funktioner i din backlog och flyttar dem högst upp för att säkerställa att du har täckt den specifika aktiviteten för dina användare.
I exemplet ovan har vi en storykarta för en MVP under aktiv utveckling (färdiga berättelser har en bock bredvid namnet). Genom att titta på den ser vi att aktiviteten Kontohantering är ofullständig, eftersom vi ännu inte har byggt inloggning via sociala medier.
Innan vi börjar arbeta med sökningen efter artister och album bör vi därför först slutföra aktiviteten kontohantering.
Storykartor i verkligheten
Precis som RICE passar storykartor utmärkt för dina prioriterings- och brainstormingmöten. En av de främsta fördelarna med att använda detta ramverk är dess förmåga att föra in användarperspektivet i mötesrummet.
Genom att titta på användaraktiviteterna och uppgifterna är det mindre sannolikt att dina teammedlemmar föreslår funktionsidéer som inte är relevanta för dina kunders behov och problem. Även om de gör det kan du enkelt ge dem låg prioritet, eftersom dessa funktioner inte hjälper användarna att slutföra sina uppgifter.
5. Poängsättning av möjligheter
Strukturellt liknar poängsättning av möjligheter RICE. Till skillnad från dess motsvarighet är kriterierna i systemet för poängsättning av möjligheter dock inte huggna i sten, utan det är upp till dig att välja dem.
För att exempelvis anpassa din övergripande färdplan till ledningen kan du överväga att använda passning mot produktstrategin, genomförbarhet och potentiella intäkter som kriterier. Så här ser en sådan färdplan ut när den har prioriterats med detta ramverk.
Här har vi använt skalan 0–5 för att poängsätta varje faktor och beräknat summan av alla faktorer för varje punkt på listan.
Poängkort i verkligheten
Eftersom du fritt kan välja dina egna kriterier är poängkort perfekta för möten där olika team ska samordnas.
Om du exempelvis behöver samordna din färdplan med juridik- och säkerhetsteamen och höra deras syn på prioriteringar väljer du kriterier som är relevanta för dem (t.ex. risken för en stämning kontra affärsvärdet). Med marknadsföringsteamet kan du däremot använda insats, kostnad, anpassning till affärsmålet, marknadsräckvidd och säkerhet som kriterier.
More Articles
6. Insatsmatris
Kommer du ihåg Eisenhower-matrisen som används för att prioritera dina personliga initiativ? Insatsmatrisen är en version av den som är mer anpassad för arbete med nya produktfunktioner.
Det fullständiga namnet är matrisen värde kontra insats, eftersom den kan visualisera förhållandet mellan dessa två faktorer för var och en av dina uppgifter. Så här ser den ut.
Du placerar insats på Y-axeln och kundvärde på X-axeln. Därefter delar du, precis som i Eisenhower-matrisen, in den i fyra kvadranter och placerar dina funktioner i var och en beroende på deras värde och insats. Sedan prioriterar du dina uppgifter i följande ordning:
- Snabba vinster (en funktion med stor effekt som du kan genomföra nu)
- Stora projekt (dina strategiskt viktiga funktioner)
- Utfyllnad (potentiella funktioner med enkel implementering att överväga senare)
Funktioner i kvadranten för tidstjuvar brukar du vanligtvis kasta bort, eftersom det inte finns någon anledning att ha dem i din backlog överhuvudtaget.
Ansträngningsmatrisen i verkligheten
Både den främsta fördelen och nackdelen med det här ramverket ligger i dess enkelhet.
Det är en fördel eftersom du enkelt kan förklara prioriteringsprocessen för personerna i rummet och omedelbart börja välja rätt funktioner med hjälp av den.
Nackdelen är att ansträngningsmatrisen inte visar de olika faktorer som spelar en viktig roll i prioriteringen (konfidens, räckvidd, beroenden osv.).
Det bästa användningsområdet för det här ramverket är därför korta möten för att skapa samsyn, där detaljerna inte spelar någon roll (eftersom ni vanligtvis har en mer djupgående session med RICE som uppföljning).
Skapa samsyn bland dina intressenter kring din produktfärdplan
Det är viktigt att prioritera ert arbete. Men det har inget värde om du inte har skapat samsyn kring era prioriteringar. Många av ramverken vi diskuterade i dag bygger på samarbete och skapar automatiskt denna samsyn.
Men om du bestämmer dig för att välja det ramverk som inte kräver att du samlar alla dina intressenter i samma rum, ska du se till att du har delat din prioriterade lista med relevanta personer och stämt av den mot deras förväntningar och behov.
Glöm inte att prenumerera på vårt nyhetsbrev för fler resurser och guider om produktledning, samt de senaste poddarna, intervjuerna och andra insikter från branschledare och experter.
