![\"Technical](\"http:\/\/galorath.com\/wp-content\/uploads\/2011\/05\/technical-debt-300x235.jpg\")
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\u00a0cuts, 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.<\/p>\n
Triggers<\/h2>\n
Technical debt is taken up for\u00a0short-term advantages such as shorter time-to-market, and preserving\u00a0capital. But in the long run, it reduces productivity, time available for new feature development and, God forbid, might keep you from crossing the chasm<\/a>.<\/p>\n While\u00a0Product Managers balance out the short and\u00a0long term benefits\/impact of every\u00a0product 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\u00a0is inadvertently introduced\u00a0and proactively manage it as a roadmap item.<\/p>\n Fowler\u00a0categorizes debt<\/a> as Reckless v\/s Prudent, or Deliberate v\/s Inadvertent. While this classification answers the ‘how’, it doesn’t provide\u00a0visibility into ‘what’ and ‘where’ of\u00a0debt is added. Without further classification, accounting debt is like having a balance sheet with just one account for liabilities. I would like\u00a0to further\u00a0categorize all the debt that is deliberately added and assess its risk upfront. Here’s how:<\/p>\n If you’re wondering why (missing) features and defects don’t show in the list, that’s because they\u00a0are the fundamental work units for development and not actually debt.<\/p>\n Using\u00a0the above framework\u00a0as checklist for all new feature development, even non-technical Product managers can easily assessthe\u00a0technical debt being accumulated\u00a0and the potential risk thereof.<\/p>\n The simplest solution is to include these 6 parameters as flags in your requirements management tool against every feature & defect –\u00a0PRD, Excel or Jira doesn’t really matter. This guarantees a thought to debt as each backlog\u00a0item is groomed, and allow the team to decide – as a collective – if they want to take up debt.<\/p>\n If you’d like a more mathematical approach to this metaphor<\/a>, follow the link<\/a>.<\/p>\n Using this data to\u00a0report on areas where debt is stashed is good use.\u00a0Using it to hold people accountable for debt, is bad use <\/span>and against the usage policy of this framework.<\/p>\n Quantification of technical\u00a0debt\u00a0is an invaluable metric to the Product development lifecycle. While there is no\u00a0benchmark on acceptable\u00a0debt, it can at least serve as an indicator of how debt\u00a0changed over time – more like tracking kill-rate of defects.<\/p>\n As we move from Vision > MRD > PRD > User stories to cover breadth & depth, the definition\u00a0of 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\u00a0defining a pragmatic\u00a0sales & marketing pitch, and set revenue targets accordingly.<\/p>\n With\u00a0sales\u00a0& operational risk now associated with every backlog item, product owners can better prioritize their\u00a0roadmap by weighing debt items against ranked features & defects.<\/p>\n Keen to learn about how you manage debt – please comments below.<\/p>\n","protected":false},"excerpt":{"rendered":" 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\u00a0cuts, compromises, and unfortunately, some quick-and-dirty solutions. Post the short-term wins, its … Continue reading Technical Debt Assessment framework for Product Managers<\/span> The Debt Assessment Framework<\/h2>\n
\n
Type<\/th>\n Potentially lacks..<\/th>\n User Visible<\/th>\n Sales Risk<\/th>\n Ops Risk<\/th>\n<\/tr>\n<\/thead>\n Business value<\/td>\n Comprehensiveness in all business scenarios, Browser\/Language support, Super admin rights, etc.<\/td>\n Y<\/td>\n Y<\/span><\/td>\n N<\/td>\n<\/tr>\n\r\n User Experience<\/td>\n Simple task flows, help cues, consistent design, mobility,\u00a0Usability or A\/B testing<\/td>\n Y<\/td>\n Y<\/span><\/td>\n N<\/td>\n<\/tr>\n\r\n Performance<\/td>\n Quick response, High availability, Clustering, CDN, Load\/Stress test suite<\/td>\n Y<\/td>\n Y<\/span><\/td>\n Y<\/td>\n<\/tr>\n\r\n Maintainability<\/td>\n Data redundancy,\u00a0Recovery, Migration, Configuration management, Sizing estimates, Documentation<\/td>\n N<\/td>\n N<\/td>\n Y<\/span><\/td>\n<\/tr>\n\r\n Design\/Architectural<\/td>\n Portability, Modularity, Coding standards, & styles, Web services, Latest component versions; Has glue or duplicate code<\/td>\n N<\/td>\n Y<\/td>\n Y<\/span><\/td>\n<\/tr>\n\r\n Test Automation<\/td>\n Comprehensive coverage of\u00a0functional\/unit tests, either brittle or missing<\/td>\n N<\/td>\n N<\/td>\n Y<\/span><\/td>\n<\/tr>\n<\/tbody><\/table><\/div>\n Practical use<\/h2>\n
Result<\/h2>\n