The Demo: Show Value Without Overselling
A demo (short for "demonstration") is when you show your product to a potential customer. For a technical founder, this is the part that feels safe. You built the thing. You know every button. So it is tempting to open the app and start clicking.
That instinct is exactly the trap. The most common bad demo is a feature dump — clicking through every feature you are proud of, in the order they appear on the screen, while the prospect quietly checks their email. A good demo is the opposite. It is short, it is about them, and it is a conversation, not a tour.
The golden rule: discovery before demo (never demo blind)
"Discovery" means the questions you ask to learn the person's real problem before you show anything (Chapter 8 was all about this). "Demo blind" means demoing before you have done that — you have no idea what they care about, so you show everything and hope something sticks.
Sales coaches are blunt about this. Peter Cohan, author of the classic book Great Demo!, and the modern presales community both repeat the same line: never demo blind. If a prospect says "just show me the product," the move is a gentle redirect, not obedience.
Prospect: "Can you just walk me through the product?"
You: "Happy to — and I'll be quick. So I show you the parts that actually matter to you and don't waste your time on the rest, can I ask two fast questions about how you handle [their job] today?"
Tailor the demo to the pains you actually heard
Discovery gives you a short list of what this person is bleeding from. Your demo should show those exact things — and ideally nothing else. If they told you "approvals take forever and my reports are a mess," you show approvals and reports, in depth. You do not show the eight other features you love.
A simple, powerful trick: use their world inside the demo. Their company name. Their kind of data. The exact workflow they described. When a prospect sees their own situation on screen, they stop watching a product and start imagining their life with it.
Show the destination before the journey
Peter Cohan's most famous principle is "Do the Last Thing First." Most demos build up slowly — setup, then steps, then finally the payoff. Cohan flips it: show the finished, impressive result first (the "destination"), get the "wow," then show how easy it was to get there (the "journey").
Why? Because if people see the payoff first, they actually care about the steps. If you make them sit through the steps first, they tune out before the payoff arrives.
FEATURE-DUMP ORDER (weak):
step 1 -> step 2 -> step 3 -> ... -> [maybe a payoff?]
(prospect tunes out around here ^)
DESTINATION-FIRST ORDER (strong):
[THE WOW RESULT] -> "and here's how simple that was"
^ they lean in ^ now they care
"Here's the finished print-ready order, with the proof already approved and the artwork queued to production. That's the end state. Now let me show you — it took your customer about 40 seconds to get there. Watch."
Tell–Show–Tell: the structure for each thing you show
"Tell–Show–Tell" is a demo structure taught by 2Win! Global and many sales-engineering teams. For each capability, you do three small steps:
- Tell — say the value first: "You mentioned approvals are slow. Here's how this fixes that."
- Show — actually do it on screen, quickly.
- Tell — reinforce what they just saw, in value terms: "So that approval that took three emails just happened in one click."
Some teach it as Need–Show–Value — same idea, sharper labels. State the need, show the feature, name the value. The structure forces you to wrap every feature in a reason to care.
Demo outcomes, not features — the "so what?" test
A feature is what the product does ("it auto-saves every 30 seconds"). An outcome (or value) is what that means for the person ("you never lose work, even if your browser crashes mid-order"). Customers buy outcomes. They tolerate features.
Here is the cheapest quality check in all of selling. After every sentence in your demo, silently ask: "So what?" If you can't answer in terms of their pain, cut the sentence.
| Feature dump (weak) | Outcome-led (strong) |
|---|---|
| "It has real-time syncing." | "Your team always sees the same order status, so nobody prints the wrong version." |
| "We support role-based permissions." | "Your junior staff can take orders but can't change pricing — so no accidental discounts." |
| "There's a dashboard with 12 widgets." | "You said month-end reporting eats a day. This is that day, on one screen." |
Keep it short, and make it a dialogue
A demo should feel like a conversation, not a TED talk. If you talk for ten minutes straight, you have lost the room. Build in check-ins — small questions that keep them talking and tell you if you're on target.
• "Is that how you'd want it to work?"
• "Does this look like the problem you described?"
• "Want me to go deeper here, or move on?"
• "How does your current tool handle this part?"
Let them drive — and the difference between a demo and a trial
People believe what they touch. Where it's safe to do so, hand over control: "Here, you try adding a product — I'll guide you." This is far more convincing than watching you, because they feel how easy (or hard) it really is.
Two related but different things:
- Demo
- You (or you together) show the product live, usually in one session, focused on their pains.
- Trial
- They use the product themselves over days or weeks, in their own world. A trial is powerful but risky if they're left alone with no guidance — most people poke around, get stuck, and quietly give up. If you offer a trial, give them a tiny "first win" goal and check in. A demo should usually come before a trial, so they know what success looks like.
Handling "Can it do X?" — honestly, including saying no
Prospects will ask about features you don't have. The instinct is to fudge it ("um, sort of, kind of, we're working on it"). Don't. Vague answers read as a "no" wrapped in fear, and they cost you trust.
Yes: "Yes — let me show you." (Then show it. Never claim it without proof.)
Not yet: "No, not today. It's on our roadmap for next quarter. Is that a must-have for you, or a nice-to-have?" (Their answer is gold — it tells you if this is a dealbreaker.)
Never / not us: "No, that's not what we're built for — tools like [X] do that better. We're focused on [your core value]." (Saying no to the wrong fit builds enormous trust.)
Why overselling quietly destroys you later
Overselling — promising more than the product really does — feels like winning the deal. It is actually borrowing against your future. The customer signs up expecting the thing you implied, doesn't find it, feels lied to, and leaves. Research on customer trust is stark: a single broken promise drives churn in a large share of cases, and most consumers will switch after just one bad experience.
For a solo founder this is doubly dangerous. A churned, angry customer doesn't just leave — they tell others, leave a bad review, and ask for a refund. You spent effort to win a customer who now costs you. The honest "no" you avoided in the demo would have been free.
When something breaks live (it will)
Live demos crash, lag, or show a bug. As a technical founder, you might panic. Don't — how you handle it teaches the prospect more than the bug does. Stay calm, name it plainly, move on.
"Ha — there's a glitch on this screen, ignore that. It's the kind of thing I fix same-day, which is honestly one perk of working with a founder directly. Let me show you the part that matters." (Then continue. Don't over-apologize or disappear into debugging.)
Before / after: the same product, two demos
"So this is the dashboard. Up here are 12 widgets. This is settings — lots of options. Here's the product catalog, you can add unlimited products, tag them, bulk-edit. Over here is the design studio, it uses Fabric.js, super powerful. And we have an API, webhooks, role permissions, multi-currency…"
(Prospect: glazed over. "Looks… comprehensive. We'll think about it.")
"You said two things hurt: customers email you back and forth about proofs, and you lose a day every month on reports. Let me show you both.
First — here's a finished, customer-approved proof, no emails needed. [shows result] That whole back-and-forth? Gone. Your customer did it in under a minute. Want to try clicking approve yourself?
Second — your month-end report. [shows it] That's the day you described, on one screen. Is this the number you usually hand-build in a spreadsheet?"
(Prospect, leaning in: "Wait — can it also handle bulk orders?" Now you're in a conversation.)
Key takeaways
- Never demo blind. Discovery first — diagnose before you prescribe; tailor the demo to the 2–3 pains they actually named.
- Show the destination first ("do the last thing first"), then the journey — the wow earns their attention for the how.
- Use Tell–Show–Tell (or Need–Show–Value) and the "so what?" test, so every feature is wrapped in an outcome they care about.
- Make it a short dialogue, not a monologue — check in every ~90 seconds and let them drive when you can.
- Answer "can it do X?" honestly, including "not yet" and "that's not us" — a clean no builds more trust than a fuzzy yes.
- Don't oversell. One broken promise drives churn and refunds; under-promise, over-deliver, and let kept customers compound.
- When it breaks live, stay calm, name it, skip it, follow up — your composure sells more than the feature would have.