Most SE discovery is theater. Both sides know their lines. The customer says they need better visibility and faster incident response. The SE nods, writes it down, and walks out thinking they've learned something. They haven't.
Real discovery is uncomfortable. It surfaces problems the customer hasn't said out loud yet. It reveals whether the deal is real. And it gives the SE enough signal to build a demo and a success case that actually resonates, rather than one that covers every feature and hopes something lands.
The mistake most SEs make
The most common discovery failure isn't asking bad questions. It's accepting the first answer.
When a prospect says "we need better observability across our microservices environment," that is not a discovery finding. That's a category description. The discovery starts with the follow-up: What specifically breaks when you don't have it? Who finds out first? What does that cost you?
The discipline of going one level deeper on every answer is harder than it sounds. It requires patience, genuine curiosity, and the willingness to sit with silence rather than fill it. But it's the difference between a demo that feels custom and a demo that feels canned.
Three questions worth their weight
I'm skeptical of rigid discovery frameworks, they tend to produce mechanical conversations. But there are three questions I return to across almost every discovery call, regardless of product or industry.
"Walk me through the last time this was a real problem." Hypotheticals produce hypothetical pain. Specific past incidents produce specific pain, with names, timelines, and dollar figures attached. The details make everything that follows more concrete.
"What have you already tried?" This question tells you what's been ruled out, what's politically charged, and whether the buyer has already been burned by a similar solution. It also signals whether you're in a replacement cycle or net-new territory, two very different selling motions.
"What does success look like twelve months from now?" Not "what do you want from this product," but what does the broader situation look like if it works. This question often surfaces the real business outcome behind the technical ask, and it gives you language to use in your POV and in executive conversations.
Technical discovery is a different conversation
Business discovery and technical discovery are both necessary and often confused. Business discovery happens with economic buyers and champions. Technical discovery happens with the practitioners, the people who will actually deploy and live with the product.
The best SEs are fluent in both, and they know which conversation they're in. When you're in a technical conversation, specificity matters more than empathy. You want exact environment details: how many hosts, what orchestration layer, what existing tooling is in place and why, where the integration points are, what the current deployment process looks like.
This information shapes everything about how you position the solution. An SE who demos generic features to a DevOps team running Kubernetes on EKS with ArgoCD is wasting everyone's time. An SE who knows the stack and can speak to it directly has credibility that no slide deck can manufacture.
The goal is qualification, not validation
Here's the thing most SE training gets wrong: the goal of discovery isn't to build rapport or uncover enough to make a deck. The goal is to qualify, to determine whether your solution can actually solve a real problem that the customer genuinely wants to fix.
That means good discovery sometimes ends with "I don't think we're the right fit for what you're describing." That conversation is worth having early. A deal that dies in discovery saves everyone months of wasted POV work, executive escalations, and mutual frustration.
The SEs I've seen grow fastest are the ones who internalize this. Discovery isn't about finding a way to say yes to everything. It's about finding the truth fast enough to do something useful with it.
What AI changes here
AI pre-call research has compressed the time it takes to walk into a discovery call with baseline context. You no longer need 45 minutes before a call to pull together what the company does, what their tech stack looks like from public signals, and what's been happening in their space. That work is increasingly automated.
What that frees up is the conversation itself. If you're not spending discovery recapping publicly available context, you can spend it going deeper faster. The best SEs are using the time AI saves them to ask better second and third questions, not to multitask between prep work and listening.
Discovery is still a human skill. But AI makes the preparation for it more efficient, which raises the floor on what "good" discovery looks like.