De rol van Product Owner (vaak met verschillende namen, maar over het algemeen hetzelfde concept) bestaat uit het prioriteren van de product backlog met de juiste visie om de waarde van het product te maximaliseren. Veel organisaties interpreteren dit "product" nogal ruim, terwijl een van de kernwaarden van Scrum "focus" is. Helaas ontbreekt deze focus vaak, waardoor een Product Owner aan verschillende "onderdelen" van een product werkt die eigenlijk aparte producten zouden moeten zijn. Daarom kan het hebben van een duidelijk overzicht van KPI's een Product Owner helpen zich te richten op de aspecten van het product die positief bijdragen aan deze indicatoren.
Key Performance Indicators zijn de statistieken die teams of organisaties regelmatig bekijken om er zeker van te zijn dat ze op het juiste spoor zitten of dat er aanpassingen nodig zijn. Het is essentieel om ze te onderscheiden van prestatie-indicatoren. Een negatieve afwijking in KPI's vereist onmiddellijke actie, terwijl een afwijking in Prestatie-indicatoren dat niet doet. Vaak zijn prestatie-indicatoren niet concreet gedefinieerd voor een product, wat mogelijkheden biedt voor optimalisatie.
Je kunt het vergelijken met een auto: als hij te snel rijdt (km/u) in een zone met snelheidscontroles, moet dit onmiddellijk worden aangepast (KPI). De kilometerstand moet echter over een bepaalde periode worden bijgehouden (PI). In het geval van een e-commerce webshop wordt de omzet gemonitord. Als deze afwijkt van het budget, moet er worden bijgestuurd. Maar als het aantal inschrijvingen op nieuwsbrieven gedurende de dag aanzienlijk daalt, hoeft er misschien niet direct actie te worden ondernomen. Hetzelfde geldt voor minder openbare producten zoals ERP systemen of order management systemen. Als het aantal geëxporteerde orders daalt in vergelijking met het gemiddelde (bijvoorbeeld per minuut), dan wijst dit op een probleem. Ook een stijging van het aantal interne rapporten over een bepaalde functionaliteit geeft aan dat deze niet gebruiksvriendelijk is en extra aandacht nodig heeft. Dit kan worden gezien als een prestatie-indicator. Een overzicht van deze indicatoren, ook wel bekend als een KPI Framework, helpt een organisatie te focussen op wat echt belangrijk is voor het bedrijf en de optimale klantreis.
In staat zijn om 'Nee' te zeggen is een van de belangrijkste aspecten van stakeholder management binnen Product Ownership. Niet alles kan of moet onmiddellijk worden aangepakt. Dit gebeurt in principe op basis van de productvisie die je hebt. In de praktijk is dit gemakkelijker gezegd dan gedaan, vooral bij een generiek product. Verwijzen naar de KPI's van de organisatie kan hierbij helpen. User stories die direct bijdragen aan het behalen van de KPI's kunnen vaak een hogere prioriteit krijgen dan stories die dat niet doen. Als een user story positief bijdraagt aan het behalen van de doelstellingen van een KPI, kan deze worden opgenomen in de product backlog. Zo niet, dan is het antwoord 'Nee'.
Als Product Owner heb je waarschijnlijk te maken met zakelijke KPI's zoals omzet. Het tegenargument kan zijn dat elke user story daar direct of indirect aan bijdraagt. Het kan helpen om rekening te houden met andere factoren zoals bereik (hoeveel gebruikers profiteren), impact (lage, gemiddelde of hoge positieve impact op de inkomsten), vertrouwen (in de eerdere schattingen van bereik en impact) en de inspanning die nodig is om de user story te implementeren. Deze factoren samen staan bekend als het RICE-model. Het RICE-model is ook handig voor het maken van je product roadmap.
Door alleen te focussen op de onderdelen of deelproducten die positief bijdragen aan het behalen van de KPI's, ontstaat er tijd en ruimte in de agenda en backlog van het Scrum-team - tijd en ruimte die anders besteed zou worden aan onnodige onderwerpen. Deze capaciteit kan vervolgens worden gebruikt om nieuwe toevoegingen te ontwikkelen die wel bijdragen aan een KPI. Er kan meer energie worden gestoken in het formuleren van hypotheses, het opzetten van experimenten, het maken van proofs of concept (POC's) en prototypes, en het helder uitschrijven van requirements voor een minimaal levensvatbaar product (MVP's). Kwaliteit boven kwantiteit is hier belangrijk. De Product Owner is verantwoordelijk voor het maximaliseren van de waarde van het product, de dienst of de functionaliteit. Deze waardegroei kan worden gemeten met behulp van KPI's.
Wanneer er een melding komt dat er iets fout gaat in de productieomgeving, is de neiging om al het werk stil te leggen en het hele (ontwikkel)team ernaar te laten kijken. Maar hoe essentieel is de falende functionaliteit? Heeft het een directe impact op een KPI (bijv. omzetdaling omdat een webpagina down is), of kan het onderzoek en de bug fix wachten tot de volgende sprint (bijv. wanneer een applicatie voor tijdregistratie aanzienlijk trager is, maar nog steeds bruikbaar)?
KPI's zijn niet alleen nuttig vanuit een financieel perspectief of als beloningsmodel, maar ze kunnen je als Product Owner ook helpen om je rol beter te vervullen en je keuzes uit te leggen. Als je Product Ownership wilt bespreken of hoe Agile en Scrum effectief kunnen worden toegepast in jouw organisatie, laat het ons weten!