a.k.a. Why & How Product Managers must assess, account & groom technical debt
Context
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:
| 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.