What discovery actually is
Discovery is the part of the deal where you figure out what the user is really trying to do. That sentence sounds simple. It's the most underrated and most under-practiced skill in the role.
Most new SAs treat discovery as a checklist — a set of standard questions to run through so they can move on to the part of the meeting that feels like the real work, which is usually the demo. This is almost exactly backward, in the same way that "getting the appetizer out of the way so we can move on to dessert" is backward. Discovery is the real work. The demo is downstream of it. A good demo built on weak discovery lands worse than a mediocre demo built on strong discovery, because the demo is only useful insofar as it speaks to what the user actually cares about.
The shorthand version of this is "no discovery, no demo." It's a phrase worth keeping handy for the AE who pings you Friday at five with a Monday-morning demo slot for a user nobody has actually talked to yet. The right answer in that situation is almost always to push the slot, not to scramble to fill it. A demo into a vacuum is worse than no demo at all, because it sets the wrong expectations about what your product is and what the user is actually buying.
The reason discovery feels uncomfortable for new SAs is that it requires you to be in the room without yet being the expert. You haven't shown what you know. You're asking questions instead of giving answers. The natural pull is to short-circuit the discomfort by jumping into product mode, where you're back on familiar ground. Resist it. The discomfort is the work. The longer you can stay in genuine inquiry, the better the rest of the deal will go.
Prep is half of discovery
A surprising amount of discovery happens before the call starts.
The first thing to do is visit the user's website. Not skim it. Actually go look at what they sell, who they sell it to, how they describe themselves. Sign up for their app if there's a free tier. Read the docs that are relevant to what you'd be supporting. Skim recent press, the team page if you want to know who you might end up talking to.
Twenty minutes of this turns a cold call into a warm one. You walk in already knowing what kind of business they run, what their user base looks like, what their stack probably involves. You can ask better questions because you have specific things to ask about. You don't have to spend the first ten minutes of the meeting catching up on what you should have known before you arrived.
The second thing to do is figure out who's going to be in the room. The AE usually has this information, sometimes in detail, sometimes in fragments. If there are names you don't recognize, look them up on LinkedIn. Knowing that the person on the other end of the call is the head of engineering versus a senior product manager versus a procurement lead changes how you should run the meeting. The technical depth, the language, the level of abstraction — all of it adapts to who's in the room.
The third thing to do is come in with questions. Not a script, but a working list of the things you'd want to know to give them genuinely useful guidance. Some of those questions you'll get to. Some you'll set aside because the conversation goes somewhere more interesting. But starting with a list — written down, in front of you — is the difference between a deliberate meeting and an improvised one.
Adopt their nomenclature
Every user you'll talk to has their own internal language. Every company does. The way they refer to their users, their products, their teams, their integrations — the specific words and abbreviations they use — is part of how their organization thinks. When you adopt their language back to them, you signal that you've been listening and that you're going to do the work of understanding their world.
When you don't, you signal the opposite. The vendor who walks in and immediately starts using their own internal jargon — the platform names, the team abbreviations, the marketing taxonomy — comes across as someone who hasn't done the homework, even when they have.
This is harder than it sounds because your own company's language is so familiar that you forget it's not universal. Your platform's specific terms — the product names, the API objects, the integration patterns — sound like neutral English to you. To the user, they're a foreign vocabulary they have to translate every time you use one. The translation cost adds up, and over a long meeting it leaves them tired in a way that hurts the relationship.
The discipline is to listen for the user's words and use them back. When they call something a "merchant," you call it a merchant, even if your platform calls it an "account." When they call their integration "the gateway," that's what it is for the rest of the conversation. When you have to introduce one of your own terms — because there isn't a clean equivalent — define it cleanly the first time and then use it consistently. Don't make them learn five new pieces of jargon in a single call.
Put them in the expert seat
One of the most powerful moves in discovery is one many new SAs avoid because it feels like giving up control: putting the user in the expert seat from time to time.
What this means in practice is asking them to teach you something. Not in a transparent or condescending way, but genuinely. You don't know their business as well as they do. You don't know why they made the architectural choices they made. You don't know what their constraints are or what trade-offs they've already worked through. They do, and they almost always want to talk about it if you give them room. Most users have at least one architectural decision they've been waiting for someone to ask about. You'll know it when you find it because the meeting suddenly has an extra fifteen minutes of energy.
A few openers that land well:
"Help me understand how this works on your side — walk me through what happens when..."
"That's interesting — why did you decide to do it that way?"
"I want to make sure I'm not making assumptions. Can you tell me more about how your team thinks about..."
These aren't tricks. They work because they're real. The user has information you don't have, and you genuinely need it to be useful to them. The conversational benefit — the user feeling heard, the relationship warming, the dynamic shifting from "vendor selling" to "two people working on something together" — is downstream of actually wanting to understand.
The thing to watch for is balance. You don't want to spend the entire meeting in expert-seat mode, because at some point the user does want your perspective and your knowledge of your platform. The flow that works best is alternating — you ask them to teach you something, they explain, you absorb it, you bring it together with what you know about your platform, you offer a perspective they didn't have. They feel both heard and informed. That's the rhythm of a good discovery call.
Have an objective for every interaction
Going into any meeting, you should be able to answer one question: what do I want to be true at the end of this call that isn't true now?
The answer might be operational ("I want to know which of their three potential use cases is the one they're actually going to start with"). It might be relational ("I want their head of engineering to feel like she got real value from the conversation"). It might be tactical ("I want to surface the security-review process so we can start planning around it"). It doesn't have to be ambitious. But it has to be specific.
Having an objective doesn't mean steering the meeting rigidly toward it. It means having a thing you're tracking, in the back of your head, while the meeting unfolds. If the meeting goes off in an unexpected direction that turns out to be more important than your objective, you let it go and follow the more important thread. But you do that deliberately, not by drift.
The failure mode without an objective is meetings that feel productive but don't actually advance the deal. Lots of conversation, lots of nodding, friendly tone, no specific next step, no specific new information. You walk out feeling like the meeting went well and a week later you can't remember what was decided. An objective protects against this. If you can't articulate what you wanted out of the meeting, you can't tell whether you got it.
Adapt to their needs
The user you're talking to in any given meeting is bringing their own context to the conversation — what they know, what they don't know, what they're worried about, what they're excited about, how much time they have, who they're trying to convince internally. The standard playbook for a discovery meeting is a starting point. The actual meeting needs to adapt to who's in front of you.
Some users want a deep technical conversation in the first call. Others want the executive summary first and the depth later. Some users have done a lot of research before the call and want validation of conclusions they've already reached. Others are starting from scratch and want to be educated.
The skill is reading which user you have and adapting in real time. The signals are usually visible early. The user who opens the call by saying "I've been through your docs and I have specific questions" is telling you the meeting they want. The user who opens with "I'm not sure exactly what you do, can you give me the overview" is telling you a different one. The user who keeps redirecting your detailed answers back to high-level strategic questions is telling you yet a third.
This is also where the room composition matters. With an executive in the room, you stay higher-level by default and let them draw you down into detail when they want it. With engineers in the room, you can go deep faster, but you also have to be careful not to lose any non-engineers who might be on the call. The general principle: the more people there are in the room, the higher level you go. Let them draw you to the level they want.
The discovery cycle is often longer than you expect
A common mistake — both by new SAs and by impatient AEs — is to try to compress discovery so the deal can move faster. This usually backfires.
Discovery isn't a phase you finish; it's a layer that runs through most of the deal. You'll find that even after what feels like exhaustive early discovery, new things keep surfacing in later meetings — a constraint nobody mentioned, a stakeholder who hadn't been involved, a use case that turns out to be more important than the one you were focused on. That's normal. Real organizations are complicated and people don't always know what they don't know about their own situation until something prompts them to look.
When new things surface late, the move is to slow down, not to push through. The user surfacing a new constraint in week six is doing you a favor. They're showing you something that would have come up later anyway, when it would have cost you more to address. Treat it as a gift. Spend the time to understand it. The deal will close better for the time you took.
Sometimes a user surfaces "new" things repeatedly because they're not actually ready to buy and don't know how to say so. The pattern looks similar at first — open questions, new concerns, scheduling delays — but the texture is different. In genuine discovery, the questions are getting more specific over time. In stalling, the questions stay vague or keep shifting around. The way to tell the difference is to ask, directly: what would need to be true for you to move forward on this? The user who's genuinely working through real questions will have a real answer. The user who's stalling will have a vague one. Both are useful information.
A note for builders
The most important thing you can do, structurally, to make discovery work in your SA function is to give your SAs enough room in the calendar to actually do it.
A function that's running at 100% utilization will skip prep. There's no room for the twenty minutes of pre-call work that turns a cold call into a warm one. There's no room to think about what the right objective for the meeting is. There's no room to write the kind of notes that future-you needs to come back into the deal cleanly.
The SAs will still go to the meetings. The meetings will still happen. The deals will still close at some rate. But the function won't be doing its actual highest-leverage work. It'll be doing the visible parts and skipping the parts that compound.
The fix is unsexy: budget the prep time. Make it explicit. A reasonable rule of thumb is that for any external meeting, you should have at least as much time scheduled around it as the meeting itself takes — half before for prep, half after for notes and follow-up. That sounds like a lot until you compare it to the cost of meetings that don't land. Discovery is the place where this discipline pays back the most.