Tech Debt vs Features: A Prioritization Framework That Actually Works with Finance Teams

[eng_director_luis]

Michelle’s question in the other thread got me thinking: How do you prioritize tech debt vs feature work when both have legitimate ROI cases?

This is the eternal tension. Every quarter, my team faces the same conversation:

• Product: “This new enterprise integration will unlock $800K in pipeline.”
• Engineering: “Paying down API tech debt will make us 3x faster at building integrations.”

Both are true. Both matter. How do you choose?

The Problem with Traditional Prioritization

Most teams I’ve talked to handle this in one of three broken ways:

1. Features Always Win
Because features have direct revenue numbers and tech debt has “soft” benefits. This leads to compounding debt and eventual productivity collapse (see Maya’s startup story).

2. Tech Debt Gets Fixed Percentage
“We reserve 20% of capacity for tech debt.” Sounds good, but then you’re doing tech debt work even when there’s a critical revenue opportunity. And 20% is arbitrary—why not 15% or 30%?

3. Squeaky Wheel Gets the Grease
Whoever argues loudest (or whose crisis is most visible) wins the priority. This is chaos masquerading as decision-making.

All three of these approaches fail because they treat tech debt and features as different categories that need different rules.

A Better Way: Unified Business Impact Scoring

At my last company, we finally cracked this by putting tech debt and features on the same scoring system. Everything gets evaluated using the same criteria. May the highest score win.

Here’s the framework:

Business Impact Score (BIS) - Five Dimensions

Every initiative—whether it’s a feature or tech debt—gets scored 0-10 on five dimensions:

1. Revenue Impact (0-10)

• Features: Projected revenue from new capability
• Tech debt: Prevented revenue loss from incidents, delays, or lost deals

Examples:

• Enterprise SSO feature: $500K projected ARR → Score: 9
• Auth system refactor: Prevents $180K/year revenue leakage from failed onboardings → Score: 6

2. Risk Reduction (0-10)

• Features: Customer churn risk, competitive risk
• Tech debt: Security risk, compliance risk, operational risk

Examples:

• Mobile app feature: Prevents churn in mobile-first segment → Score: 6
• Legacy logging system fix: Eliminates SOC 2 audit failure risk → Score: 10

3. Velocity Multiplier (0-10)

• Features: Does this unlock follow-on opportunities?
• Tech debt: How much does this speed up future work?

Examples:

• API integration framework: Unlocks 10+ integration requests → Score: 8
• Refactor payment service: Makes future billing features 4x faster → Score: 9

4. Customer Satisfaction (0-10)

• Features: Direct user value, reduced friction
• Tech debt: Fewer bugs, better performance, faster fixes

Examples:

• Advanced reporting dashboard: High customer demand → Score: 8
• Notification system modernization: 80% reduction in notification bugs → Score: 7

5. Effort (Inverse) (0-10)

• Smaller effort = higher score
• This prevents “too expensive to do” from killing high-value work

Examples:

• Quick-win feature (1 sprint): Score: 9
• Large refactor (8 weeks): Score: 4
• Massive platform rewrite (6 months): Score: 1

Total Score: Sum of all five dimensions (max 50)

How This Works in Practice

Every quarterly planning cycle, we score every candidate initiative. The product backlog and the tech debt backlog all get evaluated together.

Real examples from our last planning:

Initiative	Revenue	Risk	Velocity	CX	Effort	Total
Enterprise SSO	9	6	3	7	6	31
Auth Refactor	6	8	9	5	5	33
Mobile App	7	6	7	8	3	31
Analytics Dashboard	8	4	2	9	7	30
Payment Service Mod	5	10	9	4	4	32

In this case, auth refactor wins. Not because it’s tech debt. Not because engineers are loud. Because the math says it delivers the most business value when you consider all dimensions.

The key insight: Tech debt scored high on velocity multiplier (9) and risk reduction (8), which offset its lower direct revenue impact. Features with clear revenue (SSO: 9) scored lower on velocity and risk.

The Finance Team Loves This

Here’s why our CFO approved this framework:

1. It’s Objective
Not “engineering wants refactoring time.” It’s “here are the five business criteria we all agreed on, here’s how everything scores, highest score wins.”

