Do you take it into account when working on an existing file/unit where you have to add new functionality, but it also might have technical debt?
If so how do you do this process?
i stopped using the term technical debt. 'technical debt', 'refactoring', etc are not helpful to product owners. if something is contained in an area youre never touching, its not really worth even tracking because making it better won't improve any business metrics. tickets get lost, better to throw a comment in the code if anyone starts touching it later. If new functionality requires code changes, then that's just part of the requirements for that functionality. If some bit of code is slowing you down, then its a first class ticket to speed up developers, with explicit numbers on hours saved.
at the end of the day, the business doesn't care about code quality, it cares about revenue/profit, so reframe any tech debt in those terms
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.
So I agree that the term is here to stay, but there’s better ways to communicate it to product/management. Like your example, making it clear to product what shortcuts were taken and how it will need time to fully implement. Code improvement vs tech debt doesn’t really make a difference, it’s just getting that conversation convincing