Bring three things: evidence of a specific risk, a bounded request with an end date, and a named trade-off. Skip vague phrases like "tech debt". Say what breaks or becomes unsupported, when, and what you will stop doing to make room. A clear, limited ask gets a yes far more often than an open-ended one.
Why vague asks fail
"We need time to pay down tech debt" gives a product manager nothing to weigh. It has no date, no customer impact, and no end. They cannot compare it with a feature that has all three.
Translate the work into the terms product already uses: customer risk, delivery speed, and commitments made to buyers.
The three-part ask
1. The risk, in one sentence with a date. Example shape: "The runtime our payments service runs on stops receiving security fixes in the first quarter of next year, according to its published support policy." Use the project's own dates, and confirm them first.
2. The request, bounded. "Two engineers for three weeks, starting week four, finishing before the pre-holiday freeze." A start, a finish and a headcount.
3. The trade-off, named. "This pushes the reporting export to the following sprint." Naming the cost shows you have thought about their side.
A script you can adapt
"I want to ask for a bounded block of upgrade work. Here is the risk, here is the exact scope, and here is what moves if we do it. If we do nothing, this is the date we lose security support. If we do it now, it takes this long. If we wait until it is urgent, it will cost more and arrive without warning."
Practice it out loud. The goal is five sentences, not a deck.
Evidence worth bringing
| Evidence | Why product cares |
|---|---|
| End-of-support date from the vendor or project | A hard date, not an opinion |
| Customer or auditor questions that mention it | Links the work to revenue and renewals |
| Past incident or slip caused by old versions | Shows the cost is real, not theoretical |
| Your own estimate based on past upgrades | Shows the ask is grounded |
Security questionnaires are a good source. Buyers often ask how quickly you patch, and an old runtime makes an honest answer awkward. Our post on answering a patching timeline question shows how that conversation goes.
Offer options, not an ultimatum
Present two or three scoped options:
- Minimum: upgrade only what has an end-of-support date in the next two quarters.
- Standard: the minimum plus reachable advisories.
- Catch-up: a larger one-off push, then a smaller standing slice.
Let product choose among options you can live with. People defend a choice they made.
Keep the promise
After the work, report back in the same terms: the date risk removed, the hours spent against the estimate, and what shipped late. That record makes next quarter's ask easier. It also mirrors the idea in our guide on security versus feature myths for engineering managers.
Where Safeguard fits
Safeguard's SBOM and dependency scanning can produce the inventory and advisory evidence you bring into this conversation, and reachability analysis helps you show which findings affect code you call. A free scan is at gold.safeguard.sh/scan.
Quick check
Should I mention CVE counts?
Lead with reachable, dated risks. Raw counts are easy to dismiss and often include findings that do not affect you.
What if product still says no?
Write down the decision, the risk accepted and the date to revisit. A recorded decision is better than a silent one.
Last reviewed: 19 October 2026.
