6 okt 2025
Een Product- of Projectorganisatie?
Ik zie nog steeds veel organisaties — groot én klein — die projectmatig werken met omvangrijke projectplannen. Waarom eigenlijk?
Wat me opvalt, is dat organisaties vaak op zoek zijn naar de oplossing van een probleem, en het projectplan beschrijft dan die oplossing, niet het probleem dat ze op gaan lossen.
Daar gaat het volgens mij mis. En dat kan anders.
Wat ik me afvraag: Waarom schrijven we nog steeds van die grote projectplannen?
Het kost maanden aan voorbereiding om een plan van tientallen pagina’s te schrijven voor een doorlooptijd van een jaar of langer.
Alle stakeholders moeten input leveren, het team wordt samengesteld, budgetten geregeld — en dan zijn we eindelijk “ready to go”. Toch?
Toch gaan er hier al een paar dingen mis, bijvoorbeeld:
Niet het juiste team van experts wordt aangesloten.
Denk bijvoorbeeld aan dat project waar de inhoudelijke experts pas na het opstellen van het plan werden aangesloten. Of juist experts met extreem veel interne kennis, maar ging de outside-in gedachte verloren.Weten we echt de oplossing? Of was het plan gewoon het beste idee?
Al die uitvoerige projectplannen gieten alles in beton, en laten onvoldoende ruimte over voor bijsturing.
Dat zette me aan het denken. Want ik zie veel organisaties die nog steeds in projecten werken, maar wél Product Owners hebben die verantwoordelijk zijn voor een product — soms met of zelfs zonder dedicated team.
Hoe verhoudt zich dat?
Zoals Dave West van Scrum.org tijdens een lezing laatst zei: “Een project heeft een kop en een staart. Een product niet.”
Een product ontwikkel je continu, op basis van klantfeedback en veranderende behoeften. Een product is nooit “af”, althans totdat het end-of-life is.
Het verschil tussen een project- en productorganisatie
Een struggle die ik veel zie en ook heel begrijpelijk is. We maken een website, en het maken daarvan is toch een project? Kan. Maar wat nu als je precies die website, of app, of dienstverlening als product gaat zien voor een eindgebruiker (kan ook een interne afdeling zijn). Je gaat feitelijk je mindset aanpassen. Wat je in het project maakte, ga je als product zien. Dan komt het allemaal heel anders. Zeker als je dan ook in die mindset meeneemt dat het product nooit af is. Want de gebruiker van morgen kan toch weer nieuwe wensen hebben. Dit betekend dat je dus ook niet uitgaat van een product wat je in een keer helemaal af maakt, dat noemen we een project, maar je gaat op basis van klantfeedback dat product continu een beetje bijschaven. Continuous improvement noemen we dat. Je bouwt nieuwe functionaliteiten, onderhoud de techniek, en soms verwijder je oude functionaliteiten weer.
Een product organisatie gaat er vanuit dat diensten, apps, of zelfs fysieke zaken producten zijn waar je continu aan werkt. Projecten zitten daarmee in feite op een heel ander level. Het worden meer initiatieven, waarover hieronder meer.
De gebruiker centraal in het product.
Sluiten projecten en producten elkaar uit? Zeker niet.
In frameworks als SAFe en Scrum@Scale bestaan juist mechanismen zoals Epics om grotere initiatieven/projecten te structureren en teams te alignen.
Het verschil zit hem in de manier van denken en organiseren.
Organisaties die bijvoorbeeld een product thinking mindset hebben, zetten de eindgebruiker en het product centraal.
Ze bouwen multidisciplinaire productteams met mandaat, die continu verbeteren en waarde leveren op basis van feedback.
Kun je als organisatie dan nog projecten doen? Zeker. Maar niet meer in de traditionele vorm. Geen projectplan van 25 kantjes met een tijdlijn van 24 maanden. Want laten we eerlijk zijn: van die 25 kantjes komt zelden veel terecht, en die 24 maanden worden vaak 36. De wereld verandert te snel. Een time-to-market van twee jaar is simpelweg te laat.
Daarnaast ligt scope creep altijd op de loer, waardoor het project nooit de finish haalt. Zonde van de investering — en frustrerend voor teams die hun succes niet kunnen vieren.
Hoe dan wél?
Kijk eens kritisch naar je organisatie. Herken je die logge, stroperige projecten? Probeer het eens anders.
Begin met het opschrijven van een initiatief. Gebruik bijvoorbeeld de Epic-template van SAFe. Die is lichtgewicht. Past het niet op 1 A4, blijf dan bijschaven en uitdiepen tot het past. Het is essentieel dat je het probleem van die eindgebruiker snapt. Als je daar eindeloos veel woorden voor nodig hebt, dan zou je jezelf eens achter de oren kunnen krabben.
Nodig vervolgens de agile productteams uit om mee te denken:
Hoe kunnen zij bijdragen aan de waarde van dit initiatief?
Welke afhankelijkheden bestaan er tussen teams?
Wat hebben ze nodig om maximale impact te maken?
Ben je leider?
Dan ligt hier een belangrijke rol voor jou: faciliteer, geef richting en mandaat, maar laat teams zelf met een plan komen. Is trouwens ook echt veel leuker dan alleen achter een scherm.
Als dat allemaal lukt wordt het project een behoorlijk krachtig vehikel. Want je hebt ontdekt dat er een gebruikersbehoefte is die team overstijgend is. Door een overkoepelend intitiatief in te richten dat zich richt op het beantwoorden van die klantbehoefte bundel je bijna op een natuurlijke manier de krachten van verschillende teams. De energie die je daarmee ontketend is verslavend.
Guardrails voor een productgerichte manier van werken
Beperk teamcapaciteit per Epic/Initiatief/Project.
Teams moeten ruimte houden om te reageren op de markt, klantbehoeften en om eigen verbeteringen te initiëren.Koppel initiatieven aan productvisie en strategie.
Visieloze producten leiden tot verwarde eindgebruikers. Vraag jezelf steeds af: Welk probleem lossen we op?Werk met productroadmaps én een portfolio-overzicht.
Zorg dat de samenhang en afhankelijkheden tussen producten zichtbaar zijn. Maar ook helder wordt waar we team overstijgend naartoe werken.
Blijf écht Agile.
Voorkom dat planningen voor maanden worden dichtgetimmerd. Werken in Product Increments (PI’s), of langere roadmaps kan. Maar houd lucht in je planning en giet niets in beton wat verder de toekomst in gaat.
Lever klein, vier vaak.
Ook binnen een Epic kun je in korte cycli waarde leveren.
Denk aan je werk als legoblokjes: met elk blokje ontdek je wat het precies moet zijn, hoe het past in het geheel, en vooral — waarom je het bouwt.
Meten is weten.
Bepaal vooraf hoe succes eruitziet. Meet continu of de deliverables daadwerkelijk bijdragen aan klant- of businesswaarde. Zo niet: kill your darlings.
Samengevat
Stel die gebruikersbehoefte centraal — niet het project en zeker niet de oplossing. Door productteams eigenaarschap te geven, ruimte om te leren en focus op klantwaarde, wordt het makkelijker om kort-cyclisch te leveren en echte waarde te creëren.
Er zullen altijd grotere initiatieven blijven bestaan, maar organiseer ze zó dat teams de vrijheid houden om te doen waar ze goed in zijn. Leg mandaat in de teams, faciliteer waar nodig, en maximaliseer gezamenlijke impact.
En tot slot: vergeet nooit successen te vieren.
Aan alle Product Owners en leiders:
Hoe kijk jij hiernaar?
Herken je de spanning tussen projecten en producten in jouw organisatie?
Ik ben benieuwd naar je ervaringen — en als je hiermee worstelt of gewoon eens wilt sparren over de inrichting van een productgerichte organisatie: happy to help! 🤝