Tips for Prioritizing Technical Debt in Product Roadmaps

I've been asked several times in interviews how I prioritize features and bugs for my development teams. I also think you need to throw fixing technical debt into the mix. My method is honestly fairly simple: I build a value vs complexity model. You'll need to get a t-shirt size for items from engineering to figure out the complexity. The value can be subjective, for example - If 1 user out of 10 million wants a change then maybe it's low value - If the 1 user supplies 90% of your revenue then that might push it to high value Technical debt and bugs also have a value assigned to them. This might be an unpopular opinion, but not every bug is a high priority/value. Technical debt resolution can be a very high value if it's causing delays in new features. Once you have that info you can lay out the matrix to plan out sprints and long term roadmaps. Anyone else have a different method?

The word "Tech Debt" is thrown around a lot... but it helps to start thinking of classes of "Tech Liabilities" and their associated costs: 💵 Non-Interest Accruing Tech Debt Minor issues like stylistic refactoring, dead code-paths, and old feature flags, which can be postponed with minimal/no impact. 💹 Interest Accruing Tech Debt Costs that increase with time or product usage like a manual migration you need to do on a growing customer base, the db that's duct taped together. ⚠ Black Swan Tech Liabilities Risks of disproportionate impact from minor or misunderstood factors, covering security breaches, safety hazards, and unexpected market demands. ⚖️ Hedge-able & Forecastable Liability Predictable issues with estimable impacts, including known bugs and insufficient testing leading to somewhat predictable UX bumps, costs, or support challenges. 👉 And these all manifest in the form of: 💰 Lump sums: Hits to brand equity, churned customers, late night on-call shifts or other issues that are paid largely at once - these could be small, or massive in impact and sizing is crucial here. 💳 Subscription Taxes Ongoing distractions from unresolved issues, requiring frequent revisits by developers to past projects due to incomplete or poorly tested changes. 🚏 Metered Taxes Problems that increase with more changes or growth, slowing down development due to extensive refactoring needs or inadequately tested code. That is to say, they're not all equal! It's helpful to categorize your liabilities/fees and ensure you're burning down liabilities based on the stage of your business and the size/risk of impacts.

Software systems are bound to become complex over time, sometimes to the level of demanding a complete rewrite. How do good engineers think about these migrations, their cost and sometimes years-long execution? 1. Boiling frog problem: good engineers will pay attention to and prioritize fixing tech debt as shortcuts become costlier over time. Good leaders at all levels should bring visibility to their managers -- what shortcuts were or are being taken, what fast-follow cleanups need to be done, why velocity is taking a hit because of complexity, and eventually, when it’s time to commit to a complete infra rewrite. 2. Business goes on: you can’t stop building features and investing in topline goals. If you’re a platform team, you can’t ask your clients to stop running their business either. Good leaders advance their infra goals in balance with business goals. You may need new auxiliary metrics for your organization: velocity or reliability, which you can chase with infra migrations. 3. Deliver incremental impact: bring early returns, prove the value of migration and keep morale up. Whenever possible, aim to incrementally migrate pieces that would benefit the most from migration. For example, optimize for migrating pieces with a maximum value of (“complexity” x “number of upcoming projects touching the piece”).