Whenever I ask people how they currently run their demos, or whether they follow a certain demo approach, one answer comes up again and again:
Tell-Show-Tell.
And I have to give credit to my colleagues at Demo2Win. They did a great job of bringing Tell-Show-Tell into the world of software demos more than 25 years ago and making it one of the best-known approaches out there.
I am actually quite happy when customers tell me they already use it. Because at least it shows me that they have already spent some time thinking about how they demo.
The basic idea is simple:
- Tell your customer what you are about to show and why it matters.
- Show them how it works in the product.
- Then Tell them again what they have just seen and reinforce the key message.
That is definitely better than simply opening your product and clicking through a list of features.
The Problem with Tell-Show-Tell
The problem I see is that Tell-Show-Tell is not really a demo method. At most, I would call it a demo technique.
Because Tell-Show-Tell still does not tell you what is actually relevant for your customer.
It does not tell you how many features you should show. It does not tell you how many Tell-Show-Tell loops should be in your demo. It does not tell you which topics should come first, which ones should come later, or which ones you should leave out completely.
You can run a 60-minute demo with ten perfectly executed Tell-Show-Tell loops and still deliver a pretty bad demo.
You need something bigger around it.
Start with Prioritization
Before you think about how you present each part of your product, you first need to decide which customer challenges are actually important enough to deserve time in your demo.
That starts with prioritization.
If you learned about four or five different challenges during discovery, they should not automatically get equal airtime. You need to understand which ones matter most to your customer and then structure your demo accordingly.
Priority one goes first.
Your customer's biggest problem should not appear somewhere around minute 42 just because that is where the feature happens to sit in your normal demo flow.
The first ten minutes of your demo are especially important. You want your customer to feel very quickly that you understand them, that this demo is about their world and that you are going to focus on the things they actually care about.
If you manage that, there is a much better chance they will keep listening.
Revisit → Resolve → Result
For the individual sections of the demo, I prefer a structure I call:
Revisit → Resolve → Result
The idea is that every part of your demo should start with something you learned from your customer and end with the value they get from solving it.
Revisit
Before you show anything, go back to what your customer told you during discovery.
For example:
"You mentioned earlier that your sellers currently spend a lot of time manually updating your CRM. Because of that, they have less time to actually speak with customers and sell."
Ideally, you use the same words your customer used.
I call phrases like this Context Bridges.
They can be very simple:
- "Earlier, you mentioned..."
- "You shared that..."
- "Based on what you described..."
- "If I understood correctly..."
- "Going back to your point about..."
The purpose is simply to remind your customer why you are showing them the next thing.
You create a clear connection between discovery and demo.
Resolve
Now you show how your product solves that specific problem.
For example:
"What we can do here is automatically capture this information and write it back into your CRM, so your sellers don't have to do all of this manually. Let me show you."
Then you show the relevant part of the product.
This is the actual demo.
The important difference is that the feature now has context. You are not showing CRM automation because it happens to be one of your strongest features. You are showing it because your customer told you that manual CRM work is a problem for them.
Result
Once you have shown the solution, make the value explicit.
For example:
"What this means for you is that your sellers can spend 70% less time on admin work and use that time for actual customer conversations instead."
You can then go further if you have credible customer data:
"We have customers who were able to increase their pipeline by up to 40% without hiring additional salespeople, simply because their existing team had much more time to sell."
This is where I use what I call Value Bridges.
Again, these are very simple phrases:
- "What this means for you is..."
- "So your team can..."
- "This reduces..."
- "This helps you avoid..."
- "This enables you to..."
- "The impact for you is..."
Their job is to make the value obvious.
Because we often assume that customers will make that connection themselves.
They usually can.
But why make them work for it?
Your demo should reduce the mental effort required to understand why something matters.
If you show a feature and then leave it to your customer to translate that feature into business value, there is a good chance they will not make the same connection you had in mind.
That is why I like Revisit, Resolve, Result.
It almost forces you to stay close to what you learned from your customer.
You start with their problem.
You show how you solve it.
Then you explain what changes for them as a result.
And if you consistently use Context Bridges and Value Bridges, your customer always understands where you are in the story, why you are showing something and why they should care about it.
For me, that is also the main limitation of Tell-Show-Tell.
It gives you a nice structure for presenting something.
But it does not tell you whether you should be presenting that thing at all.
It does not help you prioritize your customer's challenges. It does not stop you from showing too much. And it does not automatically connect your product back to discovery and business value.
That is why I would not call Tell-Show-Tell a complete demo approach.
It is a useful technique. One of many.
But if all you do is repeat Tell-Show-Tell ten times in a row, you may still just be running a better-structured feature checklist.
What to Do Instead
For your next demo, I would start somewhere else.
Take everything you learned during discovery and identify the few challenges that matter most.
Put the biggest one first.
Then, for every part of the demo, use:
Revisit → Resolve → Result
Use a Context Bridge before you show anything.
Use a Value Bridge after you have shown it.
Your customer should never have to wonder:
Why are you showing me this?
or
Why should I care?
Make both answers as obvious as possible.
