Technical Discovery: Questions That Reveal Real Fit

The deal demoed perfectly. Live data. Custom workflow. The buying committee laughed at the right moments. Verbal commit by Friday. I sent the order form Monday morning.

Then the security questionnaire showed up: 312 questions, sent by a CISO I'd never spoken to, with a SOC 2 Type II requirement I knew we couldn't meet on their timeline. The deal didn't die quickly. It died over six weeks of email threads, two escalations, one rewritten MSA, and a final "we're going to extend our current contract for another year." We never got the demo replay watched. The AE moved on. I kept the calendar invite for the kickoff call I never ran.

The deal didn't die in security review. It died in technical discovery — the discovery I never ran because the prospect was excited and I confused excitement with fit.

This is the article I wish someone had handed me before that quarter.

Why Technical Discovery Beats a Better Demo

A demo answers the question "can your product do X?" Technical discovery answers a different question: "should we even be having this conversation?" Most pre-sales teams optimize the first and skip the second, then wonder why their pipeline coverage looks healthy in March and their close rate looks broken in June.

Three things a real discovery call surfaces that a demo cannot:

• Fit. Whether the prospect's data model, integration topology, and operational rhythm map to how your product actually works, not how the marketing site says it works.
• Risk. The procurement, security, and change-management gauntlets that decide whether a verbal yes becomes a signed contract.
• Disqualifiers. The hard requirements you can't meet, the timelines you can't hit, the deployment models you don't support. Surfacing these in week one is a gift. Surfacing them in week eight is a career-limiting move.

Demos that follow proper discovery convert two to three times better than demos that don't, in roughly every pipeline I've audited. The mechanism is simple: discovery turns a generic demo into a tailored one, and a tailored demo answers the buyer's actual questions instead of the SE's favorite features.

The 7-Area Technical Discovery Framework

Run every technical discovery against these seven areas. Skip an area only when you've explicitly decided it doesn't apply, never because you ran out of time.

Print this. Keep it in your discovery doc. Every call, every area.

The 3-Question Disqualification Test

Before you accept a demo invite, run these three questions past the AE, or directly past the prospect on a 15-minute pre-call. If you can't answer all three, you don't have enough to demo well, and you should push back on the timeline.

1. What's the hard requirement that, if we can't meet it, kills the deal?
2. Who outside the meeting has veto power, and what do they care about?
3. What's the realistic decision window — this quarter, next quarter, or "exploring"?

These aren't trick questions. They're a sniff test. If the AE doesn't know the answers, the deal isn't qualified yet. If the prospect doesn't know the answers, they're earlier in the process than the AE thinks they are. Either way, a demo right now is the wrong next step.

Discovery Questions That Earn Their Keep

These are the questions I keep coming back to, in roughly the order I ask them. Mix the open-ended ones with the disqualifying ones. Use whichever feel natural in your voice. Just use them.

"Walk me through the last time someone on your team needed [outcome] —
what did they actually do, screen by screen?"

This is the single best opener I know. It forces the prospect to narrate reality instead of describing aspiration. You learn the workflow, the workarounds, the actual tools, and the actual pain, all in one answer.

"If we removed your current tool tomorrow, what breaks first?"

This separates the must-haves from the marketing copy. If nothing breaks, the urgency is lower than the AE thinks. If three things break, you've just been handed your demo outline.

"Who outside this room needs to say yes — and what do they care about
that you don't?"

The buying committee question. Asked this way, it gets you names, titles, and motivations in one breath. The "that you don't" clause is the load-bearing part. It surfaces the security reviewer, the IT director, the finance partner who's going to ask questions your champion never thought of.

"What does your security team need to see before signing off on a new
vendor — and how long does that usually take?"

The single question that would have saved the deal I told you about earlier. Always. Always. Always.

"What system is the source of truth for [customer/deal/contact data]
today, and what writes back to it?"

This is your data-model question. The answer tells you the integration shape, the migration scope, and the political ownership of the data. If the answer is "honestly, it depends on who you ask," that's not a disqualifier, but it is a giant yellow flag for change management.

"When was the last time you rolled out a tool like this, and what made
it succeed or fail?"

Past behavior is the best predictor of future behavior. The answer tells you whether they have rollout muscle, who their internal champion-killer is, and what stories they're going to tell about you in twelve months.

"What's a hard requirement vs a nice-to-have? If we can't do [X], is
the deal dead?"

Direct, slightly uncomfortable, and the most respectful question you can ask. Prospects appreciate it. AEs sometimes flinch. Ask it anyway.

"How are you measuring the problem today — what's the number that has
to move?"

If they can't name a number, the project doesn't have a budget owner yet. That's not always a disqualifier, but it changes the deal stage and the timeline.

"Who owns the integration work on your side, and how booked are they
next quarter?"

The question that surfaces implementation risk before it becomes an implementation crisis. A great product with no engineer to install it is a dead deal in slow motion.

"If we're a fit, what does the next 90 days look like on your side?"

This is your closing question. Not "are we a fit," which asks for a verdict you haven't earned yet. "What does the next 90 days look like" assumes mutual evaluation and surfaces the procurement, legal, and rollout reality. If their 90 days don't include any of those, the timeline is fiction.

Running Discovery in 30 vs 45 vs 60 Minutes

Time on calendar is the constraint that shapes every discovery call. Here's what I cut, and what I never cut.

60 minutes (ideal): All seven areas. Open-ended start, structured middle, summary close. Leave 5 minutes for buyer questions.

45 minutes (typical): Drop the deep dive on scale and support expectations. Make those a follow-up email or a second call. Keep data model, integrations, security, deployment, and change management.

