Key Takeaways

• Demos that move deals are tailored to one buyer and show the value they get, while feature walkthroughs get watched and forgotten.
• Simon Harvey of Demodia builds every demo on five beats: situation, problem, offer, rallying point and transformation. The story starts at the problem.
• Waystar builds clinical demos around one realistic patient, so the data itself tells the buyer what the problem is.
• Story-first interactive demos run about 20 to 25 clicks, while feature tours tend to lose viewers around the 23rd screen.
• AI now writes the first draft of a demo story from discovery notes, which turns the presales team into editors rather than writers.
• The single habit all three speakers would drop tomorrow: showing one more feature.

On November 4, Walnut and Demodia hosted a 45-minute conversation called “From product tour to buyer story: How to make demos that move deals forward.” It brought together three people who spend their working lives inside demos. Simon Harvey is CEO of Demodia and spent years in presales, technical marketing and product marketing. David Bordewyk is a Clinical Solutions Strategist at Waystar, where he demos revenue cycle software to hospitals and health systems. Brian Fogg is Head of Customer Experience at Walnut, where he leads presales, sales and customer success and sees a huge range of customer demos.

The question they set out to answer is simple to ask and hard to live by. Why do some demos move deals forward while most just get watched?

This post walks through the session in the order it happened, with the ideas worth stealing. If you would rather hear it from them, watch the full recording.

What Separates a Demo That Moves Deals from One That Just Gets Watched?

Simon opened by asking Brian exactly that. Brian sees more demos than almost anyone, across presales, sales and customer success, and his answer set the tone for the hour.

The demos that move deals are tailored to the customer and show the value they are looking for. The ones that stall turn into a tour of features. “That doesn’t really speak to what a customer is looking for,” Brian said. “They want to see the value. Why should I buy this software? What am I going to get from this?”

Everything that followed was, in one way or another, about closing the gap between those two kinds of demo.

The Four-Pint Rule: Why Feature Overload Kills Demos

Before the panel discussion, Simon took two minutes to explain how he thinks about demo structure. He started with beer.

In the UK, he explained, a pint is a proper pint. It takes a full hand to hold. Every key feature you show in a demo is one of those pints, and the buyer has to carry it across the bar and drink it to remember what they saw. One pint is easy. Two is fine. Three, and most people start to spill.

At four, something worse happens. People do not just forget the fourth feature. When the first glass slips, the whole lot goes on the floor. The buyer leaves confused and remembers almost nothing.

Jargon makes it worse. Simon compared technical terms and deep-dive detail to washing-up liquid smeared on the glass. The buyer is probably seeing your product for the first time, and every unfamiliar term makes the pints harder to hold. His advice: keep it slim and show only what really matters.

The SPORT Framework for Demo Storytelling

Simon then shared the framework he uses with every customer he builds interactive demos for. It has five stages, and he gave it a name that is easy to remember: SPORT.

• Situation. Introduce who the demo is about and what they want. A finance lead who wants to see days sales outstanding at a glance, for example.
• Problem. Introduce what stands in their way. This is where the story really begins, and Simon was emphatic that it has to come early. “The problem is the story.”
• Offer. Show what the customer gets, with the customer as the hero, not your product. Even the labels and calls to action in an interactive demo should speak from the buyer’s side.
• Rallying point. Give the hero a clear next step. Many viewers never reach the end of a demo, so Simon now places a decision point partway through as well. Without one, “heroes never act.”
• Transformation. Show what changes for the buyer, and what the cost is of staying with the legacy process.

Build one master story around the main problem your product solves, Simon said, and you can tie every smaller use-case demo back to it.

How Waystar Moved from Features to Story

Simon asked David when his team decided feature demos were not working. David has been in demo roles for close to 15 years, and his honest answer was that it happened gradually, then quickly. The big shift came when the technology let them represent the story properly. Moving to Walnut as the basis for their demos gave them room “to lift from really focusing on feature to building a better story.”

His process starts before the demo exists. When a new product launches, he begins with what product management and product marketing learned in discovery. Who is the focus? What is the end value? What transformation are we trying to achieve? Only then does he decide which features best illustrate that value.

Waystar sells to hospitals, health systems and ambulatory practices, so the hero of the story is often a patient. “We need that patient story to be accurate,” David said. Someone in the room will be watching the clinical detail closely, and if a lab trend or a date is off, they will notice.

So every demo follows one realistic patient, with trends, results, dates and provider notes that all line up. Simon picked up on why this matters so much: a well-built profile becomes the script. The data tells the buyer what the problem is before anyone explains it.

David added something presenters rarely admit. Data that looks wrong does not only distract the buyer. It throws the presenter, who starts excusing it with “it’s just demo data” and loses the thread of the story.

How Do You Decide What to Leave Out of a Demo?

Simon called it the curse of knowledge. When you know a product inside out, you want to show everyone that you do, and pruning feels like losing something.

David’s answer was to go back to discovery. Know the 80/20 of what this buyer needs to see to understand the value, and adjust to the situation. A few minutes with an executive at a conference looks very different from a third session with end users who want depth. “There’s a discipline you have to learn,” he said, about picking what really matters and going to detail only when it is needed.

An attendee offered an analogy in the chat that the panel loved: if the client asks for a fork, do not show them the whole kitchen set.

How Do You Know If a Demo Story Worked?

David’s first answer got a laugh: “We get a contract.”

His serious answer was about signals during the call. He loves being interrupted. Questions tell him where to slow down, where to go back and where the story did not land, and he wants the flexibility in his demo flow to respond. A quiet room is the warning sign.

