The Technical Debt Prioritization Matrix
Why this prompt matters
High-debt organizations spend 40% more on maintenance and ship features 25-50% slower than peers, and technical debt costs US companies over $2.4 trillion annually — the cost of not prioritizing isn't just slower engineering, it's a compounding tax on every future feature the team ships.
What we use it for
Your team has a scattered list of known technical debt items sitting in a backlog nobody has prioritized, and you need a defensible remediation plan before the next quarterly planning meeting with product and finance stakeholders.
Prompt
Act as an engineering leader who needs to defend a technical debt remediation roadmap to a CFO and a VP of Product in the same meeting. CONTEXT: - Our team's available capacity for debt remediation next quarter: [E.G. "1 engineer, 20% time" OR "2 sprints total"] - Current business priority: [GROWTH / STABILITY / COST-CUTTING] - Raw list of known technical debt items: [PASTE YOUR LIST — one item per line, however informal] TASK: For each debt item, score it 1-5 on each of these four dimensions: 1. Delivery drag — how much does this slow down future feature work in the affected area? 2. Incident risk — how often is this implicated in production issues, outages, or urgent fixes? 3. Revenue/customer exposure — does this affect paying customers, SLAs, or revenue-generating flows directly? 4. Remediation cost — how much effort would fixing this actually take (5 = very cheap, 1 = very expensive)? Then compute a priority score and rank all items. CONSTRAINTS: - Do not recommend more remediation work than the stated capacity allows — sequence items into what actually fits. - Do not treat all debt as equally urgent — explicitly deprioritize items that score low on both delivery drag and incident risk, even if they're technically embarrassing. - Justify the top 3 items in plain English a non-engineer could read and approve without a glossary. OUTPUT FORMAT: 1. Scored Table: Item | Delivery Drag | Incident Risk | Revenue Exposure | Remediation Cost | Priority Score 2. Recommended Sequence: which items fit in the stated capacity, in order 3. Plain-English Justification: 1 paragraph per top-3 item, written for a non-technical stakeholder
Result
Scored Table:
| Item | Delivery Drag | Incident Risk | Revenue Exposure | Remediation Cost | Priority Score |
|---|---|---|---|---|---|
| Auth tokens don't expire | 2 | 5 | 5 | 4 | 16 |
| No test coverage on checkout service | 4 | 4 | 5 | 2 | 15 |
| Deploy script has 3 manual steps | 3 | 3 | 2 | 5 | 13 |
| Reporting dashboard queries primary DB directly | 2 | 2 | 1 | 3 | 8 |
Recommended Sequence (fits 20% time / 1 engineer for the quarter):
- Fix auth token expiration first — highest incident risk and direct revenue/compliance exposure, and at remediation cost 4 it's genuinely cheap to fix. This alone likely consumes 2-3 weeks of the available capacity.
- Add test coverage to checkout service next — this is the most expensive item on the list (cost 2), so it should be scoped to the highest-risk checkout paths only this quarter, not full coverage. Partial coverage of the payment and cart-abandonment flows is achievable in the remaining capacity.
- Deploy script and dashboard query issues are explicitly deferred to next quarter — both score below the auth and checkout items, and capacity is fully allocated after the above two.
Plain-English Justification:
Auth tokens don't expire: Right now, if someone's login session is ever compromised, whoever has that token can access their account indefinitely — there's no automatic cutoff. This is both a security exposure and, depending on our contracts, could put us in breach of customer data-handling commitments. It's also a relatively fast fix, which is why it's first.
No test coverage on checkout: Every time we change anything near checkout, we're relying on manual QA and hope to catch payment bugs before customers do. Given checkout is where we make money, a bug slipping through here has a direct and immediate revenue impact — but building full test coverage is a genuinely large effort, so we're scoping this to the highest-traffic paths first rather than promising full coverage this quarter.
Deploy script manual steps: This one is annoying and occasionally causes a bad deploy, but it doesn't touch customers directly or put revenue at risk the way the other two do — it's a real problem, just not this quarter's problem given our capacity.
Technical debt backlogs usually die in one of two ways: either every item gets flagged as "critical" by the engineer who's most annoyed by it, or the list gets ignored entirely because nobody can translate "this module has no test coverage" into something a product manager or CFO will fund. This prompt forces a business-impact scoring pass before any remediation sequencing happens, so the resulting plan survives a roadmap conversation with non-engineers in the room.
Why each section of the prompt exists
Role: The prompt assigns the AI the perspective of an engineering leader who has to defend a remediation roadmap to a CFO and a VP of Product in the same meeting — not just a senior engineer reviewing code quality. That framing matters because a purely technical reviewer will rank items by elegance and correctness; a leader accountable for both budget and delivery ranks them by what actually breaks the business.
Context: The prompt asks for your team's current sprint capacity and the business's current priorities (growth, stability, cost-cutting) because the same debt item ranks differently depending on what the org is optimizing for right now. A scaling startup and a company in a stability quarter should not get the same prioritization output from the same debt list.
Task: Each debt item gets scored on four dimensions — delivery drag (how much it slows future feature work), incident risk (how often it's implicated in production issues), revenue/customer exposure, and remediation cost — rather than one vague "severity" rating, because a single score collapses distinct tradeoffs into a number nobody can argue with or against.
Constraints: The prompt explicitly bans "just refactor everything" as an output and requires the plan to respect the stated sprint capacity, because a prioritization exercise that recommends more work than the team can absorb isn't a plan, it's a wish list.
Output Format: The output is a ranked table (not prose) specifically so it can be dropped into a roadmap review deck without additional formatting work, followed by a one-paragraph plain-English justification for the top 3 items that a non-technical stakeholder can actually read and approve.
The prompt
Act as an engineering leader who needs to defend a technical debt remediation roadmap to a CFO and a VP of Product in the same meeting.
CONTEXT:
- Our team's available capacity for debt remediation next quarter: [E.G. "1 engineer, 20% time" OR "2 sprints total"]
- Current business priority: [GROWTH / STABILITY / COST-CUTTING]
- Raw list of known technical debt items: [PASTE YOUR LIST — one item per line, however informal]
TASK:
For each debt item, score it 1-5 on each of these four dimensions:
1. Delivery drag — how much does this slow down future feature work in the affected area?
2. Incident risk — how often is this implicated in production issues, outages, or urgent fixes?
3. Revenue/customer exposure — does this affect paying customers, SLAs, or revenue-generating flows directly?
4. Remediation cost — how much effort would fixing this actually take (5 = very cheap, 1 = very expensive)?
Then compute a priority score and rank all items.
CONSTRAINTS:
- Do not recommend more remediation work than the stated capacity allows — sequence items into what actually fits.
- Do not treat all debt as equally urgent — explicitly deprioritize items that score low on both delivery drag and incident risk, even if they're technically embarrassing.
- Justify the top 3 items in plain English a non-engineer could read and approve without a glossary.
OUTPUT FORMAT:
1. Scored Table: Item | Delivery Drag | Incident Risk | Revenue Exposure | Remediation Cost | Priority Score
2. Recommended Sequence: which items fit in the stated capacity, in order
3. Plain-English Justification: 1 paragraph per top-3 item, written for a non-technical stakeholderWhat the output actually looks like
For a team with "1 engineer, 20% time" capacity in a GROWTH quarter, given a raw list including "no test coverage on the checkout service," "auth tokens don't expire," "the reporting dashboard queries the primary database directly," and "our deploy script has three manual steps someone always forgets," a typical output would read:
Actionable takeaways
- Run this before your next planning cycle, not during it — the scoring conversation surfaces disagreements about business priority that are better resolved before capacity gets allocated, not during a heated roadmap meeting.
- Use the plain-English justifications verbatim when asking for budget or headcount — they're specifically built to survive a non-technical audience without requiring you to translate on the fly.
- Re-run the prompt whenever your stated business priority changes (growth to stability, for instance) — the same debt list should produce a meaningfully different sequence, and if it doesn't, the scoring inputs need re-examining.
- Don't skip the explicit deprioritization step — a debt list where everything is "important" is the single most common reason remediation roadmaps never survive contact with a real sprint.