Tag Archives: Roadmap

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

A responsible species called product manager

Is that an amusing title? If yes, then product management (PM) has retained its title of being one of the most esoteric functions in IT. And this has reasons: compared to the epic number of service organizations, there exist only a few product companies, implying a fewer number of product managers – a breed that can’t be found in herds. Despite of a severe need for PMs within  the chamber, the absolute demand compared to other profiles is minuscule, causing the profile to remain unexplored even by recruiters. Whether or not that makes PM a big deal, the ones that have tasted it will agree that it demands a unique mix of aptitude, attitude & innovation – that can’t be taught in class. And above everything else, it demands hell-a-lot of responsibility.

Most people destroy the niche status of product management (PM) by confusing it with project management. I would say, planning, execution & reporting is only a minuscule part of the PM profile. PM is everything about the product from vision to release which is not a simple 1-step transition. At least, it involves:

  • Envisioning a product that solves a problem or improves some productivity parameter
  • Understanding the market for the product & preparing a market requirement document (MRD)
  • Creating a concept to get management buy-in; At senior levels with P&L responsibility, it may accompany projecting numbers
  • Detailing the product functionality & behavior through prototypes & product requirement document (PRD)
  • Maintaining a prioritized feature roadmap Continue reading A responsible species called product manager