Al drie keer mocht ik aanschuiven bij De Product Owner Podcast om te praten over technical debt en IT legacy.
Drie gesprekken, verspreid over twee jaar. En elke keer was de kern hetzelfde: technical debt is niet jouw developers’ probleem. Het is jouw probleem, als product owner of product manager die de roadmap bewaakt.
Het gesprek dat ik overal voorbij hoor komen
Ik spreek veel product owners en product managers. En het patroon is bijna altijd hetzelfde. De roadmap staat. De stakeholders zijn enthousiast. Het team gaat aan de slag. Maar ergens halverwege het kwartaal begint alles te schuiven. Features die twee sprints zouden kosten, kosten er vier. Bugs die je fixt komen in een andere vorm terug. Nieuwe developers die je aanneemt om snelheid te creëren, zitten weken in te lezen voordat ze productief zijn.
En dan krijg je als product owner die ene zin van je tech lead: “We hebben te veel technical debt.”
Ik snap dat je daar niet blij van wordt. Want wat moet je ermee? Je kunt het niet zien. Je kunt het niet kwantificeren. En je stakeholders gaan echt niet akkoord met “we gaan een kwartaal lang niks opleveren om de boel op te ruimen.”
Waarom tech debt een roadmap-probleem is
Ik schoof drie keer aan bij De Product Owner Podcast schoof om hierover te praten, en elke keer ging het over een ander stukje van hetzelfde probleem:
Podcast #102 - Technical debt, wat moet je er mee?
“Technical debt is niet het gevolg van slecht werk, maar van keuzes.”
Wat ís technical debt eigenlijk? En waarom is het niet per se slecht? Want dat nuanceverschil mist vaak. Technical debt is niet het gevolg van slecht werk. Het is het gevolg van keuzes. Bewuste keuzes soms, om sneller te kunnen leveren. Maar elke keuze heeft een prijs, en die prijs wordt hoger naarmate je langer wacht.
Podcast #163 - IT Legacy: de handrem op je roadmap realisatie
“Wacht je te lang, dan lost een refactoring-sprint het niet meer op.”
Wat gebeurt er als technical debt zich jarenlang opstapelt en niemand ingrijpt? Dan wordt het een structureel probleem dat als een handrem op je hele roadmap werkt. Niet iets dat je met een refactoring-sprint oplost, maar iets dat een strategie vraagt. We bespraken hoe je als product owner dat gesprek voert met je organisatie, en waarom het zo belangrijk is om vroegtijdig in te grijpen.
Podcast #205 - Roadmap 2026 samenstellen
“Maak technical debt zichtbaar in impact, niet in technische termen.”
De vraag die product owners het meest stellen is: hoe krijg ik mijn stakeholders mee om tijd te investeren in iets dat ze niet kunnen zien? Mijn antwoord is altijd: door het zichtbaar te maken. Niet in technische termen, maar in impact. Hoeveel procent van je sprintcapaciteit gaat naar onderhoud? Hoeveel duurder is elke feature geworden ten opzichte van een jaar geleden? Wat kost het als je niks doet?
Hoeveel procent van je sprintcapaciteit gaat naar onderhoud? Hoeveel duurder is elke feature geworden ten opzichte van een jaar geleden? Wat kost het als je niks doet?
De drie lessen die ik het vaakst deel
1. Je business roadmap en je technische roadmap zijn niet hetzelfde, maar ze horen wel samen.
Veel product owners hebben alleen een feature roadmap. Technical debt verdwijnt daardoor naar een backlog die niemand ziet en niemand prioriteert. Maak er een aparte roadmap van. Niet om het apart uit te voeren, maar juist om het zichtbaar te maken. Want als je beide roadmaps naast elkaar legt, zie je de synergie: technical debt die je kunt aanpakken in combinatie met een feature die toch al raakt aan dat onderdeel. Zo maak je voortgang zonder dat je een kwartaal lang “niks oplevert.”
2. Features schrappen is vaak sneller dan features bouwen.
Dit is het meest tegenintuïtieve advies dat ik geef, en het valt bij product owners vaak het beste. Elke feature die je in je applicatie hebt zitten moet onderhouden worden. Elke feature vergroot de complexiteit. Soms is de snelste manier om weer vaart te krijgen niet iets toevoegen, maar iets weghalen. Dat ene dashboard dat niemand gebruikt. Die export-functie die drie jaar geleden is gebouwd voor één klant. Weg ermee. Minder code, minder onderhoud, meer snelheid.
3. Maak technische schuld bespreekbaar, zonder in uren te vervallen.
Het gesprek over technical debt mislukt vaak omdat het in de verkeerde taal wordt gevoerd. Je tech lead praat over 'code quality' en 'refactoring.' Je stakeholder hoort: “het team wil leuke dingen doen in plaats van features bouwen.” De brug daartussen ben jij. En die brug bouw je niet met urenramingen, maar met impact. Laat zien wat het kost. Laat zien wat het oplevert. Gebruik data, niet gevoel.
“ Als je roadmap meer een wensenlijst is dan een plan, is technical debt meestal de reden. ”
Dennis Bunskoek
Hoe we dit concreet aanpakken
Om dat in de praktijk te brengen, hebben we bij Leukeleu de Feature Impact Tool (FIT) ontwikkeld. FIT maakt technische schuld zichtbaar in cijfers. Niet in abstracte metrics voor developers, maar in dashboards die een product owner, product manager of CTO kan gebruiken in het gesprek met de beslissers.
Wat kost je huidige technische schuld aan ontwikkelsnelheid? Welke componenten veroorzaken de meeste vertraging? Wat gebeurt er als je wél investeert in onderhoud, en wat als je het nog een jaar uitstelt?
Uit het jaarlijkse onderzoek van Productowner.nl onder product owners en leidinggevenden blijkt dat technical debt in meer dan de helft van de gevallen de hoofdreden is dat roadmaps vertraging oplopen. Dat is geen technisch detail. Dat is een bedrijfsprobleem.
Wil je weten waar jij staat?
Als je dit herkent - de stroperiger wordende sprints, de stakeholders die onrustig worden, het gevoel dat je roadmap meer een wensenlijst is dan een plan - dan wil ik je uitnodigen voor een Technical Debt Check. In twee uur brengen we samen in kaart hoe het er écht voor staat. Geen verkooppraatje, maar een eerlijke analyse met concrete handvatten.
De sessie is gratis en vrijblijvend. En als blijkt dat je ons niet nodig hebt, is dat prima. Dan heb je in ieder geval de cijfers om het gesprek zelf te voeren.