The most effective place I've worked had a fixed allocation to technical debt work (25%) and let engineering agree how to prioritise that. Want to rewrite it in Rust? If you get buy-in from the rest of the technical team to say that that's more important than sorting out the database schema or whatever you can do that, but you'd better be able to do it piece by piece and keep delivering business value the whole time.
Theoretically someone who understood both the business and the technical side of things ought to be able to weigh up individual tasks from both sides and figure out which was higher priority. But in practice that seems very hard - you'd need both intimate knowledge of both domains and immunity to organisational politics. Explicitly adjusting that high-level dial (so maybe the 25% becomes 50% when it's a codebase you want to publish/reuse, or 0% when it's an EOL project that you're just running until it falls apart) might be the best you can do in practice.
Worked in a similar setup as a PM and really liked it. As you said, it can be somewhat apples-to-oranges comparing new functionality with a stream of tech debt opportunities, so it’s helpful to target a ratio, more like stocks/bonds in a portfolio.
We called it “product health” so it could encompass tech debt but also UX debt, performance, cosmetics, etc.
Theoretically someone who understood both the business and the technical side of things ought to be able to weigh up individual tasks from both sides and figure out which was higher priority. But in practice that seems very hard - you'd need both intimate knowledge of both domains and immunity to organisational politics. Explicitly adjusting that high-level dial (so maybe the 25% becomes 50% when it's a codebase you want to publish/reuse, or 0% when it's an EOL project that you're just running until it falls apart) might be the best you can do in practice.