Effectief prioriteren met een product scorecard

Hoe zorg je ervoor dat jouw team zich richt op de meest waardevolle verbeteringen binnen jouw platform? Op papier is iedere story, bug, taak, epic of initiatief wel te verantwoorden via een business case, maar in de praktijk heb je als product owner hier simpelweg niet de tijd voor. Hoe zorg je dan toch dat je weloverwogen besluiten maakt in het vormen en prioriteren van je roadmap? Een scorecard kan hier uitkomst bieden, maar waar begin je?

Het prioriteren van functies vormt de kern van het werk van de product owner. En toch geven veel product owners prioriteiten op basis van buikgevoel, of op de behoeften van de luidruchtigste persoon aan tafel. In dit artikel leg ik uit hoe je een scorecard kunt gebruiken om alle belangen in de juiste context te plaatsen en features te prioriteren. Deze scorecardbenadering zorgt ervoor dat je gefocust blijft op klanttevredenheid en bedrijfsstrategie, terwijl je de risico’s verkleint.

Wat is een product scorecard?

Er zijn vele definities en toepassingen van scorecards binnen product management. Aangezien we ons nu focussen op prioritering is mijn definitie als volgt:

Een product scorecard is een systeem dat door product owners wordt gebruikt om features te prioriteiten, op basis van afgewogen KPI’s die in lijn liggen met bedrijfsstrategie en productvisie.

In dit artikel gebruik ik onderstaand vereenvoudigd voorbeeld:

Ingrediënten van een product scorecard

Op basis van bovenstaand voorbeeld licht ik alle onderdelen van de scorecard toe:

Wegingsfactoren en gewichten

Het fundament van je scorecard zijn je wegingsfactoren. Deze factoren zijn een directe doorvertaling van jouw bedrijfsstrategie en jouw productvisie. Bepaal de KPI’s waar jouw product het meest aan kan bijdragen en waar jij denkt dat jouw product het onderscheid kan maken. Een aantal voorbeelden van wegingsfactoren:

Omzetverhoging: de feature draagt bij aan het verhogen van je omzet. Denk aan het vermeerderen van traffic (bijv. middels SEO), conversie (bijv. optimalisatie van je checkout) of retentie (bijv. het verbeteren van je aftersale e-mails);
Kostenbesparing: de feature draagt bij aan het besparen van interne kosten. Denk aan interne procesoptimalisatie (bijv. automatiseren van handmatige werkzaamheden) en licentie bezuinigen (bijv. het vervangen van kostbare externe tooling met inhouse development);
Inzichtverkrijging: de feature draagt bij aan het vergaren van inzichten. Denk aan het verkrijgen van kwalitatief (bijv. een online questionnaire) of kwantitatieve inzichten (bijv. de implementatie van een analytics tool);
Klanttevredenheid: de feature draagt bij aan het verbeteren van gebruikservaring of NPS. Denk aan het verbeteren van je mobile experience (bijv. het responsive maken van je webshop), het lanceren van handige tools (bijv. keuze wizards, apps) of het intuïtiever maken van functionaliteiten (bijv. het vereenvoudigen van je checkout);
Performance- of stabiliteitsverbetering: de feature draagt bij aan het versnellen van paginalaadtijden of het stabieler maken van je platform. Denk aan het optimaliseren van je code (bijv. het vereenvoudigen van je CSS code), het uitvoeren van updates in je platform (bijv. het bijwerken van je PHP versie) of het doorvoeren van technische procesoptimalisaties (bijv. het inrichten van een OTAP straat);

Niet iedere wegingsfactor zal even zwaar tellen in je prioriteitsstelling. Daarom verbinden we aan iedere factor een gewicht. Uitgedrukt in een percentage, waarbij de som van gewichten 100% is, kun jij nog beter een doorvertaling maken van je bedrijfsstrategie en productvisie.

Wildcards (optioneel)

Een gevaarlijke, maar soms noodzakelijke, factor is een wildcard. Mochten er features zijn die ‘kosten wat het kost’ uitgevoerd moeten worden, dan zet ik een wildcard in. Deze wildcard zorgt ervoor dat de feature linea recta de hoogste eindscore krijgt. Wat voor features kunnen bijvoorbeeld een wildcard krijgen? Denk aan features die:

