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.
Wat is technical debt?
Technical debt is de optelsom van snelle keuzes en shortcuts in software die op dat moment logisch waren, maar nu een prijs hebben. Net als financiële schuld betaal je rente: elke aanpassing wordt duurder, bugs zijn moeilijker te vinden, en je team besteedt steeds meer tijd aan onderhoud in plaats van aan nieuwe features.
Hoe weet ik hoeveel technical debt mijn software heeft?
De meest voorkomende signalen zijn: stijgende ontwikkeltijd per feature, terugkerende bugs, lang onboarden van nieuwe developers, en een team dat meer tijd kwijt is aan onderhoud dan aan de roadmap. Voor een concreet beeld biedt Leukeleu de Feature Impact Tool (FIT) en een gratis Technical Debt Check van twee uur.
Wat kost technical debt mijn organisatie?
Meer dan je denkt. In veel organisaties gaat meer dan de helft van de ontwikkelcapaciteit op aan onderhoud en workarounds in plaats van aan nieuwe functionaliteit. Dat betekent: een tragere roadmap, hogere kosten per feature, en ontevreden stakeholders. De Feature Impact Tool maakt deze kosten inzichtelijk in concrete cijfers.
Wat is de Feature Impact Tool (FIT)?
FIT is een door Leukeleu ontwikkelde tool die technical debt meetbaar maakt. Het toont in dashboards hoeveel ontwikkeltijd opgaat aan onderhoud, welke componenten de meeste schuld dragen, en wat de impact is op je roadmap. Zo kun je het gesprek met je directie of stakeholders voeren op basis van data in plaats van gevoel.
Hoe maak ik technical debt zichtbaar voor mijn directie of stakeholders?
De sleutel is vertalen naar business-taal. Niet "we moeten refactoren" maar "52% van onze sprintcapaciteit gaat naar onderhoud, en elke feature kost 40% meer dan een jaar geleden." Tools zoals FIT leveren precies die cijfers. Dennis Bunskoek van Leukeleu heeft hier meerdere podcastafleveringen over opgenomen bij De Product Owner Podcast.
Kan ik technical debt aanpakken zonder de roadmap stil te leggen?
Ja, en dat is ook de aanpak die we aanbevelen. We integreren verbetering in de reguliere sprints: elke sprint een stukje opruimen, naast het opleveren van nieuwe features. Zo wordt de software geleidelijk gezonder zonder dat je maanden stilstaat. De business roadmap en de technische roadmap zijn dezelfde roadmap.