First, here's a primer on technical debt. Tech Debt is all those band-aide, glitchy workaround, ugly code, or labor-intensive workarounds deployed to get the product to customers faster. They're painful in the long run and generally can be a significant roadblock in the way of making your product stable.
Yes, the Product Owner and team should be tracking Tech Debt. Keep a list of all those ugly trolls lurking in your product is an excellent approach to better managing the product stability. At some point, you are going to have to deal with them.
When do you deal with Tech Debt? There are two different approaches to handling Tech Debt.
One method is the team will sprint 2-3 times with new user stories and then take 1 sprint to fix all the high priority items on the Tech Debt list. The team can either use a list of technical debt items or put Tech Debt items on cards in the product backlog. Tech Debt items should go through the sprint planning process like any other user story.
Another method is when Tech Debt is incurred, to put that Tech Debt on a card and place it in the backlog. Tech Debt when will get prioritized with the other user stories. The danger here is that it gets lost or never reaches high enough priority to be fixed.
Finally, a Tech Debt threshold is established. The threshold is expressed in terms of story points. The threshold clarifies how much Tech Debt the team is willing to accrue after a series of deployments.
It triggers the team to switch gears and start working on technical debt in the next sprint when the threshold is exceeded. This requires that all technical debt is in a card, and acceptance criteria is assigned to every Tech Debt card. Story point estimates are done on Tech Debt cards immediately.
The Product Owner keeps a rolling total of story points for technical debt. Once the threshold is exceeded, the team will go into the next sprint planning event focusing on Tech Debt cards and prioritizing the cards to focus on the essential Tech Debt cards to fix. An advantage to this approach is there is a quantifiable value to the amount of work (or rework technically) needed to eliminate the technical debt. This metric can be beneficial in determining the overall stability of the product. The lower the technical debt, the greater the product quality. It's not a one-to-one measurement between technical debt and quality, but there are strong connections between the two.