The term "technical debt" has increasingly become an organizational comfort zone. It provides an easy label for a wide array of customer-facing system issues, conveniently keeping them out of the product and business discourse. While I've recently seen the term "product debt" emerge, it still doesn't quite solve the root problem.
Many decisions that are typically perceived as the sole responsibility of the engineering organization, and which product managers often avoid, are, in reality, purely product and business decisions. Even if product managers cannot always dive into the technical intricacies of implementation or define system requirements and workflows, they must still own the decision.
"The best engineering can do" is not a product goal; it's an evasion of decision-making.
The Business of Information Security
Take system information security, for example. On the surface, it seems like a collection of regulatory and technical requirements that simply need to be "complied with." In practice, I often hear product managers telling engineering leaders, "This is your domain." And indeed, in many companies, especially in early-stage startups, the VP of R&D assumes the responsibility for regulatory compliance, such as SOC2 or ISO27001.
But information security is fundamentally a business issue driven by the risk it poses to the entire company. The cost of failure directly impacts customer trust, damages the brand, and can lead to severe legal and regulatory exposure.
In my view, Product needs to define the level of risk the company is willing to accept. They should establish the standards and regulations the company commits to, analyze the trade-offs, manage customer commitments, and prioritize the roadmap accordingly. The focus shouldn't be on the how, but on the how much and whether at all.
Conversely, the engineering organization must translate these goals and boundaries into technical solutions across the entire system. Their job is to plan the technical roadmap, surface hidden risks, and execute the implementation.
System Quality and Availability
Another critical area is system quality and availability. Too often, I hear the sentiment: "Quality and availability are the engineers' problem - just make it the best it can possibly be."
But "the best it can be" is not a product goal; it's an evasion of decision-making.
Achieving high quality, ensuring system availability, and building disaster recovery capabilities often come at a steep price. These factors impact cloud infrastructure costs, introduce architectural complexity, increase operational overhead, and sometimes come at the expense of delivering other customer-facing features.
Any issue with a direct, measurable business impact, demands comprehensive business accountability. That accountability sits squarely with Product.
Product plays a pivotal role here as well. It is up to Product to analyze market and customers' needs and define comprehensive system requirements. This includes establishing quantitative targets, such as SLOs, SLAs, MTTR, or capacity limits, as well as outlining overarching requirements like geographical deployment, data storage regulations, Disaster Recovery (DR) strategies and even cost structure.
Engineering must then translate these product definitions into architecture, technical specifications, and effort estimations, while presenting the associated financial implications, both initial and ongoing, for approval.
Rethinking Debt
Some issues are purely technical and belong entirely to engineering. However, any issue that has a direct, measurable business impact and where the cost of failure is a business cost, demands comprehensive business accountability. That accountability sits squarely with Product.
Engineering is not off the hook here. They should manage a long-term, prioritized technological roadmap. Planning for it, prioritizing work items out of it, especially vs the product roadmap should be a joint effort by both the VP of Product and the VP of Engineering. The final call sits with the VP of Product as the overall business owner.
The Organizational Debt
Ultimately, the concept of "technical debt" is misleading. It creates the illusion of an internal, hidden issue managed exclusively by the engineering team.
When an engineering organization is forced to pay the price for business decisions that were never in their jurisdiction, it creates a much deeper problem: an organizational and business debt, not just a technical one.