23 DAYS AGO • 3 MIN READ

The Question the Buyer Didn't Know to Ask

profile

Technical Trust

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.

TechnicalTrust.org

July 31st

The Question the Buyer Didn't Know to Ask: why discovery — not the demo — is where trust is actually won.

The demo was strong. The answers were honest. Nobody bluffed, nobody feature-dumped.

The deal still went to a competitor.

When the buyer was gracious enough to explain why, she didn't mention a single feature. She said: "They just seemed to understand our situation better."

Two weeks ago, in The Feature Dump, I ended with a line I didn't explain: it was a discovery problem. This is the chapter behind that sentence.

Two sets of questions

Every buyer walks into an evaluation carrying two sets of questions.

The first set is written down. Does it integrate with our stack? What's the pricing model? How does SSO work? These are the questions they know to ask — the checklist.

The second set is not written down, because the buyer hasn't articulated it yet. What actually breaks in our current process? What will my team resist? What am I really being asked to guarantee when I sign this?

Here's the uncomfortable part: the first set decides almost nothing. Two competent vendors will answer the checklist about equally well.

The second set decides everything. And the vendor who surfaces it — who asks the question the buyer didn't know to ask — wins, because there is no faster way to earn trust than to articulate someone's problem better than they can articulate it themselves.

Trust isn't won when you explain your product. It's won when the buyer feels understood.

The two ways discovery goes wrong

Watch enough discovery calls and you'll see the same two failures.

The Premature Pitch. The buyer states a need, and the seller treats the first stated need as the real need. "You need reporting? Let me show you our dashboards." The pitch starts before the problem is fully on the table. It feels responsive. It's actually a door closing — every minute spent presenting is a minute the second set of questions stays buried.

The Checklist Interrogation. The opposite failure, and just as fatal. Twenty qualifying questions, fired in sequence, straight from the CRM fields. Budget? Timeline? Decision process? The buyer answers all of them and leaves the call feeling processed, not understood. Discovery became data collection. The form got filled out. Nothing was discovered.

Both failures share one root: they treat discovery as a phase to get through on the way to the demo. But discovery isn't the warm-up act. It's where trust gets minted.

The counter-move: the question behind the question

Here's the discipline, and notice the anatomy — it has three parts.

When the buyer asks a checklist question — "Does it integrate with X?" — don't answer yet.

First, ask what's underneath. "It does — can you tell me what X handles for you today?" You're not dodging. You're refusing to answer a question you don't understand yet.

Second, listen for the situation under the requirement. The integration question is never about the integration. It's about a workflow someone is afraid of breaking, a migration that went badly once, a team that's been burned.

Third, say their problem back in their own words — and let them correct you. "So the real concern is that your ops team lives in X, and anything that forces them out of it is dead on arrival. Is that right?"

The correction is the point. Every time the buyer corrects you, they're teaching you their business. And every time you adjust and restate, they watch their own problem come into sharper focus — spoken by someone else. That's the moment the second set of questions starts surfacing on its own.

Notice what this move costs you: nothing technical. No product knowledge required, no roadmap access, no seniority. It only requires the willingness to not answer immediately — which, if you've been reading since Edition #1, should sound familiar. The Confidence Bluff and the Premature Pitch are the same reflex wearing different clothes: the fear that a pause looks like weakness.

It doesn't. The pause is where the trust is.

Where to use this in the next seven days

If you're running discovery: pick one requirement from your next call and ask, "What's happening today that makes this a requirement?" Then stay quiet longer than is comfortable.

If you're the buyer: notice whether the vendor asks about your situation or your checklist. A vendor who only answers your written-down questions is selling to your form, not your company.

If you're coaching: in your next deal review, ask the team, "What does this customer believe their problem is — in their words?" If nobody can answer verbatim, every demo in that deal is being aimed by guesswork.

The chapter to remember

Trust isn't won when you explain your product. It's won when the buyer hears their problem stated better than they could state it themselves.

$5.00

Help make technical communication better.

Every contribution helps create more tutorials, architecture diagrams, demo walkthroughs, and practical resources that... Read more

What's a question you wish a vendor had asked you — and never did? Hit reply and tell me. I read every one, and the best stories shape future issues.

​600 1st Ave, Ste 330 PMB 92768, Seattle, WA 98104-2246
Unsubscribe · Preferences

Technical Trust

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.