What is Technical Debt?
Technical debt is the implied future cost of choosing an easy or fast solution now instead of a more robust one. Like financial debt, it accrues "interest": shortcuts make the codebase harder to change, slowing future development and increasing bugs until the debt is "repaid" through refactoring.
Some tech debt is deliberate and smart (ship fast to learn, clean up later); some is accidental (from rushed work or evolving requirements). Either way, unmanaged debt compounds — eventually a team spends most of its time fighting the codebase rather than building value.
PMs must engage with tech debt rather than ignore it as "an engineering thing." Allocating roadmap capacity to paying it down (often a fixed percentage of each sprint), and weighing the speed-versus-quality tradeoff explicitly, keeps the team's long-term velocity healthy. Ignoring it is how roadmaps quietly grind to a halt.
Examples
- A team ships an MVP with a hardcoded workaround, logging the cleanup as tracked tech debt.
- A PM reserves 20% of each sprint for debt paydown after velocity drops due to brittle code.
Where PMs use this
Related terms
Minimum Viable Product (MVP)
The simplest version of a product that delivers enough value to learn from real users.
Velocity
A measure of how much work a team completes in a sprint, used to forecast future capacity.
Product Backlog
A prioritized, continuously updated list of everything that might be built for a product.
Prioritization
The discipline of deciding what to work on next by weighing value, effort, and strategic fit.