2 DAYS AGO • 3 MIN READ

Technical Trust Weekly: The Vocabulary Test

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.

Technical Trust Weekly

August 21st

The Vocabulary Test:
Understanding ≠ Relevance.



Here's the discovery mistake that kills deals.

You're 20 minutes into discovery. The customer mentions their "integration challenges."

You nod. You think APIs. You think webhooks. You think data synchronization between systems.

So when you ask, "What kind of integrations are slowing you down?" they answer, and you're tracking. You take notes. You see a clear path to how your product solves this.

Two weeks later, you're in the demo. You walk through API documentation, show how third-party tools connect, explain rate limits and authentication. It's crisp. Well-structured. Exactly what you'd want to see if you were integrating systems.

And they're... confused.

"That's not really the problem we have," they finally say.

Turns out, "integration challenges" meant something completely different to them. They weren't talking about technical APIs. They were talking about data flowing between their three internal teams. Different tools, different spreadsheets, nobody talking to each other.

They needed workflow. You showed them plumbing.

You both used the same word. You meant different things.


Here's why it's so tempting

When someone uses industry language—"integration," "automation," "real-time," "scalability"—it feels like you're speaking the same language.

It feels like understanding.

But here's what you're actually doing: you're assuming your definition matches theirs.

And sometimes it does. But not always.

The temptation is to move forward. You got the vocabulary. You got agreement. You can build a demo.

Move forward.

But you're building a demo for a problem that doesn't exist.


And here's why it's a trap

The trap is that they won't correct you.

Not because they're being difficult. But because they assume you're the expert. You're using the technical terminology confidently. They said "integration," you said "integration," and you both nodded. So they assume you understood.

Until the demo lands and it's obviously wrong.

By then, they've already invested time. They're already skeptical. And they're starting to wonder whether you were ever listening at all.

The asymmetry: You both spoke fluent English. You spoke different languages.

The fix: When they use industry language, ask them to translate it into their world.


Notice the anatomy

The moment you hear a term that could mean multiple things, you have a choice:

Assume you know what they mean, or verify.

Most SEs assume. It's faster. It feels confident.

But here's what happens when you assume wrong: you waste two hours building a demo for the wrong problem. You waste their time sitting through it. You waste the deal.

The verification takes two minutes.

"When you say 'integration,' what does that look like in your world? Walk me through it."

Their answer will either confirm your assumption or completely reframe the conversation.

Either way, you now have clarity.

The telltale sign that you've skipped the verification is when:

  • You confidently demo a feature they didn't ask for
  • They listen politely but don't light up
  • Afterward, they say "that's not quite what we meant"
  • You realize you built the wrong narrative

The counterintuitive inversion

You think asking for clarification will make you sound uncertain.

It does the opposite.

Asking "walk me through what you mean by that" signals precision. It signals that you care about their specific situation, not a generic template. It says: I'm listening to you, not to the version of you I imagined.

That builds more trust than false confidence ever will.


Three contexts where the vocabulary test lives

Early in discovery

This is when misalignment is most dangerous. You haven't heard their full story yet. One wrong assumption can poison everything that follows. Verify terminology early, and you build on solid ground. Skip it, and you're correcting course for the rest of the conversation.

Across different stakeholders

The CTO means something different by "real-time" than the VP of Product does. The Finance team's definition of "cost optimization" isn't the same as Ops. Each stakeholder uses the same words to mean different things. You can't assume carry-over from one conversation to the next.

When they use your language

This is the most dangerous moment. They've heard you explain the product. Now they're using your words. You think they understand because they're speaking your vocabulary. But they might just be mirroring you. Test it: ask them to describe the problem in their terms, not yours.


The pattern to remember

Vocabulary is not understanding.

Agreement on words is not agreement on meaning.

Your job in discovery isn't to hear the right vocabulary and move forward. Your job is to translate their language into specifics, their problems into your world, their world into your demo.

The moment they use a term that could mean multiple things, you've found a checkpoint.

Slow down.

Ask them to translate.

Build your demo on what's true, not what you assumed.


Have you walked into a discovery call confident about what a customer meant, only to realize mid-demo that you'd completely misunderstood? Reply and tell me what tipped you off. (Anonymized, always.)

— Dan

​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.