Helping technical professionals earn trust through clear communication.
Every Friday, one short email for sales engineers, solutions architects, developer advocates, and anyone who explains technology for a living: one lesson in technical communication, one demo worth studying, one practical AI workflow, and one habit that builds trust.
SHARE
TechnicalTrust.org
August 7th
How to Watch a Vendor Demo: Five checks that tell you whether you're seeing the product — or the performance.
↓
The demo was a hit.
Everyone liked it. The screens were clean, the presenter was confident, the workflow you asked about appeared on cue and worked the first time. You walked out of that meeting and told your team, "I think this is the one."
Six months later, you've submitted your fourth support ticket for a workflow that never even came up in the demo. And here's the uncomfortable part: it couldn't have come up. The demo was built so it wouldn't.
You didn't buy the product. You bought the demo.
Last week I wrote about the question the buyer didn't know to ask. This week, flip the chair. Every pattern in this newsletter so far — the Confidence Bluff, the Feature Dump, the Happy Path — has been written for the person giving the demo. This one is for the person watching it.
(And if you're the one giving demos: read it twice. This is the scouting report on you.)
A demo is a performance, and performances are rehearsed. That's not cynicism — it's just what demos are. The vendor chose the data, the sequence, the screen, and the story. Your job as a buyer isn't to enjoy the show. It's to find out what happens when the show ends.
Here are five checks. None of them require technical depth. All of them require you to interrupt the script.
1. The ugly question.
Somewhere in the first twenty minutes, ask what happens when it breaks. Pick something real: "What does the user see when the sync fails?" "Walk me through a permissions error." A great vendor will show you — live, on screen, without flinching. A nervous one will describe it instead of showing it, or promise to "follow up on that." Demos are built on the happy path. The product lives everywhere else. You learn more from one failure state than from ten features.
2. The clock check.
Quietly time how long it takes before your problem shows up on screen. Not their features — your problem, in your words, with something that looks like your data. Under ten minutes: they did discovery and built the demo around you. Over thirty: you're watching the same demo the last prospect saw, and the next one will too. A feature tour isn't a demo. It's a brochure with a mouse.
3. The unanswerable.
Ask one question they can't possibly know cold — something specific to your environment, your scale, your edge case. You're not grading the answer. You're grading the response. "I don't know — let me find out and get back to you by Thursday" is the best answer in enterprise software. A fluent, confident answer to a question nobody could actually know is the worst one. If they'll bluff on the small thing, they'll bluff on the big thing.
4. The anti-pitch.
Ask them directly: "Who is this product wrong for?" Every real product has a bad-fit customer, and every honest vendor knows exactly who theirs is. If the answer is "honestly, it works for everyone," you've learned the pitch has no edges — which means you can't know where you stand relative to them. The vendor who tells you where the product is weak has just told you they'll keep telling you the truth after the contract is signed.
5. The second-meeting test.
The demo is one data point. The follow-up is the trend line. Did the answers they promised arrive when they said they would? Did the second meeting match the first, or did the story shift? Trust isn't built in the demo — it's built in the gap between meetings, where nobody is performing. One great meeting is charisma. Two consistent ones are character.
Notice what these five checks have in common: none of them test the product. They test the people. The product will change three times before your contract renews. The people — how they handle failure, whether they listened, what they do when they don't know, where they admit weakness, whether they follow through — that's what you're actually buying.
And here's the inversion, for the sales engineers reading this: the best move you can make with a sharp buyer is to hand them this checklist. Show the failure state before they ask. Name your bad-fit customer before they probe for it. The vendor with nothing to hide hands the buyer the flashlight.
The field guide in one line: Don't watch the demo. Watch what happens when you interrupt it.
What's the one question you always ask a vendor — the one that tells you everything? Reply and tell me. The best ones will show up in a future issue (anonymized, always).
— Dan
$5.00
Help make technical communication better.
Every contribution helps create more tutorials, architecture diagrams, demo walkthroughs, and practical resources that... Read more
Helping technical professionals earn trust through clear communication.
Every Friday, one short email for sales engineers, solutions architects, developer advocates, and anyone who explains technology for a living: one lesson in technical communication, one demo worth studying, one practical AI workflow, and one habit that builds trust.
Read more from Technical Trust Weekly · by Dan Davidson