Discovery and the Demo: The Heart of Presales

Lesson 1 argued that the SE is a problem-solver, not a demo monkey, and that the real work sits around the demo. This lesson is that real work. It covers the two skills that most decide whether an SE is effective: discovery and the demo, and the crucial fact that connects them.

Here is that fact, stated as plainly as possible: a demo is won or lost during discovery, not during the demo. The audience sees the demo and thinks that is where the persuasion happened. It is not. By the time you are presenting, the outcome is mostly determined by how well you understood the buyer beforehand. A brilliant presentation of the wrong things loses; a plain presentation of exactly the right things wins.

That inverts where a newcomer spends effort. Beginners obsess over demo polish, the smooth click-path, the impressive features, and skimp on discovery because it feels like preparation rather than the main event. Experienced SEs do the opposite: they treat discovery as the main event and the demo as its delivery.

So this lesson takes them in the order that matters:

• Discovery first, because it determines everything.
• Qualification, the SE's role in judging whether the deal is real.
• The demo, as a targeted argument built from what discovery found.

Get the order right in your head and the craft makes sense. Get it backwards and you will polish demos that never had a chance.

Discovery is the process of understanding the buyer's situation deeply enough to know what to show, what to say, and whether the deal is even real. It is a conversation, not an interrogation, and it has two layers that both matter.

• Business discovery: what is the business trying to achieve, what problem or pain is driving this, what does success look like, what happens if they do nothing, and what is it worth? This is the why.
• Technical discovery: what is their current environment and stack, what are the integration points, what are the constraints, security requirements, and technical must-haves? This is the how and whether it fits.

An SE must do both, and a classic failure is doing only the technical half. You can map their entire architecture and still lose, because you never learned what business outcome would make them buy. Technical fit without business pain is a solution to a problem no one is urgent about.

John Care, in the sales-engineering canon, is credited with a "First Law of Discovery", and its spirit is simple and strict: do the discovery before you present. You cannot tailor what you have not learned. An SE who demos before discovering is guessing at the audience, and a demo built on a guess is a feature tour by another name.

The deeper reframe: discovery is not information-gathering you endure so you can get to the demo. Discovery is the selling. It is where you learn the exact argument that will land, and often where the buyer, by articulating their own pain aloud, starts to sell themselves.

Good discovery is mostly good questions asked in a genuinely curious way, then real listening. A few principles make it work.

• Ask open, outcome-focused questions. "Walk me through how your team handles this today." "What happens when that process breaks?" "If this were solved, what would change for you?" These invite the buyer to describe their reality.
• Chase the pain, and quantify it. When a problem surfaces, dig into its cost and consequence. "How often does that happen?" "What does it cost you when it does?" A pain the buyer can put a number on is a pain worth solving, and it becomes the spine of your demo and business case.
• Uncover the technical shape. "What does your current stack look like here?" "What would this need to integrate with?" "What are your must-haves for security or compliance?" You need this to know what will actually fit.
• Listen far more than you talk. The SE who dominates a discovery call learns nothing. The goal is to leave knowing their world better than they expected you to.

A subtle but powerful move is to look past the stated request to the underlying need. A buyer asks "can you do X?" The novice answers yes or no. The skilled SE asks "what are you trying to accomplish with X?" Often X is their guess at a solution, and the real need is better served another way, which you can only discover by asking.

Everything you learn here becomes ammunition. Every pain, every metric, every constraint is something you will show, specifically, to be solved in the demo.

Discovery does not only shape the demo, it answers a harder question: is this deal real? SE time is expensive and scarce, so pouring it into a deal that will never close is a serious, invisible waste. Judging which deals deserve deep effort is qualification, and the SE is often the person best positioned to see the technical truth.

The most widely used qualification framework in enterprise sales is MEDDIC, and its extensions MEDDICC and MEDDPICC. The letters are a checklist of what you must know to believe a deal is winnable:

• M, Metrics: the quantified business value, the numbers from your pain discovery.
• E, Economic buyer: who actually controls the budget and can say yes.
• D, Decision criteria: what the buyer will judge the solution against.
• D, Decision process: the actual steps to a signed deal.
• I, Identify pain: the real problem driving the purchase.
• C, Champion: an insider with power who wants you to win.
• The extensions add Paper process (the legal, security, and procurement steps after a yes) and Competition.

