Have you ever been faced with a situation where you are showing a product demo and the customer asks that dreaded question?
Follow me through this scenario:
Customer (Operations Lead): What happens when a record fails to sync?
SE: Good question. Let me get back to you on that.
Two sentences, and the customer just asked the most important question in the room. You’ve rehearsed this demo eleven times and never once shown the failure state, so the answer isn’t on your screen. It isn’t in your head either, not in a form you can say in the moment.
They nod. They don’t ask again. But the next slide feels a little less believable than the last one did.
Annotation: What the Customer Heard
Customer: Okay. Keep going.
Read that line the way the customer heard it: polite, with the question left hanging. Their notes now say “vendor avoided the sync question.” They haven’t decided you’re lying. They’ve decided you haven’t been asked the hard question before, or you’d have had a faster answer.
You already know this part. What you may not have noticed is that the customer has now started scanning for seams.
The Seams They’re Watching For
Here’s what the customer is checking while you click through the rest of the demo:
Every error message is conveniently absent. The sample data never has a null field, a duplicate record, or a name with an apostrophe. You always know exactly where to click, and you never hesitate.
Customers who’ve been burned before don’t assume a clean demo is a good product. They assume it’s a curated one. Once they find one unhandled edge case, they stop trusting the rest of what you showed them.
The Fix, in Dialogue
SE (before the demo): I’m going to show you what happens when something goes wrong, because that’s where most of the real work is. I’ll break one sync on purpose.
Customer: Okay, that’s different.
That one sentence changes the room. You’ve told them you’re not hiding anything, and you’ve set the expectation that the failure is part of the product.
SE (during the demo): Here’s a sync failing on a record with a missing billing code. The error shows up here, in the activity log, and the operator gets an alert. Watch what happens next.
The error is visible. The cause is named. The recovery is on screen. The customer’s question has moved from “Are they hiding something?” to “How long does recovery take?”
Customer: How long does recovery usually take?
SE: In your environment, it depends on how many records fail. Let’s look at how the queue handles a batch.
That’s an implementation question. The customer is picturing their own rollout now.
The Three Demo Moments
- The Silent Success. Everything works, but nothing confirms it. Fix: Show the proof. A confirmation, a log entry, a status change.
- The Hidden Failure. The demo routes around an error, so the customer assumes the error doesn’t exist. Fix: Choose one realistic failure and show it on purpose.
- The Unexplained Recovery. The system handles a problem, but the SE moves on before the customer understands what was protected. Fix: Pause on the recovery. Say what the customer would have seen without the safeguard.
Three Bold Contexts, as Transcripts
Context 1: The Flawless SE
Customer: What happens when a record fails?
SE: That doesn’t really come up in normal use.
Customer thinks: “They’re not telling us something.”
Context 2: The Candid SE
Customer: What happens when a record fails?
SE: Let me break one and show you. The error appears here, and the recovery path is this.
Customer thinks: “They’ve actually run this in the real world.”
Context 3: The Chaos SE
Customer: What happens when a record fails?
SE: Well, there are about fourteen failure modes. Let me start with the first one, the timeout case, and then the validation rules…
Customer thinks: “I have no idea what matters here.”
The goal is Context 2. Show the failure with a purpose, then show the way back.
Pattern to Remember
The Flawless Demo Problem: A perfect demo signals that something is being hidden, especially to customers who’ve seen implementations go wrong. When you remove every failure from the demo, you don’t make the product look better. You make your credibility harder to believe.
The fix: Choose one realistic failure before the call. Show it on purpose. Tell the customer what you’re doing and why. The moment you show what breaks is the moment they start believing what works.
Reply Prompt
Hit reply and tell me: What’s the failure you’ve never shown in a demo, and what do you think would happen if you did?
