You're thirty seconds into a discovery call. The CTO explains they're having performance issues with their current solution. You nod. You already know what's coming. You've seen this pattern a hundred times. Microservices scaling. Database queries. Cache layer missing. You're already mentally building the demo in your head.
By minute fifteen, you realize you have no idea what you're actually talking about.
Temptation
The trap is professional confidence.
You've done this job long enough that you should know what questions to ask. You've listened to thousands of customers describe essentially the same problem. Your brain recognizes the pattern and fills in the blanks. The pattern says: "This is a scaling problem."
So you ask scaling questions.
You show demos about throughput and concurrency and load balancing.
You talk about architecture decisions.
The customer listens politely. Asks a few clarifying questions. Schedules another call.
And nothing changes.
The Trap
Here's what actually happened.
The customer said "performance issues."
You heard "scaling issues."
Those are not the same thing.
Performance could mean:
- Latency for one specific user workflow (not throughput)
- Batch processing taking 6 hours instead of 2 (scheduling, not architecture)
- A third-party integration that's slow (not your product)
- Unpredictable spikes (monitoring, not scaling)
- Pages that load differently based on customer segment (data freshness)
But you asked about scaling because that's what you expected them to need.
Your assumption became invisible to you.
And because it was invisible, the customer never corrected it.
The Asymmetry
You assumed you knew the problem. The customer assumed you understood their industry.
The Bold Fix
Stop assuming. Start verifying.
The moment a customer describes a problem, your job isn't to solve it.
Your job is to make sure you both agree on what it is.
This requires a specific discipline: Ask the question even when you think you already know the answer.
Not to show politeness. Not to be thorough.
But because your assumption is probably wrong.
The Anatomy
There are three places assumptions hide in discovery:
1. The Industry Assumption You assume you understand their business model because you've sold to "five other healthcare companies" or "two other fintech firms." But this company's revenue model, compliance requirements, and customer segments might be completely different.
Fix: "Walk me through how you actually make money here. I want to make sure I'm not making assumptions."
2. The Problem Assumption Customer says "We need to scale to 10 million users." You assume they mean concurrent users. They might mean total users. They might mean events per second. They might mean something else entirely.
Fix: "When you say scale to 10 million, what does that actually look like? Is that concurrent, total, or something else?"
3. The Priority Assumption Customer mentions five problems. You identify which one is "clearly" the biggest. But "clearly" is only clear to you, based on patterns you've seen. Their actual priority might be completely different — driven by a deadline you don't know about, a compliance requirement you didn't ask about, or an internal politics situation you couldn't possibly predict.
Fix: "Of those five things, which one, if solved, would move the needle most for your team?"
The Counterintuitive Inversion
Great SEs are not the people who know the most answers.
Great SEs are the people who ask the best questions even after they think they know the answer.
The confidence to say, "I think I know where this is going, but let me verify," is rarer than you'd think.
Most SEs skip the verification. They've got thirty minutes and a checklist.
But that thirty minutes where you don't assume?
That's where trust actually happens.
Three Bold Contexts
Context 1: The Confident SE Walks into the call with a hypothesis. Asks leading questions that confirm it. Leaves feeling like the discovery went great. Customer leaves thinking, "They didn't really listen."
Context 2: The Curious SE Walks in with a hypothesis. Tests it relentlessly. Finds out it's wrong halfway through. Recalibrates. Asks better questions. Leaves with clarity. Customer leaves thinking, "They actually get us."
Context 3: The Stuck SE Walks in with no hypothesis. Tries to ask open-ended questions for forty minutes. Gathers a hundred data points. Leaves with no clarity. Customer leaves thinking, "That was a waste of time."
The goal is Context 2. You need both a hypothesis and the discipline to challenge it.
Pattern to Remember
The Assumption Trap: Confidence in patterns becomes invisible to the person holding it. You stop asking questions because you think you already know the answer. The customer stops correcting you because they assume you're the expert. Discovery becomes performance instead of investigation.
The fix: Verify even when you're certain. Ask the clarifying question anyway. The moment you realize your assumption was wrong is the moment discovery actually begins.
Hit reply and tell me: What's one assumption you made in a discovery call that turned out to be completely wrong?
(Anonymized, always.)