MEDDIC is usually thought of as the AE's tool, but the SE contributes uniquely to several letters. The SE surfaces the Metrics (through pain quantification), tests the Decision criteria (often technical), and, crucially, develops the Champion, the technical insider who becomes your advocate inside the account. A technical champion the SE has genuinely convinced will fight for you in rooms you are not in.

The practical point: discovery is not just about what to show, it is about whether to invest. An SE who qualifies well spends their scarce time on deals that can actually close, which is a large part of being effective rather than merely busy.

Now the demo. With discovery done, the demo becomes something specific: a targeted argument that the buyer's problem is solved. Not a tour of the product. Not everything it can do. A focused case that their pain, the one you quantified, is addressed by this capability.

The difference is stark. Contrast two demos of the same product:

• The feature tour (bad): "Here is our dashboard, and our reporting, and our integrations, and our admin panel..." Comprehensive, impressive-sounding, and forgettable, because none of it is aimed at anyone. The buyer has to do the work of imagining how any of it helps them, and they will not.
• The targeted demo (good): "You told me your team loses hours every week reconciling reports by hand, and that a late report cost you a client last quarter. Let me show you exactly that: here is the report generated automatically, in seconds." Now every click is evidence for a claim the buyer already agreed matters.

The organizing principle, associated with Peter Cohan's Great Demo! method, is to lead with the payoff, not the setup. Show the compelling result first, the thing that solves their stated pain, then, only if needed, peel back the layers to show how it works. Beginners do the reverse: they build up slowly through setup and configuration and reach the payoff, if at all, after the audience has stopped paying attention.

The test for every moment of a demo is one question: which discovered pain does this address? If a screen does not map to something the buyer told you matters, cut it. A shorter demo that is all signal beats a longer one padded with features nobody asked about.

Beyond structure, a demo is a live performance in front of people who may be skeptical, distracted, or technical enough to probe. A few practices separate SEs who command the room from those who merely click through.

• Tell a story, do not narrate a UI. "Now I'll click here, and here" is a screen recording with a voice. "Let's follow one of your invoices from the moment it arrives" is a narrative the buyer can follow and remember.
• Make it theirs. Use their terminology, their scenario, and, where possible, data that looks like theirs. A demo in the buyer's own language feels built for them, because it effectively was.
• Handle the hard question honestly. When someone asks whether it does X and it does not, say so plainly (Lesson 1's honesty), then pivot to how the real need is met. Never bluff a technical audience; they can tell, and one caught bluff poisons the whole demo.
• When something breaks, stay calm. Live demos fail. Composure in that moment is itself a credibility signal, it shows the buyer how you will behave when their production system has a problem. Panic tells them the opposite.
• Watch the room and adapt. If the technical lead leans in at integrations, go deeper there. If the executive glazes over at detail, pull back to outcomes. The demo should follow the audience, not a fixed script.

The throughline of the whole lesson: the SE does not present the product, the SE presents the solution to a specific buyer's specific problem. Discovery finds the problem; qualification decides whether it is worth the effort; the demo proves the problem is solved. Do those three well and you have done the core of the job.

But a persuaded room is not always a closed deal. Serious buyers want to verify the claims themselves, which is where the proof of concept begins, the subject of Lesson 3.

Put the core presales craft together.

The unifying idea is worth restating because it is the whole mindset: understand deeply, then show precisely. Every hour spent understanding the buyer makes the demo shorter, sharper, and more convincing. Every shortcut in discovery makes the demo longer, vaguer, and weaker. The effort is front-loaded on purpose.

For a career switcher, this is also the most transferable and learnable part of the role. Discovery is disciplined curiosity and listening, skills you can practice anywhere. The demo is structured storytelling with honesty, also learnable. Neither requires being the deepest engineer; both reward the translation skill from Lesson 1.

And notice the connection to the SE's real product, credibility. A demo built from genuine discovery, delivered honestly, is itself an act of trust-building: it shows the buyer you listened, you understood, and you are showing them the truth rather than a rehearsed spectacle. That trust is what carries into the hardest part of the deal, when the buyer stops watching and starts testing, which is Lesson 3.

Business and technical discovery uncover and quantify the buyer's pain and constraints, which both qualify the deal via a framework like MEDDIC and supply the exact material for a targeted demo that proves the discovered pain is solved, rather than touring features.