Tech debt for PMs
Technical debt is the future cost created when a product or system carries a shortcut, constraint, or accumulated complexity. I use the metaphor carefully. Some shortcuts are deliberate and sensible when they buy learning or speed. Others make future changes slower, riskier, or more expensive. The important product question is not whether the code is elegant; it is how the technical condition affects customers, the team, and the choices we need to make.
I do not treat every engineering cleanup item as technical debt, and I do not use the label as a way to win priority automatically. I ask what consequence the condition creates, who experiences it, how soon it matters, and what evidence supports the claim.
Connect the debt to an outcome
I start by asking what the debt changes in the product system. It may increase incident risk, make a customer workflow unreliable, slow a high-value change, limit an integration, weaken privacy controls, or consume engineering attention through repeated workarounds. Sometimes the effect is mainly on developer experience. That can still matter when it changes delivery quality, retention, or the team’s ability to respond.
I write the consequence in plain language. “Refactor the service layer” describes an activity. “Adding a permission rule requires changes in four coupled areas and makes review difficult” describes a condition I can discuss. I ask engineering to explain the mechanism and the evidence rather than accepting a vague statement that the system is messy.
A problem statement for PMs helps me frame the affected customer or team context. The statement may be internal, but it should still identify who is affected, what is difficult, and why the problem matters.
Separate types of debt
I find it useful to distinguish debt by the risk it creates. Code or architecture debt can make changes fragile. Test debt can make regressions harder to detect. Data debt can weaken reporting, migrations, or model quality. Infrastructure debt can increase operational risk. Design or content debt can create inconsistent experiences and support burden. Process debt can leave ownership or decision rules unclear.
These categories overlap, so I do not create a taxonomy just to create one. The purpose is to identify the right evidence and owner. A reliability concern may need operational measures. A confusing workflow may need customer observation. A data issue may require understanding lineage and usage before I prioritize a rewrite.
I also distinguish debt from ordinary bugs, new capability work, and platform investment. The same piece of work can serve more than one purpose, but naming the primary reason helps me explain the tradeoff. A security vulnerability is not merely a backlog item to rank by feature appeal.
Make the cost visible without false precision
I ask the team to describe the current cost and the likely future consequence. Useful evidence may include repeated incidents, failed deployments, long review cycles, duplicated work, blocked roadmap items, manual operations, support themes, or a pattern of risky changes. I do not require a perfect calculation before taking a serious risk seriously.
When we estimate, I label estimates as estimates. I avoid invented percentages or a made-up dollar value designed to make maintenance sound more important. A qualitative description of severity, frequency, reach, and reversibility can be more honest than false precision.
I also include the cost of not doing the work and the cost of doing it now. A large refactor can disrupt delivery, consume scarce expertise, or introduce migration risk. A small change can reduce friction immediately. I want to see both sides of the decision.
Prioritize by consequence and timing
I prioritize technical debt alongside customer, business, compliance, reliability, and strategic work. I consider the severity of failure, the likelihood of occurrence, the customers or systems affected, the effort to contain the issue, and whether delay makes the future work harder. I pay special attention to debt that blocks learning or makes an important promise difficult to keep.
Some debt deserves immediate action because the downside is unacceptable or the window to fix it is closing. Some is best addressed opportunistically when the team is already in the area. Some should be accepted explicitly because the consequence is low or the product direction is still uncertain. “Not now” is a valid decision when I record the reason and the trigger for revisiting it.
I use weighted scoring for product managers only as a conversation aid when multiple tradeoffs need to be compared. A score does not replace engineering judgment or hide a risk that should be handled as a constraint.
Choose the smallest responsible intervention
I do not assume the answer is a rewrite. I ask whether a test, boundary, migration step, monitoring improvement, documentation change, dependency update, simplification, or targeted refactor can reduce the consequence. The intervention should match the problem we can explain.
I include operational work in the plan: rollout, rollback, data validation, observability, ownership, support communication, and follow-up checks. A technically cleaner system that creates an unreviewed migration failure is not a clear win.
When the uncertainty is about whether an approach will work, I may start with a spike for PMs rather than committing to a large piece of debt work. The spike should have its own question and exit condition; it should not become a permanent delay.
Make debt part of normal product planning
I prefer to make important debt visible in the same planning system as other product work, with a link to the affected outcome and the owning team. I also look for ways to reduce new debt: define the smallest honest scope, involve engineering early, make non-functional requirements visible, and avoid treating every temporary choice as free.
I do not demand that every shortcut be eliminated. Speed can be a rational choice when the learning is valuable and the consequences are contained. The responsibility is to make the tradeoff explicit, watch the condition, and avoid pretending that tomorrow’s cost does not exist.
My bottom line is that technical debt is a product concern when it changes the reliability, speed, risk, or flexibility of the product system. I manage it by connecting technical conditions to outcomes, using evidence without invented precision, and making conscious decisions about what to fix, defer, or accept.
Next step
I develop that cross-functional judgment through the Technical Product Manager Certification, a commercial Product HQ resource. The Product HQ newsletter shares practical product and delivery lessons.
