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 assess Continue reading Technical Debt Assessment framework for Product Managers
