The first ten seconds set the price of the whole incident
Everyone in the room can see the screen. The failure is not a secret you might get away with,
so the only variable is whether they watch you handle it well or watch you pretend. Say what
has happened, in plain words, within a couple of seconds: name it, say what you are going to
do about it, and keep talking. Silence with a spinning screen is what does the damage,
because for fifteen seconds the room's attention moves from your product to your composure
and finds nothing there.
Two reflexes to suppress. The first is clicking repeatedly and quietly in the hope it comes
back, which reads as panic and usually makes the state worse. The second is blaming the
network or the VPN before you know, because if it later turns out to be a product defect you
have converted a technical problem into a credibility problem, and the technical evaluator in
the room — who has watched vendors do this for years — will already have noticed.
Work out which of three failures it is, quickly
The response differs by cause, and you usually have enough information within seconds.
A demo environment or connectivity problem is the most common and the least serious: a
sandbox someone reset overnight, an expired token, a slow tunnel. It is genuinely not about
the product, and you may say so — once you are sure — as long as you say it without relief in
your voice.
Your own driving error is the second, and it is the easiest to recover if you own it
immediately and without theatre. "That is me, I have filtered the view — one second." A
candidate who admits this crisply scores better than one who pretends the product behaved
oddly, and interviewers watch for exactly that substitution.
A genuine product defect is the third, and it is the only one with lasting consequences. If a
feature you claimed works does not, that is now the most important thing you learned in the
meeting, and it must be reported inside your own organisation and to the customer in writing.
Do not decide live that it is an environment issue because that is the comfortable
explanation.
Roughly what you say
The specific wording matters more here than in most parts of the job, because the room is
reading tone as much as content.
Weak: [silence, refreshing] "...it's usually much faster than this."
Weak: "That will be your network, it works fine in our environment."
Better: "That has not loaded and it should have. Give me one attempt at it -
I am checking whether our sandbox has dropped its session, which
happened to us on Tuesday. If it has not come back in thirty seconds
I will show you the same flow from a recording and we will come back
to it live."
If it is a real defect:
"I am going to stop guessing. That is not behaving the way I told you
it would, and I would rather find out why than talk over it. I will
have an answer to you today, including whether it is a defect or a
limitation, and I will be straight with you either way."
That last construction is the one senior candidates use, and it works because it commits to
an answer and to honesty about the outcome without promising a fix nobody can promise yet.
One narrated attempt, then route around
Give yourself a single attempt of thirty to sixty seconds, narrated so the room can follow
what you are doing, and then stop. Beyond about a minute you are debugging in front of an
audience, and the meeting quietly becomes about your infrastructure instead of their problem.
Then route around it and protect the purpose of the meeting, which was never "see feature
seven work". Move to the next part of the flow, use the recorded fallback you prepared, or
step off the screen entirely and talk through the outcome on a whiteboard with the customer's
own numbers. A demo that loses one component but reaches its point still advances the deal.
A demo that spends twenty-five minutes on a broken screen has cost you the slot and the
narrative.
Whatever you skip, say you are skipping it and that you will come back to it. Quietly
avoiding the feature that failed is noticed by exactly the person you most need to convince.
Afterwards, the same day
Write to them before the day ends, and keep it short and specific: what failed, what you have
established about why, whether it is a defect or a limitation, what you are doing, and a named
date for the re-demo. The email is doing something a verbal reassurance cannot, which is
giving your champion a document they can forward to the sceptic who was in the room and will
raise it in an internal meeting you are not attending.
Then use the specificity as an advantage. "The report timed out because our demo tenant was
rebuilt on Tuesday with a fraction of the data volume; here is the same report against a
full-size dataset, recorded this afternoon, and here is a sandbox login if you would rather
run it yourself" converts a failure into evidence. Recovery handled well is more persuasive
than a demo that never broke, because the customer now has a data point about how you behave
when something goes wrong — which is the thing they are genuinely trying to predict, given
they are about to depend on you for three years.
If it was a real gap, say so and do not soften it into a roadmap implication. Report it
internally with the account attached, get a factual answer on whether and when it will be
fixed, and pass on only what your product organisation will stand behind in writing. A dated
commitment you invented to save a meeting becomes a contractual expectation, and it will be
quoted back to you by someone holding a purchase order.
Then fix the cause on your own side
The internal half is what separates someone who recovered from someone who will recover
again. Demo environments break because they are shared, unowned and rebuilt by whoever needs
them. That is an operational problem with operational answers: a checked pre-flight, a
recorded fallback for every flow you claim, data volumes that resemble production, and an
environment that is not being reset by another team an hour before a customer call.
- Run the exact flow end to end within an hour of the call, on the same network you will use.
- Keep a recording of every flow you might show, current enough to be honest.
- Know which two features are fragile, and have a decision made in advance about whether you
will show them at all.
- Have a second path to the same story: a whiteboard version you can deliver with no software
at all.
The reputational arithmetic people get wrong
Candidates assume the demo failure is the damaging event. It usually is not. Customers know
software breaks, and most evaluators have themselves demonstrated something to their own
board and had it fail. What they remember is the explanation — specifically whether it turned
out to be true. A vendor who blamed the network and was later found to have hit a real
product limit has taught the customer to discount everything else they said, and that
discount applies to the estimate, the architecture and the reference calls.
So the reason to be honest in the moment is not principle, it is arithmetic: the cost of a
broken feature is bounded and usually small, while the cost of a discovered untruth is applied
to your entire proposal. That is the calculation an interviewer is checking you have made,
and it is why "I would tell them straight away and follow up in writing the same day" is a
stronger answer than any recovery trick.
© 2026 Preptima. Originally published at preptima.com (opens in a new tab).