De Product Owner, een rol die regelmatig een andere naam krijgt maar vaak op hetzelfde neerkomt; met de juiste visie de productbacklog prioriteren om zo de waarde van het product te maximaliseren. En dit “product” wordt in veel gevallen door organisaties vrij breed opgevat terwijl een van de waardes van scrum juist “focus” is. Helaas ontbreekt deze focus vaak, waardoor een Product Owner bezig is met de doorontwikkeling van verschillende onderdelen van ‘een product’, terwijl dit eigenlijk losse producten zouden moeten zijn. Daarom kan een overzicht van (K)PI’s een Product Owner helpen te focussen op juist die onderdelen van het product die positief bijdragen aan deze indicatoren.
Wat zijn (K)PI’s en hoe helpen ze een organisatie?
Key Performance Indicators kent iedereen wel; het zijn de cijfers die je als team of organisatie regelmatig bekijkt om te zien of de juiste koers nog wordt gevaren of dat er bijgestuurd moet worden. Hierbij is het belangrijk om het onderscheid met Performance Indicators te maken. Bij een negatieve afwijking in KPI’s zal er direct aan de knoppen moeten worden gedraaid, terwijl bij een afwijking van Performance Indicators geen directe actie nodig zal zijn. Vaak zijn het juist de Performance Indicators die niet concreet worden bepaald voor een product, terwijl hier juist kansen liggen voor optimalisatie.
Je kunt het vergelijken met een auto: rijdt deze te snel op een trajectcontrole (km/u) dan zal dit direct moeten worden aangepast (KPI). De kilometerstand, daarentegen, zal over een bepaalde periode in de gaten gehouden moeten worden (PI). In het voorbeeld van een E-commerce webshop wordt er gekeken naar omzet. Als deze afwijkt van budget, zal er moeten worden bijgestuurd. Echter, als het aantal nieuwsbrief-inschrijvingen gedurende de dag een flinke dip ervaart, dan is dit wellicht geen directe reden voor actie.
Hetzelfde kan gelden voor een minder openbaar product zoals een ERP-systeem of ordermanagement-systeem. Daalt het aantal geëxporteerde orders t.o.v. het gemiddelde (bijv. per minuut) dan is dit een indicatie dat er iets misgaat. Ook het aantal interne meldingen over een bepaalde functionaliteit geeft een indicatie dat het desbetreffende onderdeel niet gebruiksvriendelijk is en dus extra aandacht vereist. Dit kan worden gezien als een performance indicator.
Een overzicht van deze indicatoren (ook wel een KPI Framework genoemd) helpt een organisatie om te focussen op dat wat echt belangrijk wordt gevonden door de business, maar ook voor de optimale customer journey.
3 manieren waarop duidelijke (K)PI’s een PO helpen
1. Stakeholder management
Je zou kunnen stellen dat ‘Nee’ (kunnen) zeggen één van de belangrijkste aspecten van stakeholdermanagement is binnen het Product Ownerschap. Niet alles kan of hoeft gelijk te worden opgepakt. Dit doe je in de basis aan de hand van de visie die je voor het product hebt. In de praktijk is dit makkelijker gezegd dan gedaan, zeker in het geval van een vrij generiek product. Verwijzen naar de (K)PI’s van de organisatie kan hierbij helpen. User stories die direct bijdragen aan het behalen van de KPI’s kunnen in veel gevallen hoger geprioriteerd worden dan user stories die dit niet doen. En draagt de user story positief bij aan het behalen van de targets op een van de (K)PI’s? Dan kan het worden opgenomen op de product backlog. Zo niet, dan is het antwoord ‘Nee’.
Het RICE-model als backup
Nu ligt het voor de hand dat je als PO’er te maken hebt met een business KPI zoals omzet. In dat geval kan het tegenargument worden gegeven dat elke user story direct of indirect hieraan bijdraagt. Het kan dan helpen om andere factoren erbij te pakken zoals bereik (hoeveel gebruikers zijn erbij gebaat), impact (in dit geval een lage, gemiddelde of hoge positieve impact op omzet), vertrouwen (in de eerdere inschattingen van bereik en impact) en de hoeveelheid moeite die er gedaan zal moeten worden om de user story te implementeren (effort). Deze factoren samen worden ook wel het RICE-model genoemd. Het RICE-model kan ook goed gebruikt worden om je product roadmap op te stellen.
2. Het verzamelen en uitwerken van ideeën
Door alleen te focussen op de onderdelen of subproducten die een positieve bijdrage leveren aan het behalen van de (K)PI’s, ontstaat er tijd en ruimte in de agenda en backlog van het scrumteam. Tijd en ruimte dat anders was gespendeerd aan onnodige onderwerpen. Deze capaciteit kan dan benut worden om nieuwe toevoegingen te bedenken die wél die gewenste bijdrage aan een (K)PI leveren. Zo kan er meer energie worden gestopt in het formuleren van bijvoorbeeld hypotheses, het opzetten van experimenten, creëren van proof of concepts (POC’s) en prototypes en het duidelijk uitschrijven van requirements van bijvoorbeeld een minimal valuable product (MVP’s). Kwaliteit over kwantiteit is hier belangrijk. De Product Owner is immers verantwoordelijk voor het maximaliseren van de waarde van het product, dienst of functionaliteit. Deze groei in waarde kan worden gemeten aan de hand van (K)PI’s.
3. Incidentmanagement
Bij een melding dat er iets op de productie omgeving niet goed gaat, is men geneigd al het werk stil te leggen en het hele (ontwikkel)team hiernaar te laten kijken. Maar hoe essentieel is de functionaliteit die faalt daadwerkelijk? Heeft het directe impact op een van KPI’s (bijv. omzetdaling omdat een bepaalde webpagina niet online staat) of kan het onderzoeken en maken van de bug ook mee worden genomen in de volgende sprint (bijv. wanneer een urenregistratie applicatie aanzienlijk trager is, maar nog wel gebruikt kan worden)?
Aan de slag!
KPI’s zijn dus niet alleen interessant vanuit financieel perspectief of als beloningsmodel, maar kunnen jou als Product Owner goed helpen om je rol beter te vervullen én om jouw keuzes goed te kunnen uitleggen. Wil je een keer sparren over het Productownerschap of over hoe Agile en Scrum op een goede manier toegepast kunnen worden in jouw organisatie, neem dan contact met Hessel Snijder. We denken graag mee!
