9 DAYS AGO • 3 MIN READ

The Eager Yes

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

August 7th

The Eager Yes

Understanding ≠ Relevance. Here's the discovery mistake that kills deals.

You're three minutes into discovery. You ask: "Do you struggle with visibility into how your infrastructure is scaling?"

The customer nods. "Yeah, that's definitely a pain point for us."

You feel it—that little rush. You found pain. You're tracking. You move forward, asking more questions, building a picture of their environment. They keep nodding. Everything resonates. By the time you schedule the demo, you're confident. You know exactly what they need.

Two weeks later, you give them a flawless demo. Clean architecture. Perfect use case. Everything aligned to what they said was broken.

And nothing clicks.

They're polite. Engaged. But there's no spark. No "yes, that's exactly what we need." Just a vague "we'll discuss internally and get back to you." And they never do.

You replay the discovery call in your head. Where did it fall apart?

It fell apart at the nod.

Here's why it's so tempting

A nod feels like validation. It tells you that your question landed, that they understood what you were asking, that you're on the right track. And technically, you are.

But here's the thing nobody tells you: understanding is not the same as relevance.

A customer can completely understand what you're saying—the words are clear, the concept is familiar, the problem makes sense—and still not have that problem themselves.

So they agree. Not because it's their situation. But because:

  • They understand the words you used
  • They think that's what you want to hear
  • They're being polite
  • They want to move the meeting along
  • They don't want to seem uninformed

A nod doesn't mean "this is our problem." It usually means "I understand what you're saying."

And you interpreted it as the first thing.


And here's why it's a trap

When you accept the eager yes without testing it, you build your entire discovery on a false foundation.

Your demo becomes a response to a problem they may not actually have. Your narrative aligns to pain that isn't theirs. Your solution feels tangential because it wasn't ever tangential to them—it was never even adjacent to their actual situation.

The demo is great. The company is great. But they don't see themselves in it.

They'd rather reschedule than say that. So they ghost instead.


The asymmetry: The customer understood everything you said. You understood nothing about their actual situation.

The fix: When you get the nod, pause. Ask again. This time, make it personal.


Notice the anatomy

Discovery isn't about asking questions and collecting yeses. It's about testing whether your questions are landing in their world.

The telltale sign that you've landed an eager yes (not a real yes) is when the customer:

  • Agrees generally but can't articulate specifically how the problem shows up for them
  • Nods but doesn't add examples
  • Says "yeah" but doesn't expand unprompted
  • Uses your language instead of their own when they describe the problem

The moment you hear the agreement, the real work begins. You have to ask back: "Walk me through what that looks like in your environment. How is this showing up?" or "Can you give me a specific example of when that's been a blocker?"

A real yes comes with specificity. An eager yes comes with agreement.


The counterintuitive inversion

You think pausing and asking for clarification will slow you down.

It won't. It will save you.

Pushing back on your own assumptions—"wait, what do you actually mean by that?"—isn't hostile. It's honest. It says: I want to understand your world, not assume I already do.


Three contexts where the eager yes lives

First discovery call
You're new. They're polite. They haven't invested yet. A nod is easier than a "no, that's not actually our problem." Test it ruthlessly here. This is where false positives get expensive.

Multi-stakeholder follow-ups
The CFO defers to the CTO. The CTO assumes the original person spoke for everyone. Someone agrees to move things forward. No one is being dishonest. Everyone is just being efficient. Revisit assumptions with each new stakeholder.

When you're leading the discovery
If you shaped the questions, you shaped the frame. They're more likely to agree with your frame than correct it. Flip it: ask them to describe the problem in their terms before you describe it in yours.


The pattern to remember

Understanding without relevance is just politeness in a tuxedo.

Your job in discovery isn't to get agreement. It's to get clarity. Ask until the customer isn't just agreeing with what you said. Ask until they're articulating what's actually broken in their world.

The nod matters. But only when it comes after specificity.

$5.00

Help make technical communication better.

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

Have you walked into a demo confident you'd nailed discovery, only to realize mid-presentation that they were just being nice? 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.