Technical debt is the cost of writing code the fast way instead of the right way. A hack to hit a launch deadline. An architecture that made sense in year one but doesn't scale in year three. It's a bill that eventually comes due.
Ward Cunningham coined the term, and the financial analogy is intentional. Small amounts of debt are fine, you move faster now and pay it down later. But if you never pay it down, interest accrues. What took an afternoon to build now takes a week to change, because everything's tangled up in the original shortcut.
How it shows up
You know you've got real tech debt when a "simple" feature request turns into a three-week engineering project. Or when onboarding a new engineer means handing them a map of hidden hazards. Teams with heavy debt ship slower over time, not faster, because every new thing they build has to navigate around the old mess.
What product teams should do
Keep debt paydown on the roadmap. It's not exciting to stakeholders, but it needs dedicated time, not just a vague promise to "clean things up someday."
Some teams reserve 20% of each sprint for debt work. Others run periodic cleanup sprints. What doesn't work is pretending it'll sort itself out. It compounds until a full rewrite becomes cheaper than continued maintenance.