But I also think:
1) The term technical debt is here to stay and thus it is helpful to discuss about dealing with this data
2) I worked on multiple projects where we did not called it technical debt but code improvements. We were usually implementing some features with the purpose of testing it with real users as fast as possible and if validated it should be launched to all. In this case we were writing down what we left out from code design to hard coded values so that when the decision to implement the full feature comes to have a good start.
In this case we were still discussing about code improvements and it what healthy for product managers to understand how come we can deploy so fast the feature working well for limited cases/users and then when deploying full scale we just need more time.
I see companies where the business understand this as having an advantage in the market as good code design helps be prepared for changes.