How do you prioritize tech debt against other features?

Balancing technical debt and new features is one of the most critical responsibilities of a product manager — especially in high-scale domains like logistics, where reliability and speed are both non-negotiable. I typically approach it through a three-part framework: impact, timing, and trust.

I don’t treat tech debt as just “engineering clean-up.” I partner with engineering to articulate its impact in business terms:

• Will it slow us down in the next 1–2 quarters?

• Does it increase the risk of outages or bugs in a key workflow?

• Will it block performance, compliance, or scalability needs?

I try to bundle tech debt into:

• Every sprint (small % reserved): Refactors, logging improvements, test coverage.

• Feature work (opportunistic clean-up): If we’re in the code anyway, fix adjacent debt.

• Major releases or roadmap milestones (dedicated cycles): For larger infra/architecture shifts, like moving to event-driven systems.

This creates a sustainable cadence without needing to “pause” for months of tech debt work.

I keep a shared “engineering health backlog” with tech leads — including debt items, time bombs, and platform improvements. I use it in quarterly planning and proactively communicate with cross-functional stakeholders (sales, ops, execs) about why we’re investing in platform stability.

This builds trust and avoids misunderstanding between different stakeholders regarding the efficient utilization of engineering bandwidth.