6 manieren om productfuncties te prioriteren (+ tips & voorbeelden)
Als je het mij vraagt, zijn twee van de belangrijkste vaardigheden op het gebied van productmanagement weten wat je prioriteiten zijn en "nee" zeggen.
Vandaag gaan we diep in op het eerste (want het tweede verdient een eigen gids) en helpen we je om je werk te prioriteren en ervoor te zorgen dat iedereen zich aan je prioriteiten houdt.
Een belangrijke opmerking over raamwerken voor het prioriteren van productfuncties
Voordat we de manieren gaan verkennen om je backlog te prioriteren, is er één belangrijke tip die ik met je moet delen.
Want more from The CPO Club?
Sign up for a free membership to complete reading this article:
Have an account? Log In
Prioriteringsraamwerken zijn niet bedoeld om letterlijk te worden toegepast.
Nee, je hoeft het niet precies te gebruiken zoals het in het boek (of deze gids) staat beschreven. Het product waaraan jij leiding geeft, kan volledig verschillen van de producten waaraan de auteur leiding gaf toen die het boek schreef. Verschillende producten betekenen verschillende realiteiten en behoeften. Het is dus helemaal prima om het raamwerk aan je eigen behoeften aan te passen. Een goed raamwerk is tenslotte een raamwerk dat voor jou werkt.
Raamwerken voor productprioritering om uit te proberen
Wist je dat er een Thanos-prioriteringsraamwerk bestaat? Je verwijdert gewoon willekeurig de helft van alle functies in je backlog!
Dat heb ik verzonnen. Maar je begrijpt mijn punt. Er zijn gewoon te veel raamwerken. Zoveel, dat ik ze onmogelijk allemaal in deze gids kan behandelen. Eerlijk gezegd denk ik ook niet dat je hier bent om een miljoen raamwerken uit je hoofd te leren.
Daarom bespreek ik de raamwerken die ik persoonlijk in mijn dagelijkse werk als productmanager heb gebruikt en deel ik voor elk raamwerk een paar praktische tips met je. Het is ook de moeite waard om te bedenken hoe je AI kunt gebruiken bij het prioriteren van functies naast deze raamwerken.
1. Kanomodel
Deze prioriteringsmethode is vernoemd naar de getalenteerde Japanse schrijver en managementconsultant Noriaki Kano. De kracht van zijn aanpak zit in de eenvoud.
Kano stelde voor om je functies in de volgende groepen in te delen:
- Essentiële functies: Dit zijn basisfuncties van je product. Als ze ontbreken, leidt dat tot een slechte klantervaring (slechte retentie en klantverloop zijn gegarandeerd). Een goed voorbeeld hiervan is de chatfunctie in Intercom of het zoeken naar klantfeedback in G2.
- Prestaties: Deze functies creëren gebruikerswaarde op basis van hun omvang. Meer ervan betekent meer waarde. Kijk bijvoorbeeld naar de accucapaciteit en actieradius van een moderne elektrische auto. Een grotere actieradius creëert (over het algemeen) meer waarde voor bestuurders. Een ander voorbeeld is het aantal integraties in Zapier.
- Aantrekkelijk: In plaats van directe waarde toe te voegen en pijnpunten van gebruikers weg te nemen, richten deze functies zich op het vergroten van de aantrekkelijkheid van je producten. Prachtig ontworpen productvisiesecties in een projectmanagementtool of leren stoelen in een auto vallen hieronder.
Als we de relatie tussen de mate waarin deze typen functies voorkomen en de klanttevredenheid die ze creëren zouden visualiseren, zou dat er ongeveer zo uitzien.
Hier zien we dat prestatiefuncties lineair van aard zijn (vandaar dat meer ervan je meer waarde oplevert). Functies die essentieel zijn creëren daarentegen niet veel extra waarde. Ze zijn er in plaats daarvan op gericht om de ontevredenheid van je gebruikers weg te nemen.
Tot slot is de categorie aantrekkelijk bedoeld om je een extra tevredenheidsboost te geven. Maar die heeft geen enkel effect als je een van je "essentiële functies" hebt verprutst.
Kano in de praktijk
Hoe pas je het Kanomodel in de praktijk toe? Uit mijn ervaring wordt Kano zelden gebruikt in prioriterings- of brainstormsessies. De reden is dat dit iets zeer intuïtiefs is en dat je het niet op een whiteboard hoeft te tekenen en mensen hoeft te vragen hun functies op basis van deze drie categorieën in te delen.
In plaats daarvan leer je je belanghebbenden doorgaans om op de Kano-manier te denken. Hierdoor zullen ze, voordat ze bij je komen met een verzoek om een nieuwe functie, het idee in hun hoofd langs dit raamwerk halen en beslissen of het de moeite waard is om het verder te onderzoeken.
Op deze manier delegeer je een deel van het werk rond het prioriteren van functies aan je belanghebbenden en bespaar je enorm veel tijd op lange brainstormsessies.
2. MoSCoW-methode
De MoSCoW-methode is een van de populairste methoden om functies te prioriteren. De twee redenen voor de populariteit ervan zijn eenvoud en effectiviteit.
Om deze methode toe te passen, hoef je alleen maar naar elke functie in je lijst te kijken en er een van deze vier prioriteiten aan toe te kennen:
- Moet hebben
- Zou moeten hebben
- Zou kunnen hebben
- Zal niet hebben
Je kent deze prioriteiten doorgaans toe op basis van een combinatie van factoren, waaronder de waarde die het oplevert voor gebruikers, bedrijfswaarde, strategische afstemming, implementatiecomplexiteit en andere factoren.
Zo ziet een typische lijst met functies voor een muziekstreamingdienst eruit als je MoSCoW erop toepast.
- Hier hebben we de offline modus de prioriteit “moet hebben” gegeven, omdat veel van onze gebruikers naar muziek zullen luisteren aan boord van een vliegtuig.
- VR-ervaringen kregen daarentegen de prioriteit “zal niet hebben”, omdat ze behoorlijk moeilijk te implementeren zijn en maar weinig gebruikers VR-headsets hebben om ze te ervaren.
MoSCoW in de praktijk
Hoewel je MoSCoW uitstekend kunt gebruiken om je prioriteringsvergaderingen te ondersteunen, is er één nadeel waardoor het voor dergelijke situaties minder effectief is.
Omdat de prioriteit is gebaseerd op een combinatie van meerdere factoren, kost het elk teamlid behoorlijk veel tijd om de onderbouwing achter zijn of haar productbeslissingen uit te leggen. Uit mijn ervaring zijn MoSCoW-sessies behoorlijk traag en inefficiënt in vergelijking met andere raamwerken.
Maar dat betekent niet dat ik MoSCoW niet goed vind. Het is juist het raamwerk dat ik het vaakst gebruik. Mijn favoriete toepassing van MoSCoW is de lijst met functies in een PRD.
Ik geef lezers doorgaans eerst context over de gebruikerswaarde, technische complexiteit en andere factoren in het document voordat ik de functies opsom. Wanneer ze bij een functie “moet hebben” zien staan, hebben ze daardoor de context om de onderbouwing van mijn beslissing snel te begrijpen.
Op deze manier levert MoSCoW me een gemakkelijk te begrijpen lijst met functies op in een productvereistendocument.
3. RICE-methode
In tegenstelling tot de vorige twee methoden is het RICE-scoringsmodel iets gestructureerder en minder afhankelijk van besluitvorming op basis van intuïtie. Het identificeert vier afzonderlijke prioriteringsfactoren en stelt je in staat om elke factor afzonderlijk te kwantificeren en te evalueren. Deze factoren zijn:
- Bereik: Dit vertegenwoordigt het aandeel van je gebruikers waarop deze functie invloed zal hebben.
- Impact: De omvang van de impact zelf.
- Vertrouwen: Geeft aan of je er vertrouwen in hebt dat de bereikte mensen die impact zullen ervaren.
- Inspanning: Dit is de tijdsduur die je ontwikkel- en productteam nodig heeft om deze functie gereed te maken.
Wat je doorgaans doet, is een functie kiezen en vervolgens voor elk van deze vier factoren een score tussen 0 en 10 toekennen. Daarna bereken je de RICE-score met deze formule.
Tot slot rangschik je je lijst met functies op basis van de belangrijkste metriek van dit raamwerk: de RICE-score (een hogere score = hogere prioriteit). Zo ziet het resultaat van een RICE-prioritering eruit.
- In deze lijst zien we dat de nieuwe gebruikersinterface de hoogste score heeft gekregen dankzij de lage inspanning en het grote bereik/de grote impact.
- De cloudsynchronisatie staat daarentegen onderaan de lijst vanwege de grote inspanning die je team nodig heeft om deze te implementeren.
RICE-score in de praktijk
Ik heb meerdere keren genoemd dat zowel MoSCoW als Kano niet de beste keuze zijn voor prioriterings- en brainstormvergaderingen. Maar welk raamwerk gebruik ik voor dergelijke situaties? RICE!
Door voor elke factor afzonderlijke scores toe te kennen, maak je het voor mensen gemakkelijker om tijdens deze vergaderingen de onderbouwing achter hun beslissingen te presenteren (iets wat bij MoSCoW ontbreekt). Bovendien kun je het scoren van elke factor delegeren aan de teamleden die op dat gebied de meeste kennis hebben.
Zo is je productontwikkelingsteam het meest geschikt om de inspanningsscore toe te kennen. Je data-analisten hebben daarentegen het beste inzicht in het potentiële bereik van die functie.
4. Gebruikersverhalen in kaart brengen
Technisch gezien is Gebruikersverhalen in kaart brengen geen prioriteringsframework. In plaats daarvan wordt het gebruikt om het werk dat je team moet doen te organiseren en functies te ontdekken die je moet toevoegen om volledige gebruikersreizen mogelijk te maken.
Om een storymap te maken, som je de belangrijkste gebruikersactiviteiten (of taken) op en noteer je vervolgens de taken die gebruikers daarvoor moeten voltooien. Daarna som je alle functies op die je moet bouwen om je gebruikers deze taken te laten voltooien. Je kunt dit doen met plakbriefjes op een whiteboard of een van de vele speciale tools voor productmanagers gebruiken.
Zo ziet de map eruit voor een muziekstreamingdienst.
Op dit punt ben je waarschijnlijk nog niet veel aan het prioriteren.
Het proces van het noteren van de vereiste functies voor elke taak helpt je echter nog steeds bij het prioriteren, omdat je zult beseffen dat er functies ontbreken voor bepaalde activiteiten (die voor jou prioriteit hebben).
Je voegt deze ontbrekende functies vervolgens snel toe aan je backlog en verplaatst ze naar bovenaan, zodat je zeker weet dat je die specifieke activiteit voor je gebruikers volledig hebt afgedekt.
In het bovenstaande voorbeeld hebben we een MVP-storymap die actief wordt ontwikkeld (voltooide stories hebben een vinkje naast hun naam). Als we ernaar kijken, zien we dat de activiteit Accountbeheer onvolledig is, omdat we de aanmeldingen via sociale media nog niet hebben gebouwd.
Voordat we beginnen met het bouwen van de zoekfunctie voor artiesten/albums, moeten we dus eerst de activiteit Accountbeheer voltooien.
Storymaps in de praktijk
Net als RICE zijn storymaps zeer geschikt voor je prioriterings- en brainstormsessies. Een van de belangrijkste voordelen van dit framework is dat het gebruikersperspectief naar de vergaderruimte brengt.
Door naar de gebruikersactiviteiten en -taken te kijken, zullen je teamgenoten minder snel functie-ideeën voorstellen die niet relevant zijn voor de behoeften en pijnpunten van je klanten. Zelfs als ze dat wel doen, kun je deze eenvoudig een lage prioriteit geven, omdat deze functies gebruikers niet helpen hun taken te voltooien.
5. Kansenscore
Structureel gezien lijkt kansenscore op RICE. In tegenstelling tot RICE liggen de criteria in het systeem voor kansenscores echter niet vast en bepaal je zelf welke criteria je kiest.
Om je roadmap op hoofdlijnen bijvoorbeeld af te stemmen op je leidinggevenden, kun je kiezen voor aansluiting bij de productstrategie, haalbaarheid en potentiële omzet als criteria. Zo ziet een roadmap eruit die met dit framework is geprioriteerd.
Hier hebben we een schaal van 0 tot 5 gebruikt om elke factor te scoren en de som van alle factoren voor elk item op de lijst berekend.
Scorekaarten in de praktijk
Omdat je zelf de criteria kunt kiezen, zijn scorekaarten perfect voor afstemmingssessies tussen teams.
Als je je roadmap bijvoorbeeld moet afstemmen met je juridische en beveiligingsteams en hun mening over prioriteiten wilt horen, kies je criteria die voor hen relevant zijn (bijv. het risico op een rechtszaak versus bedrijfswaarde). Met je marketingteam kun je daarentegen inspanning, kosten, aansluiting bij bedrijfsdoelen, marktbereik en vertrouwen als criteria gebruiken.
6. Inspanningsmatrix
Herinner je je de Eisenhower-matrix die wordt gebruikt om prioriteit te geven aan je persoonlijke initiatieven? De inspanningsmatrix is daar een variant van die meer is toegespitst op het werken met nieuwe productfuncties.
De volledige naam is de matrix voor waarde versus inspanning, omdat deze de relatie tussen deze twee factoren voor elk van je taken kan visualiseren. Zo ziet die eruit.
Je plaatst Inspanning op de Y-as en Klantwaarde op de X-as. Vervolgens deel je de matrix, net als de Eisenhower-matrix, op in 4 kwadranten en plaats je je functies in elk kwadrant, afhankelijk van hun waarde en inspanning. Daarna prioriteer je je taken in de volgende volgorde:
- Snelle overwinningen (functie met grote impact die je nu kunt uitvoeren)
- Grote projecten (je strategisch belangrijke functies)
- Aanvullingen (mogelijke functies met een eenvoudige implementatie om later te overwegen)
Functies in het kwadrant van tijdvreters gooi je meestal weg, omdat er überhaupt geen reden is om ze in je backlog te hebben.
Inspanningsmatrix in de praktijk
Zowel het grote voordeel als het nadeel van dit raamwerk schuilt in de eenvoud ervan.
Het is een voordeel, omdat je het prioriteringsproces eenvoudig kunt uitleggen aan de mensen in de ruimte en er meteen de juiste functies mee kunt selecteren.
Het nadeel is dat de inspanningsmatrix niet de verschillende factoren laat zien die een belangrijke rol spelen bij prioritering (vertrouwen, bereik, afhankelijkheden enzovoort).
De beste toepassing voor dit raamwerk zijn daarom korte afstemmingsbijeenkomsten waarin de details er niet toe doen (omdat je meestal als vervolg een diepgaandere sessie met RICE houdt).
Zorg dat je belanghebbenden op één lijn zitten met je productroadmap
Het prioriteren van je werk is belangrijk. Maar het heeft geen waarde als je niet iedereen achter je prioriteiten hebt gekregen. Veel van de raamwerken die we vandaag hebben besproken zijn van nature samenwerkingsgericht en zorgen automatisch voor afstemming.
Maar als je besluit te kiezen voor het raamwerk waarvoor je niet al je belanghebbenden in dezelfde ruimte hoeft samen te brengen, zorg er dan voor dat je je geprioriteerde lijst met de relevante mensen hebt gedeeld en deze hebt afgestemd op hun verwachtingen en behoeften.
Vergeet niet je te abonneren op onze nieuwsbrief voor meer bronnen en handleidingen over productmanagement, plus de nieuwste podcasts, interviews en andere inzichten van marktleiders en experts.
