How I Run Technical Discovery Calls
A discovery call that turns into a demo or an interrogation is a wasted call. The goal is to leave with enough context to write a technical proposal, and enough credibility that the prospect wants to read it.
What Bad Discovery Looks Like
The version that goes wrong: you spend the first 30 minutes showing slides, then run out of time before getting to the technical environment. You leave with a list of stated requirements and no real understanding of the constraints behind them. The proposal you write back addresses the surface requirements and misses the thing that was actually going to kill the deal.
The version that also goes wrong: you ask so many questions it feels like a security audit. The prospect answers everything but doesn't feel like you understand their problem yet. No momentum.
Good discovery is a conversation where you're both figuring something out. Here's the structure I use.
The Call Structure
Confirm your understanding before asking anything. Brief them on what you already know: the platform they're evaluating, the rough shape of their environment, why they're looking now. Let them correct you. This signals that you've done homework and sets a collaborative tone.
I'll usually say something like: "Before we get into it, based on what I know so far, you're running Entra ID, you have an M&A integration coming up, and the provisioning workflow is the main concern. Is that the right frame?"
Getting corrected here isn't a failure. It's exactly what you want.
Start with current state, not desired state. Most discovery conversations jump straight to requirements. That skips the part where you understand how things work today, what's broken about it, and why it's broken that way. The history matters. The reason things are the way they are often tells you more about the constraints than any requirements document.
"Walk me through what happens today when a new employee needs access to this platform."
"What's the most common thing that breaks in that process?"
Know who's in the room. A platform owner has different concerns than an IT admin, who has different concerns than someone from InfoSec. If there are three people on the call and you don't know what each of them cares about, you're guessing at what matters. Ask if you need to.
Surface blockers, not just requirements. Requirements tell you what they want. Blockers tell you what will prevent this from moving forward.
"What would make this a bad fit?"
"Is there anything on the security side that needs to be resolved before this can move forward?"
"What's happened with similar projects in this organization?"
That last one is the most useful. If the last three integration projects got stuck in security review for six months, that's your actual constraint.
Close with something specific. A call that ends with "we'll follow up" goes cold. Before you hang up, confirm the next concrete step and who owns it on both sides.
What I Document Afterward
Every discovery call gets a short written summary before I do anything else:
- Current environment: what's deployed, what's connected, what's still manual
- Stated requirements and the implied requirements underneath them (often different)
- Who's involved in the decision and what each person needs to feel confident
- Technical blockers and compliance requirements
- Open questions and next steps with owners
This summary becomes the technical proposal. If you can't write a clear summary, the call didn't go deep enough.
The Thing That Matters Most
The goal isn't to collect information. It's to understand the problem well enough that when you propose a solution, the prospect feels like you actually got it. That feeling is what creates momentum.
If they leave the call thinking "this person understands our environment," everything that follows is easier.