How should product managers think about technical debt?

The metaphor is load-bearing

Debt has principal and interest. The principal is the shortcut; the interest is every future change that costs more because of it. Debt nobody touches charges no interest and can be safely ignored forever — which is why a blanket "let's clean up the codebase" quarter is usually a bad trade. It pays down principal on loans that weren't charging anything.

The right question is narrower: where is the interest actually being paid? That's identifiable — the modules where estimates are consistently wrong, where bugs cluster, where engineers negotiate about who has to go in.

Facebook's version of the bill

Facebook's mobile app was built on HTML5 to ship once across platforms — a completely rational trade at the time. The interest came due when mobile became the entire business and the performance ceiling of that choice became an existential constraint. The rewrite to native wasn't a refactor; it was a company-level bet made under duress.

The lesson isn't that the original choice was wrong. It's that the interest rate on a platform decision rises with the platform's importance, and nobody re-evaluated the loan as mobile went from side channel to main channel.

What a PM can actually do

Keep the debt on the same list as the features. Separate lists guarantee the debt list loses, because it's judged on different criteria by people with less power in the room.

Ask engineers for the specific delivery consequence rather than a severity rating. And when you deliberately take on debt to hit a date — which is often correct — write down what you took and what would trigger repaying it. Most debt becomes dangerous through forgetting, not through the original decision.