Noodzakelijk zijn om aan een bepaalde wet te voldoen;
Noodzakelijk zijn om een groot security risico te voorkomen;
Bedrijfskritische problemen oplossen;
Op het kritieke pad liggen van interne noodzakelijke bedrijfsprogramma’s;

Development omvang

Een belangrijke factor die vaak vergeten wordt is de grootte van de feature voor je development team. Als je deze waarde niet meeneemt dan loop je het risico dat je reusachtige features met een geringe hogere eindscore boven features plaatst die qua omvang vele malen kleiner zijn. Aangezien het inschatten van de grootte van een feature in dit stadium meestal nog erg gissen is, raadpleeg ik altijd het team om mij te assisteren in het maken van een zgn. “t-shirt estimation”, waar ik de waarden “S”, “M”, “L” en “XL”. In mijn achterliggende formule ken ik aan iedere t-shirt maat een absoluut getal toe. Een voorbeeld:

T-shirt maat	Ingeschat aantal sprints	Rekenwaarde
S	2	2
M	4	4
L	8	8
XL	16	16

Bepaal zelf welke t-shirt maten je hanteert en welke sprinthoeveelheden en rekenwaardes je aan iedere t-shirt maat toekent. Mochten features groter zijn dan je grootste t-shirt maat, dan kun je overwegen om de feature op te delen in twee afzonderlijke features.

Eindscores

Op basis van alle factoren bereken je op basis van een formule de eindscore per feature.

= ( ( ( [gewicht van wegingsfactor 1] maal [feature score van wegingsfactor 1] ) plus ( [gewicht van wegingsfactor 2] maal [feature score van wegingsfactor 2] ) plus ( [gewicht van wegingsfactor …] maal [feature score van wegingsfactor …] ) ) gedeeld door [development omvang] ) plus [‘100’ indien wildcard van toepassing is]

Vullen van features

Nu de kolomkoppen zijn belicht is het van belang om de scorecard te vullen met features. Voor iedere wegingsfactor bedenk je per initiatief een relatieve score (0 (laag) tot 100 (hoog)) ten opzichte van de andere initiatieven. Daarnaast vul je in of een wildcard van toepassing is en wat de t-shirt grootte is van de feature. Op basis van de formule rolt er automatisch een eindscore uit. Des te hoger de eindscore, des te hoger de prioriteit op jouw roadmap.

Tips voor scorecarding

Zorg voor buy-in bij senior management: jouw scorecard kan alleen werken als je deze ‘top-level’ hebt afgestemd. Zorg dat senior management jouw interpretatie en doorvertaling van KPI’s steunt. Alleen op deze manier creeer je draagvlak en heb jij je antwoord klaar voor ‘die luidruchtige’ aan de vergadertafel;
Bepaal vooraf de scope van ieder initiatief: het is van groot belang dat je vooraf per feature een duidelijke scope hebt vastgesteld. Op basis van deze scope kun je pas écht goed de scores en development omvang bepalen. Dit klinkt logisch maar wordt in de praktijk vaak snel vergeten;
Blijf objectief beoordelen: ook deze tip klinkt als een no-brainer maar verdwijnt vaak naar de achtergrond. Vergeet die vervelende stakeholder, gooi jouw persoonlijke voorkeuren over boord en kijk louter naar feiten en best practices;
Schat development omvang in met developers: ik heb in het verleden de fout gemaakt om de development omvang zelf in te schatten of dit samen met een (ver van de praktijk afstaande) architect uit voeren. Zoals ook geldt voor de uiteindelijke estimation, geldt ook voor deze high level inschattingen van de development omvang: doe dit samen met één of enkele ervaren developers. Zij kennen het product immers het beste en weten als geen ander wat er moet gebeuren om de feature met zijn scope op te leveren;
Reevalueer scores tussentijds: de scores die je toekent aan features zijn relatief. Dit betekent dat de scores worden bepaald in perspectief van andere features. Mocht je op een later tijdstip een feature toevoegen die hoger is dan een feature met score ‘100’ dan dien je alle features naar beneden bij te stellen (voor de betreffende wegingsfactor). Daarbij kunnen nieuwe inzichten binnen features altijd leiden tot het revalueren van diens score;