Prioritizing Tech Debt
Product managers hear "tech debt" as a black hole. Node.js tech leads translate Node upgrades, pool tuning, and dependency refreshes into risk language product can prioritize.
Recipe
Quick-reference recipe card - copy-paste ready.
## Tech Debt Ticket Template
**Title:** Node 24 upgrade - orders-api
**User impact if ignored:** CVE exposure; hiring friction; incident MTTR +30%
**User impact if done:** Faster cold start; aligned platform libs
**Effort:** 5 engineer-days
**Recommendation:** Next sprint (P1)
**Product trade-off:** Delays feature X by 3 days OR swap 2 smaller storiesWhen to reach for this:
- Sprint planning debt vs feature tension
- Post-incident "we should have fixed pool months ago"
- Quarterly planning with EM and PM
Working Example
Debt Register (Shared with PM)
| Item | Risk if deferred | Effort | Priority |
|---|---|---|---|
| Node 22 → 24 LTS | CVE, unsupported runtime | 8d | P1 |
pg pool max 50 → 20 + query fix | Repeat SEV2 pool timeouts | 3d | P0 |
| Renovate backlog 40 CVEs | Supply chain audit fail | 5d | P1 |
| Express 4 → 5 | Security patches end | 13d | P2 |
| Remove 12 stale feature flags | Confusion, dead code | 2d | P3 |
Sprint negotiation:
PM goal: 3 features
TL ask: P0 pool + P1 Node upgrade (11d)
Agreed: 2 features + pool this sprint; Node upgrade next; flags in slack timeDeep Dive
Node-Specific Debt Categories
| Category | Examples | Product framing |
|---|---|---|
| Runtime | Node LTS, OpenSSL | "Security and compliance" |
| Data path | Pool, indexes, N+1 | "Checkout reliability" |
| Dependencies | CVE, deprecated SDK | "Audit and vendor risk" |
| Observability | Missing trace on queue | "Faster incident recovery" |
| Delivery | No canary | "Safer launches" |
Prioritization Matrix
High incident risk
│
P0 │ P1
(now) │ (next sprint)
──────────────┼──────────────
P3 │ P2
(backlog) │ (quarterly)
│
Low incident risk
←── High velocity cost ──→Making 20% Capacity Real
1. EM + PM sign capacity split quarterly
2. Debt items in same backlog as features (not separate swamp)
3. TL brings top 3 debt risks to every planning
4. Celebrate prevented incidents (pool tune metrics)- Link Node Upgrade Policy
What Is NOT Debt
- Desired refactor with no risk/velocity argument
- "I don't like Prisma" without measurable pain
- Rewriting for résumé technologies
Gotchas
- Debt without business language - PM always picks features. Fix: Incident $ and audit dates.
- Infinite debt list - Noise. Fix: Top 10 register; archive rest.
- Surprise debt sprint - Trust break. Fix: Pre-negotiated capacity.
- Only fixing debt in incidents - Expensive. Fix: P0 from post-mortem within 2 sprints.
- Ignoring worker debt - API polished, queue flaky. Fix: Register per deployable.
Alternatives
| Alternative | Use When | Don't Use When |
|---|---|---|
| 10% chaos budget | Google-style | Need explicit items for PM |
| Debt-only sprint | CVE emergency | Quarterly at most |
| Boy scout rule | Micro debt | Node upgrade size |
FAQs
How do we estimate Node upgrade?
Use Node Upgrade Skill checklist: native modules, CI, staging soak. Add 30% buffer.
Should PM rank debt items?
PM ranks by user/business risk with TL input on technical severity. Joint P0/P1 agreement.
Related
- Product Collaboration Basics - partnership
- Estimation & Risk - buffers
- Node Upgrade Policy - LTS rule
- Dependency Governance - CVE process
- Working with Product Best Practices - condensed list
Stack versions: This page was written for Node.js 24.18.0 (Active LTS), npm 10+, TypeScript 5.6+, Express 5, Fastify 5, and NestJS 11.