The short answer
When a product leader demands a complete moratorium on technical debt remediation and infrastructure maintenance, they are fundamentally misunderstanding the physics of software engineering. They are treating infrastructure maintenance as an optional luxury rather than the physical foundation that allows commercial features to exist. You cannot agree to this mandate.
As the Vice President of Engineering, your primary fiduciary duty is to protect the stability, security, and scalability of the platform. The VP of Product is optimizing entirely for short-term visual progress to appease sales or investors. If you capitulate and allocate one hundred percent of your capacity to feature development for six months, you guarantee a catastrophic production outage, massive data latency, and a complete collapse of deployment velocity.
You must reject the premise that maintenance is opposed to revenue. You must reframe infrastructure work as the literal enforcement of your commercial Service Level Agreements (SLAs). You must force the product leader to accept that cutting maintenance requires them to formally authorize degraded system performance and potential contractual breaches with your largest enterprise clients.
Why this question is a trap
The trap is the seduction of the "revenue-generating" label. The VP of Product is using aggressive commercial language to paint your engineering department as an academic, slow-moving cost center that cares more about clean code than company survival. They are trying to force you into a defensive posture where you have to justify why you are "wasting" time on invisible backend work.
If you simply say no, you validate their narrative. You look like a stubborn technologist who refuses to align with the company's urgent commercial goals. They will escalate to the CEO, claiming that engineering is holding the roadmap hostage for the sake of unnecessary refactoring.
Conversely, if you agree to the moratorium, you assume all the liability for the inevitable disaster. When the database locks up during peak traffic, or when the deployment pipeline breaks and halts a critical launch, the VP of Product will not take the blame. They will point at you and say you failed to keep the system running. You cannot allow a commercial leader to dictate the structural integrity of your architecture while leaving you with the operational risk.
What most people say
Most engineering leaders react with intense frustration and technical lecturing. They say something like, "You clearly don't understand how software works. If we don't clean up our technical debt and optimize these database queries, the whole system is going to crash. We have to dedicate at least twenty percent of our time to maintenance."
This response is a failure of executive communication. It sounds patronizing, defensive, and completely disconnected from the business reality. Telling a product leader that "the system will crash" sounds like a vague, unquantifiable threat rather than a concrete business risk. It sparks an endless debate about what percentage of time is "appropriate" rather than addressing the core commercial trade-off. It proves you are speaking a different language than the rest of the executive team.
What to say instead
"I am fully aligned on accelerating the commercial roadmap, but freezing database maintenance guarantees we will breach our enterprise SLA uptime commitments within ninety days. If you mandate one hundred percent feature capacity, I need you to formally sign off on accepting a twenty-percent degradation in checkout latency and the financial penalties of those SLA breaches."
This script translates technical reality into pure commercial risk. You start by validating their goal: you are aligned on accelerating the commercial roadmap. You establish that you are on the same team and that you care about revenue.
Then, you deploy the ultimate executive weapon: contractual liability. You do not talk about clean code, technical debt, or refactoring. You talk about breaching enterprise SLAs within a specific timeframe (ninety days). You tie the invisible infrastructure work directly to the legal commitments the company has made to its buyers.
Finally, you force the trade-off. You agree to their mandate, but only if they formally sign off on the exact consequences: degraded latency and financial penalties. You remove yourself as the blocker and transform the issue into a business decision they must own. A product leader will never sign a document accepting SLA penalties, which instantly ends the debate and restores your maintenance budget.
The phrase to anchor on
Formally sign off on the financial penalties of those SLA breaches.
How to deliver it
Deliver this response with absolute calm and analytical precision. Do not raise your voice, and do not show any signs of technical exasperation. You must sound like a Chief Financial Officer explaining a balance sheet, not an engineer complaining about messy code.
Maintain steady eye contact. When you say the words "financial penalties," pause for a brief second to let the reality of that risk hit them. Your tone should imply that you are perfectly willing to execute their plan, provided they are willing to take the legal and financial responsibility for the inevitable consequences. You are passing the risk back across the table.
Mistakes that cost you the room
The most fatal mistake is getting dragged into a debate about specific technical tasks. If you start explaining why a specific microservice needs a new caching layer, you have lost the room. Product leaders do not care about caching layers; they care about user experience and revenue. Never debate architecture with someone who only cares about outcomes.
Another error is hiding maintenance work secretly. If you agree to zero maintenance but secretly tell your engineers to "sneak in" refactoring during feature work, you destroy your own velocity metrics and create a culture of deceit. You must defend the capacity allocation openly and aggressively.
Finally, do not make empty threats about engineers quitting. While it is true that engineers hate working in a decaying codebase, telling the VP of Product that "the team will revolt" sounds like you are weaponizing morale to win an argument. Anchor entirely on system performance and commercial contracts.
Practice plan
First, audit your current enterprise contracts. You must know exactly what your uptime SLAs are and what the financial penalties are for breaching them. You need this data as ammunition.
Second, practice translating your top three technical debt items into direct commercial risks. If you don't refactor X, what happens to feature Y?
Finally, run the drill in the Talk Rightly studio. Focus heavily on maintaining a collaborative but unyielding posture. You must sound like a trusted advisor warning them of a cliff, not a roadblock preventing them from walking.