FDE Track 06~11 min readFoundational
The Performance
A demo is a performance,
not a code review.
You can build the perfect solution and still lose the room in five minutes with a bad demo. The demo is where an FDE’s weeks of work either become obvious value or die in a settings screen. It’s a skill — prepared, structured, and rehearsed — not a personality trait.
01
Why the demo decides everything
Engineers underrate demos because they assume good work speaks for itself. It doesn’t. A demo is the compression of weeks of effort into a few minutes of perception, and perception is what the customer acts on. The same solution can read as “transformative” or “meh” depending entirely on how it’s shown. That’s not unfair — it’s just that value the customer can’t see isn’t value to them yet.
So the reframe is uncomfortable but freeing: a demo is a performance. Not in the sense of faking — you’re showing something real — but in the sense that it’s staged, rehearsed, and directed toward a reaction. Treat it with the seriousness of a performance and it becomes a repeatable skill instead of a nerve-wracking gamble.
02
Before: prep is 80% of it
A great demo is mostly won before it starts. The five preparations below prevent almost every way a demo goes wrong.
Their dataNothing lands like a customer seeing their own records flow through. Load it in advance — sample data reads as a toy.
RehearseRun the exact click-path three times. Muscle memory frees you to talk instead of hunt for the next button.
FallbackRecord a screen capture of the happy path. If live breaks, you cut to it — no scramble.
Kill noiseClose Slack and mail, silence notifications, hide bookmarks, go full-screen, bump the font size.
Know the roomDecide the first two minutes for this audience before you start.
Notice that four of the five have nothing to do with the software. They’re about removing everything that could distract from — or derail — the one moment you want the customer to feel. The full pre-flight list lives in the demo checklist.
03
During: structure the story
A demo has an arc. Skip the arc and you get a feature tour — “here’s a button, here’s another button” — which is forgettable. Follow it and the customer experiences a small, satisfying story that ends on the value.
| Beat | What to do | Why |
|---|
| Open with the problem | Restate their pain in their words before showing anything | Anchors everything to what they care about |
| Show, then explain | Do the impressive thing first; explain how second | The result earns their attention; the mechanism keeps it |
| Narrate the “so what” | After each step: “which means you save X / catch Y earlier” | Translates features into value they feel |
| Slow down on the wow | Pause after the key moment; let it land; don’t talk over it | Rushing past the payoff wastes it |
| End on the wow | Finish on your strongest capability, not a config screen | People remember the last thing they saw |
The most-missed beat is the so what. Engineers narrate what the system is doing (“now it’s embedding the documents”) when the customer needs to hear why it matters (“which means it finds the right clause in seconds, not the afternoon it takes today”). Same action, completely different demo.
It will, eventually — a timeout, a stale token, a wifi hiccup. The failure itself rarely loses the room; how you handle it does. Panic, over-apology, and live debugging turn a small glitch into the story of the meeting. Composure turns it into a footnote.
→ The three rules
Stay calm. One light acknowledgment, not five apologies. Cut to the recording. That’s exactly why you made it — keep the momentum. Never debug live. Note it, move on, follow up. Debugging on stage says “this isn’t ready”; a smooth recovery says “this person is unflappable.”
There’s a quiet upside here: handling a live failure gracefully often builds more trust than a flawless run, because the customer sees how you’d behave when something goes wrong in production — which it will. Your calm is part of the product.
The same solution needs three different openings depending on who’s watching. Get the first two minutes right for the actual audience and you have their attention for the rest.
The executive
- Wants the outcome and the ROI, fast.
- Lead with the business result, not the architecture.
- “This cuts a two-day process to ten minutes.”
The technical / IT stakeholder
- Wants the how, the integration, and the risks.
- Show the architecture; answer the security question before it’s asked.
- “It runs in your VPC; nothing leaves your network.”
The end user
- Wants their own day to get easier.
- Show the exact workflow they do daily — but faster.
- “No more copy-pasting between five tabs.”
Usually all three are in the room at once. The move is to speak to each in turn — a sentence of ROI for the exec, a sentence of architecture for IT, a workflow moment for the user — so everyone hears the part that matters to them.
The demo isn’t over when you stop sharing your screen. Three moves convert a good reaction into forward motion.
First, lock in a next step before you leave the call — “by Friday we’ll wire in the second data source and show you the full flow.” A demo with no agreed next step is a dead end, no matter how well it went. Second, send a same-day recap while the reaction is warm: what they saw, the value it delivers, and the next step you agreed. Third, capture every “can it also…” — each one is a signal about the real need and a scoping input for the next iteration, not a promise you have to make on the spot.
Do this consistently and demos stop being isolated events and become the heartbeat of the deployment — each one advancing the work, surfacing the next requirement, and deepening the customer’s belief. Which loops right back to discovery: the best “can it also…” questions are just discovery for what you build next.
Frequently asked
Quick answers
How do you give a good product demo?
Treat it as a story, not a feature tour. Open with the customer’s own problem in their words, use their real data, show the impressive result before explaining how it works, and narrate the "so what" after each step. Rehearse the exact click-path, kill notifications, and have a screen-recording fallback in case the live version breaks. End on your strongest capability and a concrete next step.
What do you do when a demo breaks live?
Stay calm and keep moving. Don’t apologize repeatedly or start debugging on stage — that kills the story. Say “let me show you this a different way” and cut to a pre-recorded screen capture of the happy path, which is exactly why you prepared one. Note the failure, move on, and follow up afterward. Composure under a live failure often impresses more than a flawless run.
How do you tailor a demo to the audience?
Match the first two minutes to who’s in the room. Executives want the outcome and ROI — lead with the business result. Technical stakeholders (IT, security) want the how and the integration — show the architecture and answer the risk questions. End users want their day to get easier — show the workflow they do every day, faster. Often you have all three in the room, so speak to each in turn.
What should you do after a demo?
Lock in a concrete next step before you leave the call — a demo with no next step is a dead end. Send a same-day recap while it’s fresh: what they saw, the value, and the agreed next step. And capture every "can it also…" they raised — each one is a scoping input for the next iteration, not a promise.