Zonder goede product owner, geen succesvol IT-project

Het spel kennen, maakt je nog geen schaakmeester. Ook dat geldt voor de rol van product owner (PO). Vanuit mijn ervaring als projectmanager bij Linku ken ik inmiddels de grootste valkuilen in het product-ownerschap. In dit blog onthul ik precies die valkuilen en uitdagingen die inherent zijn aan deze cruciale rol en hoe deze niet alleen het project, maar ook het gehele team beïnvloeden.

Mijn doel? De impact van de product owner duidelijk maken en hoe de interactie met het development-team het verschil maakt voor een succesvol IT-project.

Om de valkuilen te begrijpen, is het eerst belangrijk om te weten wat de ideale product owner is. De PO in een IT-project staat tussen de stakeholders, bestaande uit minstens een opdrachtgever en een ontwikkelteam. Hierin vormt deze rol de brug tussen bedrijfsstrategie en techniek. Een product owner:

De ideale product owner beschikt over een unieke combinatie van vaardigheden:

Flexibiliteit, stressbestendigheid en een veelzijdige focus zijn eveneens essentiële persoonlijke eigenschappen. Deze dragen bij aan het succes van het project.

Iemand die al deze aspecten beheerst, ontwikkelt zich tot een ideale product owner.

Helaas verloopt de realiteit vaak anders dan het ideaal. De valkuilen waar product owners mee te maken krijgen, omvatten onder andere:

Deze uitdagingen stapelen zich vaak op tot een breekpunt, waarbij een project faalt en niemand wint. Daarom is een diepgaand begrip van deze rol van vitaal belang. Dit leg ik graag uit.

Een product owner is veel meer dan een tussenpersoon die verzoeken en informatie van de ene naar de andere partij doorspeelt. Het is de strateeg die overzicht houdt en vanuit deze kennis doelgerichte beslissingen neemt.

De product owner moet proactief zijn, initiatieven nemen en inspireren. De rol vereist dat het niet alleen de ‘’taal’’ van elke stakeholder en discipline spreekt, maar ook dat het deze verschillende ’talen’ vertaalt in een gezamenlijke strategie die alle teams op één lijn brengt.

Dit vraagt om een actieve houding, waarbij de product owner continu initiatief neemt en het team inspireert om samen aan een gemeenschappelijk doel te werken.

Het falen van een project zit vaak in het fundament, maar wordt vaak ten onrechte toegeschreven aan de laatste ‘schakel’: de ontwikkelaars. Software is echter niet oneindig aanpasbaar; een heldere strategie vanaf het begin is cruciaal. De product owner is hierin als een architect met een blauwdruk. Dit leg ik uit aan de hand van drie situaties.

Een product owner zonder een heldere, doordachte strategie is als een architect zonder blauwdruk. Zo’n aanpak leidt onvermijdelijk tot een wankel fundament waarop geen stabiel softwarehuis kan staan. Zelfs de meest vaardige ontwikkelaars kunnen geen robuuste applicatie bouwen op een basis die vanaf het begin gedoemd was te falen.

Maar zelfs een perfecte blauwdruk kan falen wanneer het eindproduct iets heel anders blijkt te zijn. Denk aan de bouw van een huis. Elk element, van fundering tot dak, is uitgedacht om dat gebouw te vormen. Stel je voor dat halverwege de bouw wordt besloten er een villa van te maken. Dat is geen kwestie van een paar aanpassingen; het is een fundamentele verandering die vereist dat je vanaf nul begint.

Zo is het ook met softwareontwikkeling. Wanneer tijdens een project de koers radicaal wijzigt, kun je niet simpelweg de achterliggende code aanpassen en verwachten dat het resultaat stabiel en functioneel zal zijn. Net zoals een huis niet spontaan een villa kan worden zonder ingrijpende wijzigingen, kan specifieke software niet zomaar transformeren zonder significante herziening en herstructurering.

Zicht op de markt en het speelveld zijn ook essentieel. Je moet voorbereid zijn op externe factoren. Als bijvoorbeeld vooraf niet duidelijk was dat het huis bestand moet zijn tegen aardbevingen, dan loop je na de bouw een enorm risico. Het is eigenlijk wachten tot een ramp. En als het dan misgaat, geef je dan de bouwvakkers de schuld?

Voor software geldt hetzelfde. De werking is onderhevig aan externe factoren. Net als bij de bouw van een huis moet je actief rekening houden met het speelveld om de werking te blijven garanderen. Als de product owner geen zicht heeft op de externe factoren, of besluit er niets mee te doen, dan loop je de kans dat het product faalt bij een ‘aardbeving’. Is het dan eerlijk om naar de ontwikkelaars te wijzen? Nee, maar dat gebeurt helaas wel.

