Marcus Castenfors' principle, stated plainly: the first rule of tech debt is talking about it — openly and explicitly — rather than hiding it as invisible, underground work squeezed in between "real" roadmap items.
Tech debt hidden from stakeholders becomes tech debt stakeholders never fund. Once it's named, it can compete for planning time and budget on equal footing with new-value work — see Three Buckets of Product Work: New, Existing, Protect Value and the Household Budget Analogy for how to make that funding case. It also feeds the Car/Vehicle Analogy for Transformation Readiness: an org that hides engine problems can't explain why the vehicle won't reach the destination.
Surface tech debt and infrastructure constraints explicitly in planning and stakeholder conversations — put it on the roadmap, name it in reviews, quantify it — instead of treating it as something only engineers are allowed to know about.
Whether a product manager can pitch tech debt as a compelling business initiative — standing alongside an engineer, not leaving it entirely to engineering to justify — is a useful diagnostic for how far a transformation has actually progressed, not just a communication nicety.
Apply: if tech-debt pitches are always engineer-only, product hasn't genuinely taken shared ownership of protecting value, regardless of what the transformation's stated intentions are. See Household Budget Analogy, Three Buckets of Product Work: New, Existing, Protect Value.
Julia Barham frames advocating for fixing technical debt as unavoidable payment — you pay for it upfront or you pay more later. Attaching a dollar value to the debt (treating the team or product like its own P&L) reframes the ask: instead of looking like "a stick in the mud" resisting new features, the PM is seen as "a steward of the business." See "Don't Scale Expensive Problems" (Architectural Debt Mistake) for the scaling mistake this addresses.