Why this is its own chapter
The demo is the visible artifact of the SA role. It's the thing people outside the function think the role is mostly about. It isn't, but it's important enough — and specific enough as a craft — to deserve its own chapter.
There are good books on demo construction. I won't try to replicate them. What I want to do here is talk about the parts of demo work that are usually undertaught — the performance dimension, the tactical hygiene, the situations that aren't covered in standard demo guidance. The mechanics of "what slides to use" or "how to structure a feature walkthrough" are well covered elsewhere. What follows is the rest of it.
The introduction is the first thirty seconds
The first thirty seconds of any demo set the tone for everything that follows. If you fumble the open — uncertain about who you are, why you're there, what you're about to show — the rest of the meeting is uphill. If the open is clean and grounded, the room settles and you have everyone's attention for the actual work.
The fix is unglamorous: practice your introduction. Out loud. Enough times that it sounds natural, not memorized. There's a real difference. Memorized sounds like you're delivering a wedding toast you wrote on the way over. Natural sounds like you've thought about what you're doing, which you have. Twenty to thirty seconds, covering who you are, what your role is, why you're in the meeting, and what you're going to do for the next however many minutes. That's it. Most SAs don't practice this and it shows. The ones who do practice come across as more senior, even when they aren't, because the open feels prepared.
The other thing the introduction does is set the meeting structure. Telling the user, in the open, "I'm planning to spend about twenty minutes walking through the core flow, then leave time for your questions and a deeper dive on whichever parts are most relevant" gives the meeting a shape. The user knows what to expect. They know when their questions fit. The meeting becomes legible.
A note on overshadowing: unless it's necessary, don't overshadow your teammates in the introduction. If the AE has set up the meeting and is leading the open, your introduction is a complement to theirs, not a replacement. The wrong move is to step on the AE's flow because you're more comfortable in the technical seat. The right move is to do your own clean, brief intro that fits cleanly into the meeting they're running.
Find your persona
The performance frame from Chapter 2 has a tactical implication worth naming directly: you need a persona. Not a fake one — a real version of yourself that you've decided on, that you can step into when the meeting starts, and that's consistent enough that you stop having to think about how you're showing up.
The persona is yours to design. Mine, for years, was that uncle at Thanksgiving who may have had a few. A little casual. Shirt untucked. Arm over the back of the chair. Informal in a way that put the room at ease — but who happened to be pretty knowledgeable in the topic at hand. That worked because it was honestly close to who I am, and because the casual frame let the prep work land naturally rather than feeling like I was performing expertise.
Yours doesn't have to be casual. It can be precise and a little formal. It can be warm and curious. It can be quietly authoritative. It just has to be a version of you that's stable, that you can repeat, and that you find genuinely comfortable. The wrong move is to copy someone else's persona that doesn't fit you. The user can tell.
The reason the persona matters is cognitive, not aesthetic. When you've decided in advance how you're going to show up, you save the in-meeting bandwidth for actually thinking. You're not asking yourself "should I be funny right now?" while trying to answer a hard technical question. The persona is the wrapper. The wrapper lets the contents flow.
Find yours. Practice it. Let it evolve as you grow. Don't show up cold, deciding in real time who you are.
Pace is your most underused tool
When a demo is going well, the temptation is to keep going — to keep showing things, keep demonstrating capability, keep proving how much your platform can do. This is almost always a mistake.
The right pace in a demo is slower than your instinct. Slower than feels natural. Slower than the user is asking for, sometimes. The reason is that the user is processing, and processing is the bottleneck. You can show them three things in five minutes and they'll remember one of them, badly. You can show them one thing in five minutes and they'll remember it well, and they'll have time to ask the question that turns into the actual decision-making conversation.
A few mechanics that help.
Pause after a key point. Three seconds of silence after you've shown the most important thing in a section feels like an eternity to you and registers as confidence to the user. The pause gives them time to absorb and to ask a question if they have one.
Pick up a pen. This is a trick I learned and have used hundreds of times. When the meeting is moving too fast — questions stacking up, the user getting ahead of you, your own brain starting to chase — pick up a real pen and start taking notes. Real or fictional notes, it doesn't matter. The act of picking up the pen breaks the rhythm of the meeting. The room takes a breath. You take a breath. The pace resets. Try it. It works.
Let silence do the work. When a user asks a question, don't rush to answer. A two-second pause before answering reads as thoughtful, not slow. It also gives you a moment to actually think about whether the easy answer is the right answer.
Recovery, not perfection
You are going to have bad calls. Not occasionally. Regularly. You will demo something and have it fail in a way it has never failed in rehearsal and will never fail again. You will draw a blank on a question you absolutely know the answer to. You will say something that turns out to be wrong and have to come back to it. You will lose your place in your own demo flow and have to find it again with the user watching. The product gods are watching. This is part of the job.
These things happen to senior SAs who have been doing the job for a decade. The performance isn't ruined by the mistake; it's ruined by the panic afterward. What separates the SAs who recover well from the ones who don't is the habit of treating the mistake as a non-event.
The move is always the same. Name the thing, take it offline if needed, move on.
"I want to make sure I give you the right answer on that — let me follow up after the call."
"That's odd, the demo's not behaving the way I expected. Let me note that and we can come back to it; in the meantime let me show you the next part."
"That's a good question and I'm not actually sure off the top of my head. I'd rather get you a precise answer than guess — let me get back to you within a day."
These sentences cost nothing. They preserve the relationship and the meeting. The user almost always forgets the moment within five minutes. What they remember is whether you were rattled. If you weren't, the call lands fine.
The mistake to avoid is the over-apology. "I'm so sorry, I really should have known that, this is embarrassing, I'll definitely get back to you on that." That spiral is worse than the original moment. The user becomes uncomfortable, the meeting loses its rhythm, and you've signaled that small mistakes are a big deal — which makes the next one bigger.
The alpha nerd
Occasionally — not often, but occasionally — you'll get a user who is going to test every angle of your knowledge. The technical lead who asks rapid-fire detailed questions designed to probe whether you actually know what you're talking about. The architect who has read every page of your docs and wants to discuss inconsistencies. The senior engineer who clearly already has strong opinions about your platform and is looking for confirmation that you know the platform as well as they do.
These users are not adversaries, even when the dynamic feels adversarial. The good news is that once won over, alpha nerds become the most valuable champions you can have — they go to bat for you internally in ways no one else can. The bad news is that the path to winning them over is admitting what you don't know, which is the opposite of what your nervous system is telling you to do in the moment.
Don't stress about it. Don't try to match their pace if you can't. It's okay to say "I don't actually know the answer to that off the top of my head — let me come back with something specific." It's okay to say "that's deeper than I'm going to be able to go in real time, let me get a product person on the next call who can answer that better." It's okay to be the SA in the room without being the deepest expert in the room on every question.
What's not okay is faking it. If you bluff in front of an alpha nerd and they catch you — and they will — you've lost not just their trust on that question but their trust on the deal. Whereas if you say "I don't know" the first time it comes up, and then come back with a clean answer next call, you've demonstrated something more useful than encyclopedic knowledge: you've demonstrated reliability.
The general principle: knowing a lot of things is great, and reminding people you're a human is also great. "I don't know" is not just allowed — used well, it's one of the most relationship-building things you can say.
Sell what's on the truck
We'll come back to this in Chapter 10 because it deserves its own treatment, but it shows up in demo work too. The demo should show what your platform actually does today, in production, that the user can use. Not what's coming next quarter. Not what's in beta with a few customers. Not what's on the architectural diagram for the redesigned version.
You can mention the future when it's relevant. You can say "we're working on this and we expect it in a couple of quarters" if there's a reason the user needs to know. What you should not do is build the demo around future capability and let the user form their impression of your platform based on what isn't shipped. They'll remember the impression. They'll be frustrated when they get the actual product.
Some betas are tempting to demo because they're impressive and you've gotten access to them. Be cautious. Especially be cautious with timeline. Software ships when it ships, and your read of the timeline is rarely as accurate as it feels. Promise less, deliver more. The other way around poisons the relationship.
Start at the beginning, not in the middle
The other tempting failure mode in demos is to skip the basics and jump straight into the interesting part. The user is sophisticated, you've already had two calls, the AE wants to keep the meeting tight — so you skip the platform overview and dive into the specific scoping question.
This is sometimes the right call. More often it isn't, and the reason it isn't is that the user's mental model of your platform is less complete than you think it is. Even sophisticated users, even users who've read the docs, have gaps in how the pieces fit together. If you skip the basics, you're solving a specific problem on top of a fuzzy foundation, and the resulting solution is often confusing in ways that aren't obvious in the moment.
The right move is to start with the foundation, briefly, and let the user guide the level of detail from there. "Quick recap of how the platform fits together, and then I'll go deep on the marketplace flow we discussed last time." The recap takes maybe three minutes. It anchors everyone. The user who already knows the foundation patiently nods through it and is grateful you didn't skip it for the new person on the call. The user who didn't quite have the foundation finally gets it.
If the room genuinely doesn't need the recap, they'll tell you. "We're good on the basics, can you go straight to the marketplace flow?" That's the room granting you permission. Take it. But don't grant yourself the permission unilaterally; the cost of being wrong is higher than the cost of three minutes of recap.
Stay curious
A pattern I've watched undermine more demos than any other: the SA who's done this enough times to think they already know what the user needs. The first five minutes of the meeting tell them everything, they figure out the answer, and they spend the rest of the meeting confirming their initial read.
This is recognition without curiosity, and it's a real failure mode that comes with experience. You'll get good at identifying solution patterns. You'll have something figured out in the first five minutes of a call. You might be right. You also might be missing the thing that would have changed your read entirely if you'd kept asking.
The discipline is to stay curious even when you think you know. Ask the next question. Ask the question after that. Pay attention to the things that don't quite fit your initial pattern — those are usually the most important signals. The "experience barrel of snakes" is the thing that bites you when you stop being curious because you've decided you already know what you're looking at.
A note for builders
The biggest leverage point for demo quality, in a function, is rehearsal — and almost no SA team does enough of it.
Demos are practiced individually, in the moment, in front of the user. There's almost never a structured forum for SAs to give demos to other SAs, get feedback, and refine. The result is that everyone develops their own version of the demo, with their own strengths and quirks, with no shared standard for what good looks like.
A weekly demo-clinic — even thirty minutes — where one SA gives a demo to the rest of the team and gets honest feedback, changes the trajectory of the whole function. Skills transfer. Common rough edges get sanded. New SAs ramp faster because they see what good looks like rather than having to invent it. The pattern compounds over a year.
The reason it doesn't happen by default is that everyone is busy and rehearsal isn't urgent. Make it a calendar standing item. Protect it. The investment pays back, but only if you actually run it.