Brian answered from the data side. Across Walnut customers, the demos that engage are the tailored ones, where the customer, the data and the value hold together from screen to screen. The ones that lose people follow a familiar pattern: “click the next button, here you can see this feature.” In Brian’s words, viewers “make it through like 23 screens and then they drop off, because they don’t want to know the feature function.”

Branching: Let the Buyer Choose the Path

Simon asked Brian for tips on keeping people engaged in an interactive demo when there is no presenter to help.

Brian’s team uses branching. At a key moment, the demo asks the viewer what matters most and offers two or three paths based on what came up in discovery. Not ten. Two or three. “It is showing them, here’s what you asked for, now we’re demonstrating it.” It turns “click, next, next” into something the buyer actually participates in.

The Mistake Teams Make When They Add Story to an Old Demo

Simon audits a lot of interactive website demos, and he often finds teams who believe they have moved to storytelling. Then he looks closer. The demo is still 50 screens long, still covers every feature, and is really the same harbor tour with a new opening slide.

Brian named the most common version of this. A team takes an existing long demo and pastes a story into it without rethinking what each screen and tooltip was built to show. The result has no through line. “The screens don’t match up with the story and the story doesn’t really show a value.”

His fix: if you reuse an older template, go back and watch the whole flow, then make sure the story you are telling matches the screens you are using.

How AI Is Changing Demo Storytelling

All three speakers described the same shift. Building a story used to mean writing it from scratch, often in a spreadsheet of made-up patients or customers. Now, as David put it, you get to be “more of an editor” than a creative writer.

Brian walked through his own workflow. He gives an AI assistant the persona and what came out of discovery, and asks for a value-based story built around that persona. Then he opens Walnut‘s AI Mode, gives it the story and the screens, and has it align every step so the demo points at the right things and speaks to that persona.

Simon has seen customers go further: feed an existing demo, the SPORT framework and a description of the ideal customer into an AI model, and ask which problem to introduce and which four or five clicks prove the solution. “It does a damn good job these days,” he said.

David raised a challenge that is specific to selling AI products. When the product’s value happens behind the scenes, a spinner on screen does not show the buyer much. The demo still has to make visible what the AI did and why it matters, which is a storytelling problem rather than a feature problem.

Leave-Behinds, Recordings and the Two-Minute Rule

Near the end, Simon shared a story from a sales leader who said he knew a deal was won if anyone other than the people in the room watched more than two minutes of the recorded call. Brian has wondered the same thing every time a buyer asks for the 45-minute recording.

His advice for anything a buyer views alone: shorter, clearer, and written for someone who was not on the call, because it will get forwarded. We went deeper on that idea in a separate post on building the leave-behind demo.

When Simon asked for the ideal length, Brian gave Walnut’s internal guideline: 20 to 25 clicks, counted as clicks rather than screens, or about two to three minutes for the viewer.

Who Should Own Your Demos?

An audience question asked who should be in charge of building and maintaining demos. Brian admitted it is often a heated topic. Marketing wants it, sales wants it, and solutions consultants, by their own admission, can be control freaks about it.

His answer was to let subject matter experts lead, whichever team they sit in, and iterate from there. David added that the people who present a demo repeatedly should have the final say, because presenting someone else’s demo is like presenting someone else’s slide deck. When experts build the story once and reps can reuse it, the whole team tells the same story. That is the idea behind having SEs author once while everyone else reuses.

The One Thing to Stop Doing Tomorrow

Simon closed by asking each speaker for one thing people should stop doing in their demos.

David’s answer: resist the urge to show one more thing. “Show that and stop, and if they have questions they’ll ask or they’ll come back.” He framed it as respect. The buyer gave you their time in discovery, so show them what they said mattered and let them get to their next meeting.

Brian’s final word was even shorter: “Value, value, value, value, value.”

Simon summed up the hour in one line. A demo should tell the customer’s story, not the story of your product. Start with a problem they care about, show only what proves the answer, and keep it short enough to remember.

Frequently Asked Questions

What is the SPORT framework for demos?

SPORT is a demo storytelling framework shared by Simon Harvey of Demodia. It stands for situation, problem, offer, rallying point and transformation. You introduce the buyer and what they want, present the problem in their way, show what they get with the buyer as the hero, give them a clear next step, and finish with what changes for them.

How many features should a product demo show?

Two key areas is a safe limit, and three at most. Showing four or more tends to overwhelm buyers to the point where they remember very little of the demo, not just the extra features. Choose the areas that prove value for the specific buyer and save the rest for later conversations.

How long should an interactive demo be?

Walnut’s internal guideline is 20 to 25 clicks, which takes a viewer about two to three minutes. Short use-case demos for a single persona can be as brief as 5 to 10 clicks. Feature-led demos commonly lose viewers after about 20 screens.

How do you make demo data realistic?

Build the demo around one consistent customer or persona and make sure every value, date and record lines up across every screen. Teams like Waystar build a complete, realistic profile first, often with AI help, and then use it throughout the demo so the data itself explains the buyer’s problem.

Can AI write a demo story?

AI can draft a strong first version of a demo story from discovery notes and a persona description, and can suggest which problem to lead with and which steps prove the solution. People still need to judge which problem matters to a given buyer and check that the story, screens and data match.

Where can I watch the From Product Tour to Buyer Story webinar?

The full recording of the November 2026 webinar with Demodia, Waystar and Walnut is available on demand. Watch the recording here.

Watch the Full Conversation

This recap covers the main ideas, but the session is full of examples that are better heard than read, especially David’s walk-through of building clinical demo stories. Watch the full recording with Simon, David and Brian.

Ready to build demos around your buyer’s story? Start for free with Walnut.