Een doordachte blauwdruk is dus essentieel, niet alleen om de structuur van het project te bepalen maar ook om elk onderdeel van de software op elkaar af te stemmen. Zonder deze strategische grondslag zijn plotselinge herstructurering en inefficiëntie onvermijdelijke gevolgen, wat leidt tot verspilde tijd en een eindproduct dat tekortschiet.

Natuurlijk kun je niet alles vooraf uitdenken en is het soms nodig een paar stappen terug te doen. Dit betekent echter niet dat de oorspronkelijke blauwdruk waardeloos wordt. Integendeel, een goede blauwdruk is een flexibel framework dat ruimte biedt voor aanpassingen. Wanneer de product owner de visie bewust aanpast, bijvoorbeeld in reactie op veranderende marktomstandigheden of nieuwe inzichten, is het wel essentieel dat ontwikkelaars hierin meegenomen worden. Dit zorgt ervoor dat aanpassingen soepel verlopen en dat het team gezamenlijk richting hetzelfde doel blijft werken.

Dit onderstreept het belang van een product owner met een visie die vanaf het begin duidelijk en consistent is. Continuïteit in deze visie is cruciaal, zelfs als er wijzigingen nodig zijn. Het is de taak van de product owner om ervoor te zorgen dat de uitgestippelde route niet alleen in het begin wordt gevolgd, maar ook door het gehele bouwproces. Zo komt het team niet voor verrassingen te staan die vragen om een terugkeer naar de tekentafel. Daarmee wordt de succesvolle oplevering van een project – of het nu om een woning of software gaat – gewaarborgd.

Naast het belang van een goede visie mag de invloed van de product owner op de teamdynamiek niet worden onderschat. De PO zorgt voor meer dan alleen een omgeving waar openheid heerst; het is de drijvende kracht achter de teamgeest. Ook bij ontwikkelaars.

Het is belangrijk dat elk lid zich verbonden voelt met het project en begrijpt hoe zijn of haar bijdrage het eindproduct versterkt. De product owner staat in het midden, niet als een doorgeefluik, maar als de kern van een groep stakeholders die samenwerken aan een gedeeld doel.

Wanneer een product owner geen goede teamdynamiek realiseert, ontstaan o.a. de volgende valkuilen:

Ontwikkelaars zijn simpelweg geen machines, ze schrijven hun code met emotie.

Er wordt vaak gedacht dat code één waarheid kent; een reeks logische commando’s, puur en onpersoonlijk, die altijd op dezelfde manier samenvallen. Toch drukt de ontwikkelaar, bewust of onbewust, een stempel op dit werk. Code is niet alleen een product van intellect, maar ook van emotie. Wanneer een ontwikkelaar niet goed in zijn of haar vel zit, is dat terug te zien in het werk.

Elke regel code die een ontwikkelaar schrijft, vertelt een verhaal. Niet alleen over de technische eisen, maar ook over de staat van de geest van de ontwikkelaar. Een team dat goed functioneert en positief is, zal code produceren die helder, georganiseerd en efficiënt is. Maar wanneer ontwikkelaars zich gefrustreerd voelen, onder druk staan of ontevreden zijn over de gang van zaken binnen het project, kan hun code complexer, minder gestructureerd en zelfs foutgevoelig worden.

Dit is waar de rol van de product owner exponentieel belangrijk wordt. Een empathische en ondersteunende product owner verlicht de emotionele last die een ontwikkelaar draagt. Door een veilige en open omgeving te creëren waarin je zorgen kunt delen, helpt de product owner om het emotionele klimaat te stabiliseren. Dan zijn ontwikkelaars in staat om code van de hoogste kwaliteit te produceren.

Ik heb het helaas te vaak gezien: projecten die een terugslag kennen omdat de product owner de rol onvoldoende beheerst. De impact, nuances en valkuilen van deze rol worden immers onderschat. Daarom is het tijd om het belang en de valkuilen van deze sleutelrol te benadrukken. Het zijn de schaakmeesters, de astronauten, de bouwers, en de kapiteins van onze IT-projecten.

Blijf ons volgen. We gaan dieper in op het ideale IT-proces, de samenwerking van de PO, het managen van verwachtingen, en het balanceren tussen alle stakeholders. Zo komen we samen dichterbij het ideale IT-project waarin iedereen het beste uit zichzelf kan halen.