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
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
In our 29-criteria evaluation of the static application security testing (SAST)  market, we identified the 10 most significant vendors — CAST, CA Veracode,  Checkmarx, IBM, Micro Focus, Parasoft, Rogue Wave Software, SiteLock,  SonarSource, and Synopsys — and researched, analyzed, and scored them. This  report shows how each measures up and helps security professionals make the  right choice. Forrester Wave: Static Application Security Testing, Q4 2017  Analyst Paper
This study by CAST reveals potential reasons for poor software quality that  puts businesses at risk, including clashes with management and little  understanding of system architecture. What Motivates Today’s Top Performing  Developers Survey
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