Build a technical debt negotiation case for your engineering team

Description

Engineering keeps asking for 'tech debt sprints' but can't explain the business impact, and leadership keeps saying 'not now.' This builds a data-driven case that translates technical debt into business language — shipping velocity, incident risk, and opportunity cost — so both sides can agree on a realistic paydown plan.

Build a compelling business case for addressing technical debt in {{product_name}} that both engineering and business leadership will support.

## Context
- Product: {{product_name}}
- Engineering team size: {{team_size}}
- Current sprint velocity trend: {{velocity_trend}} (stable, declining, volatile)
- Top technical debt items identified by engineering: {{debt_items}}
- Recent incidents or slowdowns caused by tech debt: {{recent_incidents}}
- Upcoming product priorities: {{upcoming_priorities}}

## Step 1: Quantify the Cost of Inaction
For each major tech debt item:
1. How much engineering time is spent working around this issue per sprint? (hours/sprint)
2. How many incidents or bugs has it caused in the last 6 months?
3. What features are blocked or slowed by this debt?
4. What's the risk of a major failure if this isn't addressed? (probability × impact)

Calculate the "tax rate": what percentage of each sprint is consumed by debt-related work vs. new feature development?

## Step 2: Translate to Business Impact
1. Velocity tax: "We're shipping at X% of our potential velocity because of these 3 debt items"
2. Incident risk: "There's a Y% chance of a Z-severity outage in the next quarter if we don't address [item]"
3. Opportunity cost: "Addressing [item] would unblock [feature], which has an estimated impact of [metric]"
4. Hiring impact: "Tech debt is increasing ramp time for new engineers by N weeks"

## Step 3: Propose the Plan
1. Prioritize debt items by: business impact, effort to fix, and risk of deferral
2. Propose an allocation model: X% of sprint capacity dedicated to debt paydown
3. Create a 3-sprint roadmap showing which items get addressed when
4. Define measurable outcomes for each item (e.g., "deploy frequency increases from weekly to daily")
5. Identify any debt items that can be addressed incrementally alongside feature work

## Step 4: Frame the Ask
- Write a one-page executive summary: the problem, the cost, the plan, the expected ROI
- Prepare answers to likely objections: "Can't we do this later?", "How do we know it will help?", "What features are we delaying?"
- Propose a 30-day pilot: dedicate 20% of one team's capacity to debt paydown and measure the velocity impact

Customize This Prompt