2. Same Rules for Everything
Features don’t get special treatment. Tech debt doesn’t get charity. Both get evaluated on business impact.

3. It Forces Hard Choices
You can’t just say “this feature will make money.” You have to defend why it’s worth doing compared to everything else, including tech debt that might have higher total impact.

4. It’s Transparent
Every exec can see the scoring and understand why decisions were made. No black-box engineering prioritization.

The 20% Reserve Rule Still Applies

Even with unified scoring, we maintain one additional policy: Reserve 15-20% of capacity specifically for tech debt, regardless of scoring.

Why? Two reasons:

1. Tech Debt Compounds
If features dominate the priority queue for 3 quarters straight, you build up debt that will crush you in quarter 4. The reserve prevents this.

2. Preventive Maintenance
Some tech debt work is like changing your car’s oil. Low drama, low visibility, but skip it long enough and your engine seizes. The reserve ensures this work happens.

So the actual process is:

1. Reserve 20% capacity for tech debt
2. Within that 20%, prioritize using BIS scoring
3. For the remaining 80%, prioritize using BIS scoring (features and tech debt compete)

This means tech debt can win more than 20% if it scores high enough. But it’s guaranteed at least 20%.

Calibration Is Critical

The framework only works if everyone agrees on the scoring criteria. We spend time in quarterly planning calibrating:

• What does a “9” in revenue impact mean? ($500K+? $1M+?)
• What does a “10” in risk reduction mean? (Prevents audit failure? Prevents data breach?)
• How do we score velocity multiplier objectively? (2x faster? 5x faster?)

We also retrospect on previous quarters:

• “We scored that feature as 8 in revenue impact, but it only delivered $200K. Our scoring was off.”
• “We scored auth refactor as 9 in velocity multiplier, and we’ve actually seen 4x faster auth features since. Score was accurate.”

This calibration makes the scoring better over time.

Handling Executive Pressure

Inevitably, an exec will say: “I don’t care about the scoring, we MUST ship this feature for Customer X.”

Our response: “Okay, let’s score it. If it really is that critical, it’ll score high enough to win. If not, let’s be honest about the trade-off we’re making.”

Sometimes they’re right—it’s genuinely critical and scores 45/50. Ship it.

Sometimes they realize it’s not actually that urgent when forced to compare it to everything else objectively. The framework provides cover for hard conversations.

Question for the Community

This framework has worked well for us, but I’m curious:

1. What other prioritization approaches have you seen work?

2. How do you handle the “urgent but low-value” requests that executives push?

3. What’s the right percentage to reserve for tech debt? We do 15-20%, but I’ve heard arguments for both higher and lower.

4. How do you score initiatives where the benefit is uncertain? Some features are experiments. Some tech debt impact is hard to predict. How do you handle the uncertainty in scoring?

Would love to hear what’s worked (or spectacularly failed) for others.

[vp_eng_keisha]

Luis, I love this framework. We do something similar at my company, and I want to add one dimension that’s been critical for us:

Adding an Organizational Health Dimension

We added a sixth scoring dimension: Team Sustainability (0-10)

This captures:

• Engineer morale and retention risk
• Learning and growth opportunities
• Preventing burnout from maintenance burden

Why it matters: Losing a senior engineer costs $200K+ in recruiting, lost productivity, and knowledge transfer. If tech debt is grinding your team down and causing attrition, that’s a real cost.

Example scoring:

• Refactoring the codebase area that causes most on-call pages: Score 9 (massive morale boost)
• Building another enterprise feature in legacy system: Score 3 (team is exhausted)

This gave us language to push back when execs wanted to pile more features onto a team drowning in tech debt. “This team has shipped 6 quarters straight with no tech debt time. Team sustainability score is 2. We’re at high attrition risk. We need to invest in their codebase health.”

The Calibration Session Is Key

Luis’s point about calibration is so important. We do a half-day session at the start of each quarter where product, engineering, and exec team leaders align on scoring criteria.

We look at examples:

