John Spooner

Playbook

Demonstrations: Show the customer their problem being solved

A demo should prove that a product can solve this customer's problem, not walk them through a feature catalogue. I build demonstrations around the customer journey, stakeholder concerns and the specific outcomes that need to become believable.

  • Technical Sales
  • Communication

In this playbook

  1. How do I decide what actually deserves to be shown?
  2. How do I make one demonstration relevant to different stakeholders in the room?
  3. How do I keep discovering while I demonstrate?

A demo is not a product tour. It is a deliberately constructed argument that your product can solve this customer's problem.

The prospect should leave having seen that happen — not being asked to imagine what might work after enough configuration.

Generic demos put too much work on the prospect.

They show menus, features and possibilities, then ask the customer to mentally translate all of that into their own environment and use case.

That is closer to product onboarding than technical sales.

A bad demo doesn't understand the problem it claims to solve. It asks the prospect to fill gaps with imagination and promises: “We don't have it configured that way here, but it can do it.”

If nobody is engaging, questioning or relating what they see back to their own situation, something has gone wrong.

Do

Make the important part visible in the customer's own context.

Avoid

Show a generic product tour and ask the customer to imagine how it might apply to them.

Everything is excluded by default.

Every feature, flow and technical detail shown needs a reason to be there.

Before the demo I want to understand:

  • What problem are we trying to solve?
  • How does the current journey work?
  • Why are they considering changing it?
  • Who will be in the room?
  • What does each stakeholder care about?
  • What alternatives are they considering?
  • Where are we genuinely stronger — and weaker?

Then I build the demonstration around that context.

The customer knows their problem. I know the product. My job is to connect the two.

That doesn't mean blindly showing exactly what they requested. Sometimes the best part of the demo is something they didn't know to ask for. If I introduce it, I should be able to explain precisely why it matters based on what I've learned about them.

  1. Understand the context

    Research the company, but prioritise the actual business case over corporate slogans.

    Understand the customer journey, current solution, pain points, buying motivation and competition.

    Company strategy can still be useful context — particularly if it helps your champion explain internally how the solution supports a wider initiative.

  2. Understand the room

    Know who is attending and what each person cares about.

    A security lead, architect and CX owner may watch the same flow for completely different reasons.

    You don't need three separate demos. You need to know which moments matter to whom.

    If Kathy owns security, address the security implications directly with Kathy.

    If Joe owns CX, ask him whether the flow you just demonstrated actually works for the customers he described.

  3. Decide what deserves to be shown

    Build a story around the customer's problem.

    Choose:

    • The journey you will demonstrate
    • The capabilities required to tell that story
    • Where your differentiation matters
    • What you deliberately won't show
    • What assumptions you need to validate during the meeting

    More features do not make a stronger demo.

    Relevance does.

    Preparation should also be proportional to the opportunity. A major enterprise deal may justify custom environments, integrations, branded pages or bespoke flows. A speculative low-value opportunity may not.

    Never waste SE resources — but never give a completely irrelevant demo because preparation was inconvenient.

    Do

    Show only what helps the customer understand the solution or advance their decision.

    Avoid

    Add features simply because they are impressive, available or easy to demonstrate.

  4. Demonstrate and keep discovering

    A demo is another discovery call with a product running in the middle of it.

    Ask questions. Validate what you think you know. Adjust the flow when you learn something new.

    Customer questions are particularly valuable because the question itself often matters less than the reason behind it.

    “Can you store recordings on-prem?” could really mean:

    • Will this fit our infrastructure?
    • Is this GDPR compliant?
    • Can our CX team easily use recordings for training?

    If you don't understand the why, you can give a technically correct answer that completely misses the concern.

    Do

    Understand the concern behind the question before deciding what answer the customer actually needs.

    Avoid

    Stop at the literal technical answer when the real concern is architectural, operational or commercial.

    For individual sections, Tell → Show → Tell is a useful discipline:

    Tell: Connect what you're about to demonstrate to the problem.

    Show: Demonstrate the outcome without narrating every click.

    Tell: Reinforce what changed and why it matters.

    It isn't a script. Good demos should still feel like conversations.

  5. Finish with discussion, not applause

    The demo ending doesn't mean discovery is over.

    Ask stakeholders directly what they thought using questions that demand more than yes or no.

    What worked? What didn't? Did it address the issue they raised earlier? What would stop this working in their environment?

    Anything you couldn't answer becomes follow-up work — a technical check, short video, configuration change or next-step discussion.

    The goal is to leave the meeting knowing more about the deal than when you entered it.

I have repeatedly built demonstrations around specific customer journeys rather than generic product environments.

That sometimes meant creating bespoke technical implementations. More importantly, it led me to build reusable demo infrastructure so that the work required to produce relevant demonstrations could scale across the wider sales team.

I have also used deliberately unusual demonstrations — such as Nigel the Coding Butler — where the commercial objective was different. In that case, the first job was to make a technically complex capability immediately obvious and memorable before explaining how it worked.

The presentation changes. The principle doesn't:

Know what you want the audience to understand, then build the demonstration that makes it easiest for them to understand it.

For significant opportunities, I plan the customer journey, stakeholder concerns, differentiation and intended story before configuring the demo.

I built reusable demo infrastructure so that bespoke work created for one opportunity could become available to the wider commercial team.

I have also trained commercial teams on preparing and delivering effective demonstrations, including stakeholder mapping, competitive positioning, interactive delivery and Tell–Show–Tell.

  • A demo is not a product tour. Build a deliberate argument that this customer's problem can be solved, and never ask them to imagine the part that matters.

  • Everything is excluded by default. Relevance beats breadth; every feature and technical detail shown should earn its place.

  • A demo is still discovery. Understand the concern behind the question, validate assumptions as you go and leave knowing more about the deal than when you entered it.