La Matriz de Priorización de technical debt
Por qué importa este prompt
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.
Para qué lo usamos
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
Resultado
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.
Los backlogs de technical debt suelen morir de una de dos maneras: o bien cada elemento es marcado como "crítico" por el ingeniero al que más le molesta, o la lista queda ignorada por completo porque nadie sabe cómo traducir "este módulo no tiene cobertura de tests" en algo que un director de producto o un CFO esté dispuesto a financiar. Este prompt obliga a realizar una valoración del impacto de negocio antes de establecer cualquier secuencia de remediación, de modo que el plan resultante sobreviva a una conversación sobre el roadmap con personas que no son ingenieras.
Por qué existe cada sección del prompt
Rol: El prompt asigna a la AI la perspectiva de un líder de ingeniería que debe defender un roadmap de remediación ante un CFO y un VP de Producto en la misma reunión, no simplemente la de un ingeniero senior revisando la calidad del código. Ese encuadre importa porque un revisor puramente técnico ordena los elementos por elegancia y corrección; un líder responsable tanto del presupuesto como de la entrega los ordena según lo que realmente perjudica al negocio.
Contexto: El prompt solicita la capacidad actual del equipo en el sprint y las prioridades actuales del negocio (crecimiento, estabilidad, reducción de costes), porque el mismo elemento de technical debt recibe una clasificación distinta según lo que la organización esté optimizando en ese momento. Una startup en fase de escala y una empresa en un trimestre de estabilidad no deberían obtener el mismo resultado de priorización a partir de la misma lista de deuda.
Tarea: Cada elemento de technical debt se puntúa en cuatro dimensiones —arrastre en la entrega (cuánto ralentiza el trabajo futuro de funcionalidades), riesgo de incidencias (con qué frecuencia está implicado en problemas en producción), exposición a ingresos o clientes, y coste de remediación— en lugar de una valoración vaga de "severidad", porque una única puntuación colapsa tradeoffs distintos en un número con el que nadie puede discutir a favor ni en contra.
Restricciones: El prompt prohíbe explícitamente "simplemente hacer refactor de todo" como resultado posible y exige que el plan respete la capacidad declarada del sprint, porque un ejercicio de priorización que recomienda más trabajo del que el equipo puede absorber no es un plan, es una lista de deseos.
Formato de salida: El resultado es una tabla ordenada (no texto corrido) precisamente para que pueda insertarse en una presentación de revisión del roadmap sin necesidad de formateo adicional, seguida de una justificación en lenguaje llano de un solo párrafo para los 3 primeros elementos, que un stakeholder no técnico pueda leer y aprobar sin dificultad.
El 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 stakeholderCómo luce el resultado en la práctica
Para un equipo con capacidad de "1 ingeniero al 20% del tiempo" en un trimestre de CRECIMIENTO, dado un listado que incluye "sin cobertura de tests en el servicio de checkout", "los tokens de autenticación no caducan", "el dashboard de informes consulta directamente la base de datos principal" y "nuestro script de despliegue tiene tres pasos manuales que alguien siempre olvida", un resultado típico se leería así:
Conclusiones accionables
- Ejecuta este prompt antes de tu próximo ciclo de planificación, no durante él: la conversación de puntuación hace aflorar desacuerdos sobre las prioridades del negocio que es mejor resolver antes de asignar capacidad, y no en medio de una acalorada reunión de roadmap.
- Usa las justificaciones en lenguaje llano de forma literal cuando solicites presupuesto o recursos humanos: están construidas específicamente para sobrevivir ante una audiencia no técnica sin que tengas que improvisar una traducción sobre la marcha.
- Vuelve a ejecutar el prompt cada vez que cambie la prioridad declarada del negocio (de crecimiento a estabilidad, por ejemplo): la misma lista de technical debt debería producir una secuencia significativamente diferente, y si no lo hace, los datos de puntuación necesitan revisarse.
- No omitas el paso de descartar elementos explícitamente: un backlog de deuda donde todo es "importante" es la razón más habitual por la que los roadmaps de remediación nunca sobreviven al contacto con un sprint real.