Demo Differently: How Should a Software Demo for Scientists Be Structured?

What should a software demo look like for a scientific audience? I coach the application scientists and sales teams I work with on this. My approach was influenced by a Great Demo! workshop I took 20 years ago, when I was new to application science. Here are four things I focus on.

Start with their problem, not your company

In my experience, the first ten minutes matter most in the sales process. Don’t spend them on information the prospect already has. If someone agreed to the meeting, they have done their research. They know who you are, and they don’t need a company timeline or a slide of logos.

They need to see, straight away, that you understand their critical issue and the impact you can have on it. The most senior person in the room may have 15 minutes before her next meeting. If those minutes are spent on your founding story, she is gone before the demo starts. Send the corporate overview as a pre-read or put it at the back of the follow-up deck.

Do the discovery that makes the demo possible

Clients ask me what information they need to plan an impactful demo. As an application scientist, I needed to know what was keeping the customer awake at night. I also needed to know why it matters and what would change if it were solved. That is the impact your solution delivers and the value the customer will realise. It lets the demo show what changes once the problem is solved, not only what the software does.

You also need to know whether your champion has budget, authority and a timeline. Asking can feel uncomfortable, especially for technical salespeople who worry about intruding. Or the call turns into an interrogation, and the prospect shuts down.

What has worked for me is going into the call with a crib sheet of what I need, with space for notes. Let the customer direct the conversation, and probe deeper into what they say before moving to your next topic. Some answers surface naturally. For the rest, be direct. Explain why you are asking and why it helps them, then walk them through what comes next.

Show less

Restraint is one of the hardest things for an application scientist to learn. You know the product inside out, and you are proud of it, so there’s a big temptation to show everything. Show too much, and the message you needed them to hear gets lost. They leave unsure whether they saw the capability that mattered, and the software looks complicated.

If discovery has been done well, you know what to show. By focusing on the capabilities that address their critical issue, you show them that you listened. When other capabilities come up in Q&A, the right response is “Yes, we can do that. Would you like to see it?” Sometimes the answer is no. Knowing it is possible is enough. A focused demo also leaves time for their questions and for next steps.

End with a roadmap

Before anyone leaves the room, walk them through what comes next. “We’ll be in touch” is not enough. Describe the evaluation: what you will deliver, what you need from them, and what they can expect from you.

Be specific. Who should be on their evaluation team? What data or access do you need? What support and training will you provide during the evaluation? What feedback do you need, and by when? You already know their timeline from discovery. Familiarise them with yours, with the milestones.

A prospect who understands the process can resource it, involve the right people and move with confidence. A vendor who sets clear expectations avoids an evaluation that drifts or stalls. The demo may be the prospect’s first impression of your company. The roadmap shows that the partnership they glimpsed in the demo will continue through the evaluation.