Technical Debt: A Framework for Product Managers


Here is a post that discusses why and how product managers must access and manage technical debt. Technical debt often first considered as solely theory, until the pressures of time and customer desires create the need for compromise and quick and dirty shortcuts. Once the results of these pressures start to build up and create an amount of technical debt that demands a solution.

Technical debt is incurred when trade offs are taken in order to have shorter time-to-market and capital preservation. But after some time of building on the amount of technical debt in an organization it limits productivity and increases the amount of time needed to implement new features. Product managers are meant to balance out the short and long terms gains of ever decision on a product, but they should also keep track of the technical debt built into the codebase. Introducing a framework that anticipates any inadvertent debt that could occur and manage it as a roadmap item.

Fowler, famously, categorizes technical debt as reckless vs. prudent and deliberate vs. inadvertent – while this explains how dept is taken on it doesn’t demonstrate what or where this debt is added.

By using the framework above as a checklist for new feature development, even nontechnical product managers can assess the risks and damage of accumulating technical debt. Including these six parameters as flags the requirements management tool against every feature and defect would be the simplest method to guarantees that debt is thought about and decided by the team whether it is worth  paying back. Using this to report on areas that have stored technical debt is a good use of this method.

Quantifying technical debt is a good practice because although there is no benchmark for acceptable technical debt determining how debt has changed over time can help any organization.

To read the full post go to:

Filed in: Technical Debt
  This report describes the effects of different industrial factors on  structural quality. Structural quality differed across technologies with COBOL  applications generally having the lowest densities of critical weaknesses,  while JAVA-EE had the highest densities. While structural quality differed  slightly across industry segments, there was almost no effect from whether the  application was in- or outsourced, or whether it was produced on- or off-shore.  Large variations in the densities in critical weaknesses across applications  suggested the major factors in structural quality are more related to  conditions specific to each application. CRASH Report 2020: CAST Research on  the Structural Condition of Critical Applications Report
Get the Pulse Newsletter  Sign up for the latest Software Intelligence news Subscribe Now <>
Open source is part of almost every software capability we use today. At the  very least libraries, frameworks or databases that get used in mission critical  IT systems. In some cases entire systems being build on top of open source  foundations. Since we have been benchmarking IT software for years, we thought  we would set our sights on some of the most commonly used open source software  (OSS) projects. Software Intelligence Report <> Papers
Making sense of cloud transitions for financial and telecoms firms Cloud  migration 2.0: shifting priorities for application modernization in 2019  Research Report
Load more reviews
Thank you for the review! Your review must be approved first
New code

You've already submitted a review for this item