All of these product management processes seem to assume there's no underlying maintenance or tech debt that needs some level of attention. And there almost always is, but it's really hard to measure impact because it's usually "hidden" (that is, it's not a direct impact, but it ultimately affects velocity, on-boarding, developer happiness, etc). So with "tricks" like this they get relegated to "low impact", while "high impact" (typically "user facing features") get prioritized.

And there's lots of other things that have hidden or very difficult to measure impacts. These often revolve around developer happiness and growth. For example, ignoring a complex, bugging and/or aging codebase can affect attrition (among other things), which will quickly get _very_ expensive: as a team starts losing developers, the remaining developers have to carve out more and more time to interview and onboard. Not to mention the direct company costs of turning over employees. And trying to find quality employees who are willing to work with in that codebase.

And maybe this sort of thing should be addressed "out of band" - ancillary to the product management lifecycle. But that's really hard to maintain in most orgs.