Technical debt
Technical debt is the future cost created when a team chooses a faster or simpler solution now over a better one that would take longer. Like financial debt, it accrues interest: each change in the affected area takes more time and carries more risk until the debt is repaid through refactoring. Ward Cunningham coined the metaphor in 1992.
Why it matters for a PM
Debt is not a failure in itself: taking it on deliberately can be the right call to learn quickly or meet a deadline. The problem is debt nobody tracks, which shows up as slower delivery, recurring bugs and estimates that keep growing. Because repaying it competes with features, the decision belongs on the roadmap, and the PM should take part in it.
Example
To launch on time, a team hardcodes the tax rules of a single country. A year later every new country takes six weeks instead of one. The PM brings the measured cost to roadmap planning, and the team schedules the rework before the next two launches.
Key points
- A well-known quadrant by Martin Fowler crosses two questions: was the debt taken on purpose, and was it prudent or reckless?
- Interest is paid where code changes often; debt in stable areas can wait.
- Make debt visible with concrete costs: delays, incidents, time lost on each change.
- When you take on debt on purpose, record the decision and a plan to repay it.
Common mistakes
- Treating refactoring requests as engineers' preferences rather than product risk.
- Promising a dedicated “debt sprint” that never comes.
- Calling every bug or every old technology “technical debt”.
Go further with Module
The courses and lessons that cover this concept: