The short answer
When the Vice President of Product attacks your team for slow ticket response times, you are facing a massive deflection of accountability. The product organization ships broken code, customers flood the support queue with complaints, and the product leader blames your team for not handling the incoming volume fast enough. You cannot accept this premise. If you apologize and promise that your team will work harder to answer tickets faster, you validate their false narrative. You effectively agree that the problem is a lack of support efficiency rather than a catastrophic failure in product quality.
As a Technical Support Manager, your mandate is to protect the sanity of your support engineers and maintain the baseline quality of troubleshooting. Forcing your team to rush through technical tickets to meet an artificial first-response metric will only create worse problems. Customers will receive copy-pasted, useless replies. The tickets will immediately reopen, driving the total backlog even higher and tanking your customer satisfaction scores. You must refuse to manage to a vanity metric and force the product leader to confront the physical reality of the queue.
Your objective is to redirect the accountability back to the source of the fire. You must tie the doubled ticket volume directly to the specific buggy product releases that caused the spike. You will demand that the product organization either dedicate immediate engineering capacity to fix the underlying bugs or fund temporary support headcount to absorb the impact of their flawed code. You must transform a defensive conversation about support speed into an offensive conversation about product stability.
Why this question is a trap
The trap is the isolation of the first-response metric. The Vice President of Product is weaponizing a single, highly visible data point to put you on the defensive. By asking why your team is not answering tickets faster, they establish the premise that the support team is the bottleneck. They want you to feel embarrassed about the metrics and pledge to squeeze more productivity out of your existing staff.
If you agree to push your team harder, you fall into an endless cycle of burnout. Your support engineers are already saturated dealing with angry customers who are experiencing real product failures. Demanding that they move faster without addressing the root cause will destroy team morale. Your best technical problem solvers will quit, leaving you with inexperienced staff who will struggle even more to close the complex engineering escalations. You lose your best people to protect a product leader's ego.
This dynamic also teaches the product organization that they can ship untested features without consequences. If the support team silently absorbs the pain of every buggy release, the product team feels no operational friction. They will continue to prioritize shipping new features over fixing technical debt. You must create structural friction. You must make the product leader feel the pain of their own poor quality control by refusing to absorb it silently.
What most people say
Most support managers panic when confronted by senior leadership about declining metrics. They try to sound accommodating and proactive. They say something like, "We have definitely seen the spike in volume this month. I know the response times look bad right now. I will have the team work some overtime this weekend to clear out the backlog, and we will try to get our first-response times back under the twenty-four-hour target."
This response is a complete failure of managerial defense. By agreeing that the metrics look bad and offering overtime, you accept total blame for a problem you did not cause. You volunteer your team to suffer the consequences of bad code. You fail to connect the volume spike to the recent product release, allowing the product leader to walk away thinking their release was a success while you manage the fallout. You look like a weak administrator rather than a strategic operational leader.
What to say instead
"First-response times doubled because incoming ticket volume tripled following last week's buggy analytics release. My team is maintaining our median resolution SLA, but we refuse to send automated junk replies just to hit a first-response target. We need the product team to either dedicate two sprint cycles to resolving these core bugs or fund three temporary support contractors to handle the artificial volume spike."
This script is a masterclass in operational accountability. You begin by immediately correcting the premise of the attack. You explain that response times doubled because volume tripled. You tie the tripling of volume directly to the specific analytics release. You do not leave room for debate about the cause of the backlog. You place the blame squarely on the product organization where it belongs.
You then defend your team's actual performance. By highlighting that you are maintaining the median resolution SLA, you prove that your team is still effectively solving problems once they get to the tickets. You explicitly state that you refuse to send automated junk replies. This demonstrates that you prioritize true customer resolution over vanity metrics. You are managing the business correctly.
Finally, you deliver the ultimatum. You give the product leader two options to fix the crisis they created. They must either pause feature development and dedicate sprint cycles to fixing the bugs, or they must open their budget to fund temporary support contractors. You force them to choose between their engineering roadmap and their departmental budget. You solve the problem by pushing the cost back onto the department that generated the failure.
The phrase to anchor on
My team is maintaining our median resolution SLA.
How to deliver it
Deliver this response with crisp, unemotional precision. You are reporting data from the front lines of the business. Do not sound angry, vindictive, or overwhelmed. You are an operational leader holding a mirror up to the product organization. Your tone must project absolute confidence in your analysis.
Maintain direct eye contact with the Vice President of Product. When you name the specific buggy release, speak clearly and distinctly. Let the reality of their failure land in the room. When you deliver the options regarding sprint cycles or contractor funding, lower your vocal pitch slightly to indicate that these are the only two paths forward. Do not end your sentences with an upward inflection. You are stating business requirements, not asking for favors.
Mistakes that cost you the room
The most damaging mistake is failing to have the exact ticket categorization data ready. If you claim the volume spike is due to the analytics release, the product leader will immediately ask for proof. If you cannot instantly pull up a dashboard showing a massive increase in tickets tagged with the new feature, your argument collapses. You will look like you are making excuses. You must have the data organized before you have the conversation.
Another error is threatening to stop answering tickets entirely. Do not say that your team is going to drop the ball or that customers are going to start churning. You must maintain the posture that your team is executing flawlessly under impossible conditions. You are the professional adult in the room managing a crisis created by someone else.
Do not accept a vague promise that the product team will look into it. If the Vice President says they will ask engineering to review the bugs eventually, you must reject that timeline. You need immediate relief for your queue. Force a hard commitment on sprint allocation or budget transfer before leaving the meeting.
Practice plan
First, build a real-time dashboard that tracks ticket volume strictly by product feature tag. You must train yourself to view your support queue as a diagnostic tool for product quality, not just a list of chores. You need this data available at all times.
Second, practice the pivot from defending the metrics to presenting the binary choice. The transition from refusing to send junk replies to demanding engineering capacity must be seamless and commanding. Record yourself delivering this transition until it sounds natural.
Finally, run the drill in the Talk Rightly studio. Focus on eliminating any defensive posturing. You are not apologizing for being slow. You are diagnosing a systemic failure and dictating the required executive intervention.