Some product owners don't want to address technical debt. They only want to add features to a product or system. And that's a huge problem.

The product owner has the responsibility for value of the entire system. That means that the product owner has to address features, technical debt, defects, whatever needs to be ranked so that the team knows what to do when. If the product owner does not rank the technical debt and the existing defects in addition to the features, the team will have trouble sooner or later delivering features.

So what's a team to do?

1. It's time for a heart-to-heart talk with the product owner. The product owner first needs to know that it is his/her job to rank everything for the iteration. It's possible he or she does not know.
2. If you are not tracking velocity, start. Remember, velocity is a trend, and will help your product owner see what is going on. Because your velocity will go down as your technical debt goes up, and your product owner needs to know that now.
3. If you are not tracking the number of defects found and fixed in an iteration, start now. Make this a trend, not a number. Trends are what's important. 
4. Consider tracking Fault Feedback Ratio, the number of bad fixes to total fixes as a trend on an iteration basis. This tells you if the developers and testers are making progress or spinning their wheels.
5. Make fixing technical debt a part of each feature. I don't understand how anyone can prevent you from doing this. I do understand how insufficient estimation can prevent initial test automation. But a team has the ability to say, "Wait a minute, we are not really done." 

Remember, the team has a the "done" card. If a team wants to play the done card and define what done means, and swarm around a story, making sure that they have prevented technical debt from accumulating, they can. I'm not talking about gold-plating, adding more features. I am talking about code review, architectural review, test development at all levels, whatever you need to know that the code works.

Not fixing technical debt is behavior you want to prevent, or stop early. But, if you can't stop it early, make sure the product owner sees the reality of his or her decisions. This is why short iterations are such a good idea. Your product owner might even have a good reason for his or her feature-itis. But if they acknowledge the reason for the feature-itis and explain when it will end, the team has a shot of retaining its sanity.

The more features a team adds without address technical debt or defects, the more technical debt a team adds. And, that's not acceptable, regardless of your lifecycle.