• “Feature X generated $800K last year. That’s a 9 in revenue impact. Feature Y is similar scope, so it’s also a 9.”
• “Tech debt Z reduced our incident rate 70%. That’s a 9 in customer satisfaction. Use that as your benchmark.”

This eliminates the “I think this is important” subjective debates. We have shared anchors.

One Refinement: Confidence Intervals

We add confidence scores to uncertain initiatives:

• Enterprise SSO: $500K revenue (80% confidence) → Adjusted score: 9 × 0.8 = 7.2
• Experimental feature: $300K revenue (30% confidence) → Adjusted score: 6 × 0.3 = 1.8

This handles Luis’s question about uncertain benefits. Experiments score lower because the outcome is uncertain. Proven patterns score higher.

Great framework, Luis. Using unified scoring across all work types is the only way I’ve seen this actually work at scale.

[product_david]

As a product leader, I have to say: I was skeptical of this framework when our CTO first proposed it. But it’s actually made my life easier.

Why Product Teams Should Love This Framework

Before unified scoring: Every planning cycle was a battle. Engineering wanted tech debt time, I wanted feature velocity, execs wanted their pet projects. Loudest voice or highest rank won.

After unified scoring: We have objective criteria. If I want a feature prioritized, I need to show it scores high on the dimensions we all agreed matter. Same for engineering with tech debt.

This eliminated 80% of the prioritization arguments.

The Best Part: It Forces Better Product Thinking

The framework made me a better product leader because I can’t just say “customers want this feature.”

I have to answer:

• What’s the revenue impact? (Need to quantify pipeline)
• What’s the velocity multiplier? (Does this unlock future opportunities?)
• What’s the customer satisfaction impact? (Need real user research)
• What’s the effort? (Need accurate engineering estimates)

This discipline has improved our product strategy. We’re more rigorous about validating assumptions before committing to build.

Handling the “Exec Pet Project” Problem

Luis asked how to handle executive pressure for low-scoring initiatives.

Here’s what works for us: We make the scoring visible to the entire leadership team.

Every initiative in our quarterly plan includes:

• The score breakdown (Revenue: 7, Risk: 4, Velocity: 8, etc.)
• The rationale for each score
• The trade-offs (“Choosing X means deferring Y and Z”)

When an exec says “we MUST do this,” we show them:

• Here’s how it scores (total: 24)
• Here are the initiatives it would displace (scores: 31, 29, 28)
• Are you saying this 24-scoring item is more important than the 31-scoring item?

Usually they back down. Sometimes they say “yes, I understand the trade-off and I’m making a strategic call.” That’s fine—that’s their job. But they own the trade-off explicitly.

The 20% Reserve: My Perspective

I used to fight the 20% tech debt reserve. “That’s 20% of capacity we could use for features!”

But I’ve learned: Tech debt reserve is actually a product investment.

Here’s why: When we pay down tech debt consistently, feature velocity INCREASES. Our team ships more story points per sprint in clean codebases than in legacy areas.

Math:

• Team A (clean codebase): 12 story points/sprint
• Team B (high tech debt): 7 story points/sprint

If I invest 20% of Team B’s time in tech debt for 2 quarters and they get to Team A velocity, I haven’t lost 20%—I’ve gained 71% ongoing productivity (from 7 to 12 points).

The 20% isn’t lost capacity. It’s velocity investment.

Once I understood that, I stopped fighting the reserve and started asking “which tech debt will give us the biggest velocity unlock?”

One Addition: Customer-Facing vs Internal Impact

We add a modifier to the scoring: Is this customer-facing or internal?

Customer-facing work (features or tech debt that users see) gets a 1.1x multiplier. Internal work gets 1.0x.

Why? Because in a competitive market, customer-facing improvements drive revenue and retention more directly.

Example:

• Internal API refactor: Base score 30 → Final score 30 × 1.0 = 30
• Customer-facing notification improvements: Base score 28 → Final score 28 × 1.1 = 30.8

This helps break ties and ensures we’re not over-indexing on internal engineering improvements at the expense of user experience.

Bottom Line

This framework works because it treats product and engineering as partners in maximizing business value, not adversaries fighting for budget.

Both sides have to defend their work using the same criteria. May the best score win.