How to Talk About Technical Debt to a COPIL
Technical debt is the subject no one wants to address in COPIL.
PMs avoid it because it's difficult to quantify.
Engineers try to push but know they'll be told to prioritize features.
Result: it's never really addressed, or not enough, until the day it becomes blocking.
The problem with the usual framing
Most COPILs love talking about new features.
Much less about topics that silently slow down the organization for months.
Technical debt is part of these topics.
The problem isn't that leaders "don't understand tech".
The problem is that technical debt is often presented as an engineering problem, whereas it's actually a problem of future product capacity.
The right framing: product impact
Technical debt becomes decisive when it's translated into measurable product impact.
Before
"We need X sprints to refactor feature Y."
After
"Each new feature on checkout currently takes 3x longer than it should, due to strong coupling between the payment module and the catalog.
If we don't resolve this before Q3, the personalization project will take 6 weeks instead of 2."
The difference? The second argument is expressed in future opportunity cost, not past technical work.
The impact/urgency matrix
To present technical debt in a strategic meeting, I use a simple matrix:
| Type of debt | Impact on velocity | Risk if untreated | Priority |
|---|---|---|---|
| Payment module coupling | High (-40% on checkout) | Blocks Q3 | P1 |
| Insufficient unit tests | Medium | Frequent regressions | P2 |
| Missing logging | Low | Slow debugging | P3 |
This presentation transforms an opaque subject into a normal prioritization decision.
What NOT to do
- Don't put everything in the same basket. (be strategic and don't fight all battles) "We have debt everywhere" leads nowhere. Select 2-3 critical points.
- Don't speak in technical jargon. Coupling, refactoring, legacy — these words don't resonate.
- Don't request a generic dedicated sprint. Ask for a specific result: "reduce the average delivery time on checkout from 3 weeks to 1 week by the end of Q2."
The right moment to talk about it
The best moment to address technical debt in COPIL is before a major project, not during.
Integrate it into the roadmap planning: "to deliver X, we need to first address Y."
To conclude
Not all technical debts should be addressed immediately.
Some can stay in place for a long time without major impact.
The PM's role isn't to defend "less debt" abstractly.
The role is to identify:
which debts really slow down the product,
which increase risk,
and which threaten the future roadmap.
Otherwise, the discussion becomes ideological instead of strategic.
If you have questions about how to structure this type of presentation, feel free to contact me.