Beheer

7 eigenschappen van een goede product owner
Veel organisaties worstelen met de goede invulling van de rol product owner.
Veel organisaties worstelen met de goede invulling van de rol product owner.
Hoe meer organisaties hun manier van werken in agile veranderen, hoe crucialer de rol van product owner wordt. De product owner bepaalt namelijk wat er wanneer wel of juist niet wordt opgeleverd, èn waarom. Hoe beter een product owner functioneert, hoe groter diens impact is. Tegelijkertijd worstelen veel organisaties om juist deze rol goed ingevuld te krijgen. Wat mag je volgens Margo van Houtum en Rini van Solingen van een excellente product owner verwachten en hoe ziet zijn of haar ontwikkeling eruit?
Veel organisaties hebben inmiddels hun organisatie compleet ingericht rond een agile manier van werken. De product owner is daarin de rol die verantwoordelijk is voor het maximaliseren van de waarde van het werk van zijn of haar team(s). Om waarde te maximaliseren, bepaalt een product owner de visie en waardepropositie, de markt (of het segment), businessdoelen en -modellen en de belangrijke functies van een product.
Hoe dit wordt gedaan, kan sterk uiteenlopen bij organisaties, teams en individuen. De rol van product owner is weliswaar ontstaan in scrum maar heeft ook in bijna alle andere agile frameworks (zoals SAFe – het Scaled Agile Framework) een prominente rol.
Wachtlijst voorkomen
Het basisidee is dat één persoon het mandaat krijgt om beslissingen te nemen op de intersectie van gebruikers, business en technologie. Dat kan een product owner zelden alleen en daarvoor zoekt deze interactie met verschillende stakeholders. Maar uiteindelijk beslist de product owner. Een goede afweging maken tussen wat mogelijk is qua capaciteit en welk effect behaald moet worden, lukt alleen als de product owner keuzes maakt over wat juist niet wordt gedaan. Alleen dan wordt voorkomen dat er een heel lange wachtlijst ontstaat van werk. De product owner is zodoende het stuur op de output en outcome van zijn of haar teams. En daarmee zijn alle product owners gezamenlijk het stuur op vrijwel alle investeringen van de organisatie.
De rol van product owner is daardoor cruciaal in elke organisatie die agile oppakt. Er zijn nog maar weinig organisaties die zich dat echt goed realiseren en daar ook naar handelen. Dat blijkt bijvoorbeeld als de rol van product owner op de volgende manier wordt ingevuld:
- slechts in deeltijd en soms zelfs voor maar een paar uur per week, of
- door een medewerker zonder beslissingsbevoegdheid, of
- met de hoofdtaak van het uitschrijven van user story's, of
- operationeel aangestuurd door een business manager of stuurgroep die eigenlijk de beslissingen nemen, of
- door een medewerker die totaal niet is opgeleid tot product owner,
- en soms zelfs door al deze zaken gecombineerd.
Impact op wendbaarheid
Het mag duidelijk zijn dat het op die manier onmogelijk is om de rol als product owner goed in te vullen. Dat heeft direct impact op de daadwerkelijke wendbaarheid van de organisatie als geheel, en daarmee op de cijfers onderaan de streep.
Maar er is ook goed nieuws. Ten eerste wordt het door alle praktijkervaringen steeds helderder wat het verschil is tussen goede en minder goede product owners – in het bijzonder wat ze wél en juist niet (zouden moeten) doen. Ten tweede wordt steeds duidelijker wat een organisatie van haar product owners mag verwachten (zie kader). En ten derde kunnen product owners zichzelf ontwikkelen van waar ze nu staan tot excellente product owners, en ook die evolutie laat zich steeds beter uittekenen.
Kortom, de rol van product owner wordt steeds belangrijker voor veel organisaties. Dat vraagt steeds meer van de medewerkers die deze rol invullen. Tegelijkertijd zal hun ontwikkeling tot excellente product owners hard nodig zijn. Want willen we in de praktijk onze organisaties écht op een wendbare manier laten functioneren, dan wordt het tijd dat we de product owners in de sturende positie brengen waar ze worden verwacht. En het vraagt tevens dat we deze rol gaan invullen met de menselijke kwaliteiten die daarvoor nodig zijn.
- Eindgebruikers intensief betrekken. Alles draait om het maken van keuzes vanuit een waardeperspectief. De eindgebruiker is daarbij cruciaal om het gewenste effect te bereiken. Excellente product owners weten die gebruikersbehoefte dan ook heel concreet te maken. Dat doen zij onder meer door gebruikers intensief te betrekken – bijvoorbeeld door altijd een aantal van hen uit te nodigen bij sprint reviews en demo’s – en door bewust en intensief te werken met 'persona’s' (gedetailleerde representatieve gebruikersprofielen). Daarnaast zorgen goede product owners voor een snelle gesloten feedback loop, zodat heel regelmatig getoetst wordt of de verwachte gebruikerswaarde ook daadwerkelijk wordt ervaren.
- Eigenaarschap opeisen. Product owners nemen eigenaarschap en realiseren zich dat dit een constant gevecht om zeggenschap is, én dat dat bij de rol hoort. Eigenlijk zijn het mini-entrepreneurs die doen alsof elke investering van geld en capaciteit uit de eigen portemonnee komt. Excellente product owners pakken ruimte en vragen geen toestemming, omdat zij de propositie en verwachte waarde zelf leveren. 'Nee' kunnen zeggen op allerlei slimme manieren is daarmee een noodzakelijke vaardigheid.
- Denken en handelen op meerdere niveaus. Excellente product owners schaken simultaan op meerdere niveaus. Minimaal op de drie niveaus: operationeel, tactisch en strategisch (zie ook AG artikel april 2019: Van Solingen en Van Soest – Agile naar strategisch niveau), maar afhankelijk van de omgeving kunnen dat er nog veel meer zijn. Daarom hebben zij lijntjes op elk hiërarchisch niveau in de organisatie. Daarnaast leggen zij escalatiepaden naar deze niveaus al op voorhand aan. Intensief en terugkerend contact op deze drie niveaus organiseert de product owner zelf. Onder meer door minimaal een keer per twee weken de belangrijke stakeholders bij elkaar te brengen – en samen met hen businesscases uit te werken. Ook zorgen zij voor intensief contact met de ander product owners (minimaal eens per week met de direct aanpalende teams en minimaal een keer per maand met alle product owners gezamenlijk). Bij het contact met de andere product owners is het cruciaal dat er een roadmap is (of komt) voor de gemeenschappelijke businesspropositie. Tot slot schakelen ze op twee niveaus met hun teams: op operationeel niveau om het werk begrijpelijk en haalbaar te maken, en op strategisch/tactisch niveau om technologische mogelijkheden en onmogelijkheden vroegtijdig te bespreken en de balans tussen inspanning en impact op voorhand zo optimaal mogelijk te maken.
- Waarde concreet maken. Excellente product owners maken waarde concreet en meetbaar (zie ook AG artikel januari/februari 2021: Van Solingen en Van Daalen – Sturen op waarde met agile). Strategisch en tactisch moet waarde objectief uit te drukken zijn, omdat er trade-offkeuzes nodig zijn ten opzicht van andere epics, teams en proposities. Daarvoor maken goede product owners bijvoorbeeld een business-value-scorecard met de businessdimensies op de ene as (de kansen) en de randvoorwaardelijke investeringen (risico’s) op de andere. Waarde wordt door hen uitgedrukt in bottom-line eenheden zoals geld, marktaandeel, kostenbesparingen of NPS-scores. Technisch onderhoud, compliance of kwaliteit worden ook in waarde uitgedrukt en meegeprioriteerd. Bijvoorbeeld via cost-of-delay (wat kost het als we het nu niet oppakken?).
- Resoluut weigeren om zélf user story's uit te schrijven. Excellente product owners snappen dat het erom gaat dat teams waarde echt begrijpen. De beste toets hiervoor is deze teams zelf de user story's te laten uitschrijven. Dan is direct zichtbaar wat wel en wat niet is begrepen. Steeds verder uitdetailleren en uitkauwen van user story's en deze aan teams ‘voeren’, leidt nooit tot goede oplossingen. Een excellente product owner zorgt voor een excellente manier voor de totstandkoming van user-story's en snapt dat je die daarom dus nooit zelf uit moet schrijven.
- Specifieke werkwijze inrichten passend bij elk team. Elk team heeft een eigen volwassenheidsniveau en elk teamlid heeft individuele krachten en behoeften. Een goede product owner kent de behoeftes van het team en past de werkwijze daarop aan. Dat betekent dus dat ongelijke teams ook ongelijk worden behandeld (zie ook AG artikel december 2017: Van Solingen en Koning – Eigenaarschap hoort bij agile). De mens achter elk teamlid is leidend en de product owner zorgt voor de meest effectieve manier van aansturing die daarbij past. De product owner handelt vanuit vertrouwen en geeft teams de ruimte om zelf fouten te maken want dat is waar de teamvolwassenheid groeit. Deze langdurige investering betaalt zich uiteindelijk terug in gezamenlijk resultaat en een hogere teamvolwassenheid.
- Hoogfrequente rapportage op voortgang en forecast. Transparantie op voortgang en vooruitblikken op de toekomst is voor een excellente product owner cruciaal. Verwachte oplevermomenten, voortgang en haalbare deadlines en tijdpaden worden samen met het development team uitgewerkt en expliciet gemaakt. De product owner werkt deze rapportage op wekelijkse basis bij en verstuurt deze aan alle stakeholders - en tegelijkertijd. Een goede product owner laat zien wat zijn of haar verwachtingen naar de toekomst zijn en stelt deze minstens elke week bij. En indien aanpassingen impact hebben, dan worden die stakeholders daar direct over ingelicht. De voortgangsrapportage van de excellente product owner bevat nooit pijnlijke verrassingen voor de stakeholder.
Dit artikel is ook gepubliceerd in het magazine van AG Connect (juni 2022). Wil je alle artikelen uit dit nummer lezen, zie dan de inhoudsopgave.
Met punt 5 ben ik het niet eens. Het is ook in tegenspraak met punt 6.
Het uitschrijven van user stories komt meestal neer op het vertalen van een businessperspectief naar een softwareperspectief. Wie kan dat beter dan de product owner (PO), die zowel de taal van de business begrijpt als de taal van de ontwikkelaars? Natuurlijk moet de PO daarbij het hele ontwikkelteam betrekken. Maar de PO blijft zelf verantwoordelijk voor de kwaliteit van de product backlog.
Punt 6 betekent dat de PO het uitschrijven mag overlaten aan ontwikkelaars, als die dat kunnen en willen. Maar veel ontwikkelaars hebben daar geen zin in. Die willen gewoon horen wat er gebouwd moet worden. Dan kan de PO het beter zelf doen. Of het overlaten aan een analist, als het team daarover beschikt.