Technical Debt Assessment framework for Product Managers

a.k.a. Why & How Product Managers must assess, account & groom technical debt

Context

Technical Debt explained (c) galorath.com
Technical Debt explained (c) galorath.com

When I started conceptualizing a new product 5 years back, the concept of technical debt only existed in theory. Over a period, the pressure of time & customers, drove features cuts, compromises, and unfortunately, some quick-and-dirty solutions. Post the short-term wins, its not too long before technical debt surfaces and forces a resolution.

Triggers

Technical debt is taken up for short-term advantages such as shorter time-to-market, and preserving capital. But in the long run, it reduces productivity, time available for new feature development and, God forbid, might keep you from crossing the chasm.

While Product Managers balance out the short and long term benefits/impact of every product decision, it is important that they keep track of the debt that is being baked in with every story. At the same time, having some framework to preempt the debt that is inadvertently introduced and proactively manage it as a roadmap item.

The Debt Assessment Framework

Fowler¬†categorizes debt as Reckless v/s Prudent, or Deliberate v/s Inadvertent. While this classification answers the ‘how’, it doesn’t provide¬†visibility into ‘what’ and ‘where’ of¬†debt is added. Without further classification, accounting debt is like having a balance sheet with just one account for liabilities. I would like¬†to further¬†categorize all the debt that is deliberately added and assess its risk upfront. Here’s how:

Risk assessment for (deliberate) technical debt
Type Potentially lacks.. User Visible Sales Risk Ops Risk
Business value Comprehensiveness in all business scenarios, Browser/Language support, Super admin rights, etc. Y Y N
User Experience Simple task flows, help cues, consistent design, mobility, Usability or A/B testing Y Y N
Performance Quick response, High availability, Clustering, CDN, Load/Stress test suite Y Y Y
Maintainability Data redundancy, Recovery, Migration, Configuration management, Sizing estimates, Documentation N N Y
Design/Architectural Portability, Modularity, Coding standards, & styles, Web services, Latest component versions; Has glue or duplicate code N Y Y
Test Automation Comprehensive coverage of functional/unit tests, either brittle or missing N N Y

If you’re wondering why (missing) features and defects don’t show in the list, that’s because they¬†are the fundamental work units for development and not actually debt.

Practical use

Using the above framework as checklist for all new feature development, even non-technical Product managers can easily assessthe technical debt being accumulated and the potential risk thereof.

The simplest solution is to include these 6 parameters as flags in your requirements management tool against every feature & defect –¬†PRD, Excel or Jira doesn’t really matter. This guarantees a thought to debt as each backlog¬†item is groomed, and allow the team to decide – as a collective – if they want to take up debt.

If you’d like a more mathematical approach to this metaphor, follow the link.

Using this data to report on areas where debt is stashed is good use. Using it to hold people accountable for debt, is bad use and against the usage policy of this framework.

Result

Quantification of technical debt is an invaluable metric to the Product development lifecycle. While there is no benchmark on acceptable debt, it can at least serve as an indicator of how debt changed over time Рmore like tracking kill-rate of defects.

As we move from Vision > MRD > PRD > User stories to cover breadth & depth, the definition of MVP could force us to target breadth first. In such situations, top management and sales is likely to carry a wrong picture of the depth. This is where data around technical debt comes handy in defining a pragmatic sales & marketing pitch, and set revenue targets accordingly.

With sales & operational risk now associated with every backlog item, product owners can better prioritize their roadmap by weighing debt items against ranked features & defects.

Keen to learn about how you manage debt – please comments below.

2 thoughts on “Technical Debt Assessment framework for Product Managers”

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.