30 minutes (compressed): This is not technical discovery. This is a triage call. Run the 3-question disqualification test, ask the data model question, ask the security question, and book the real call. Don't pretend a 30-minute slot is enough, and don't agree to demo at the end of it.

What never gets cut, regardless of time:

• The security question. Ever.
• The "what breaks if we removed your current tool" question.
• The 90-day forward look.

Everything else can flex. Those three are non-negotiable.

The AE Pre-Call Brief: What You're Owed

A discovery call you walk into cold is a discovery call you've already half-lost. Before any technical call, the AE owes you a one-page brief covering:

• Account context. Industry, size, geography, current tech stack (if known).
• Why now. What triggered this evaluation: a contract renewal, a new exec, a failed implementation, a regulatory shift.
• Stakeholders on the call. Names, titles, roles in the decision. Who's the champion, who's the skeptic, who's the budget owner.
• What's been said so far. The two or three things the AE heard in the first call that matter: pain points, objections, competing tools.
• The ask. What outcome the AE wants from this call: a follow-up demo, a security review kickoff, a proof of concept, a disqualification.

If you don't get this brief, ask for it. If you can't get it, do a 10-minute pre-call with the AE before the prospect joins. Walking in cold is a choice, and it's the wrong one.

The Post-Call Summary: 24-Hour Rule

Within 24 hours of every discovery call, the SE sends a summary email to the prospect (cc the AE). Three reasons:

1. You confirm what you heard. Misunderstandings surface in writing in a way they don't in conversation.
2. You force the prospect to either correct you or commit. Either is useful information.
3. You create the record the deal will be evaluated against later by your manager, by the deal review committee, by the prospect's procurement team.

The template:

Subject: [Prospect company] — discovery summary + next steps

Hi [Name],

Thanks for the time today. Quick summary of what I heard so I can
make sure the next conversation is useful.

What you're solving:
- [pain point 1]
- [pain point 2]
- [pain point 3]

Hard requirements I noted:
- [requirement 1]
- [requirement 2]

Key stakeholders we'll need to bring in:
- [name, role, what they care about]

Open questions I want to come back with answers on:
- [question 1]
- [question 2]

Proposed next step: [specific call, date, attendees, agenda]

If anything above is wrong or missing, please reply with corrections
before [date] so we don't build on the wrong foundation.

Thanks,
[SE name]

The "if anything is wrong, reply" line does more work than any other sentence in the email. It invites correction without asking for permission, which is what you want.

Common Pitfalls

Asking "how does it work today?" without follow-up. It's a fine opener, but the answer is always vague. The follow-up ("walk me through the last time someone needed X, screen by screen") is where the gold lives. One question is interrogation. Two questions is consultation.

Demoing instead of discovering when the prospect asks for screens. Prospects will ask. They're not being difficult; they want signal. Hold the line. "Happy to show you that. Let me ask two more questions first so I know which version of the workflow to show you." That's a complete sentence and a professional response.

No technical disqualification because "we'll figure it out later." "Later" is when the deal dies. If you can't meet a hard requirement, say so on the discovery call. The deal you save by being honest in week one is the deal that comes back in twelve months when their requirement changes. The deal you lose by being honest in week eight is the deal that costs you a renewal at another account.

Letting the AE drive a technical call. Some AEs default to demo-mode the moment a prospect engages. Push back. The pre-call brief, the agenda, and the question order are yours. If the AE wants to drive, schedule a separate call for them.

Treating discovery as interrogation instead of consultation. Twelve questions in ten minutes is interrogation. Three questions with deep follow-up over thirty minutes is consultation. Slow down. Listen for the second sentence, the one that comes after the prospect's first answer, where the real information is.

For a deeper look at what to do once discovery is done, see Demo Design That Maps to Buyer Pain. When prospects push back on what you've found, Handling Technical Objections Without Defensiveness is the companion piece.

Measuring Success

Four numbers tell you whether your discovery process is working.

• Discovery-to-demo conversion rate. The percentage of discovery calls that lead to a tailored demo with the right stakeholders. A healthy number is 60–75%. Below 50% means your AEs are sending unqualified deals to discovery. Above 90% means you're not disqualifying enough.
• Technical win rate after discovery. Of the deals where you ran proper discovery and built a tailored demo, what percent close? This should be measurably higher than your baseline win rate. If it's the same, your discovery isn't shaping the deal.
• No-show rate after technical discovery. A leading indicator. Prospects who skip the demo after a real discovery call are telling you something, usually that the discovery surfaced a fit issue they didn't want to say out loud. Above 15% is a yellow flag.
• Percentage of deals that die in security or implementation. A lagging indicator of discovery quality. Deals dying in security review six weeks after a verbal commit means the security question wasn't asked early enough, or the answer wasn't taken seriously.

For a fuller treatment of SE measurement, see Sales Engineer Metrics That Actually Matter.

What Senior SEs Get Right That Junior SEs Don't

Junior SEs ask questions to fill silence. Senior SEs ask questions to find the truth, then sit in the silence afterward while the prospect tells them more than they planned to.

Junior SEs save their hardest questions for the second call. Senior SEs ask the hardest questions in the first ten minutes, because if the answer is bad, they want to know now. The deals you disqualify in week one are the deals you don't have to apologize for in week eight.

The questions in this guide are the questions I wish I'd been asking three years before I started asking them. Steal them, change them, make them yours. Just don't run another demo without asking them first.

For more on the traps SEs walk into without realizing it, Common Pitfalls Every Sales Engineer Hits covers the rest of the list.