John Spooner

Case Study

Product Education: Explaining a complex product at scale

I turned recurring customer questions into product education, writing the scripts, presenting on camera and directing the technical story.

  • Communication
  • Technical Sales
Featured Video

Surfly was a technically unusual product, and some of its most important capabilities were not easy to explain with feature copy alone. Prospects often needed more context before they could understand why things like universal co-browsing, compliance controls or white-labelling mattered.

I saw an opportunity to turn the explanations I was already giving repeatedly in sales conversations into something more useful on the website.

I chose the topics, wrote the scripts and presented four professionally produced product videos. Where a technical explanation depended on a particular diagram or visual, I also supplied mock-ups and directed what needed to appear on screen.

The topics came directly from the questions I spent the most time answering in sales conversations: deployment, compliance, trusted branding and what “universal co-browsing” actually meant.

Video was already a big part of how I worked. If something complicated needed to be explained asynchronously, I usually preferred a short recording to a long email. For specific deals, though, bespoke recordings were often more useful than generic material.

  • Topic selection based on recurring sales conversations
  • Scriptwriting and on-camera delivery
  • Technical direction for diagrams and supporting visuals

The aim was not to explain everything Surfly could do. It was to explain the things prospects most needed to understand.

Surfly had plenty of technical depth, so the challenge was deciding which explanations were worth turning into reusable content.

I based the topics on the conversations I was having most often with prospects and workshopped them with the wider sales team. The aim was not to create technical documentation. These were website videos for people trying to understand the product, so anything too detailed could be covered later in the sales process.

The four questions we kept hearing were:

  1. How quickly can we deploy it?
  2. Can we use it safely in regulated environments?
  3. Can it live inside our own brand and customer channels?
  4. What does universal co-browsing actually mean?

The content strategy came from sales conversations, not a marketing brainstorm.

What does “universal co-browsing” actually mean?

This was probably the most important of the four. We used the phrase constantly in sales, but most people did not immediately know what it meant. Other vendors also used similar language for products that worked quite differently.

The challenge was to explain the distinction clearly without turning the video into an architecture lesson. I was particularly happy with this script because it simplified an explanation I had given many times in customer conversations.

Surfly platformThis video remains live on the Surfly website as part of the platform overview.Opens in a new tab.

How difficult is Surfly to deploy?

One of Surfly's strengths was how quickly it could be integrated. The video focused on the speed and relative simplicity of getting started without turning it into an implementation guide.

Can this be used safely in regulated environments?

Security and compliance came up frequently, particularly with customers in healthcare and financial services. The video focused on the controls that mattered most to buyers and kept the explanation at the right level for someone still learning about the product.

Surfly security and complianceThis video remains live on Surfly's security and compliance page.Opens in a new tab.

Will this feel like our service or somebody else's?

For many businesses, this was a trust issue as much as a branding one. They did not want their customers being sent to unfamiliar URLs, strange email domains or obviously third-party experiences.

The video explained how Surfly could sit inside the customer's existing brand and channels.

Knowing a product well is not the same as explaining it well.

I had full ownership of the scripts, with CEO approval to go ahead with the project. The people reviewing them were not deeply technical, which was actually useful. I asked them to tell me where something was unclear or where they lost the thread. If the explanation made sense to them without extra context, it was probably at roughly the right level for the website.

I used three checks when writing the scripts:

  1. Would someone without product knowledge understand it?
  2. Is this detail useful at this stage of the buying process?
  3. Does simplifying it change the meaning?

The aim was never to show everything I knew about the technology. It was to give somebody enough understanding to see why the product might matter to them.

That is also how I think about Solutions Engineering more broadly. Technical accuracy matters, but so does knowing how much detail is useful at a particular stage of a deal.

Knowing a product deeply is useful. Knowing what not to explain is just as important.

An external agency handled the filming and editing.

I stayed closely involved where the visuals were part of the technical explanation. If a particular diagram, interface or sequence was needed to make the point clear, I supplied mock-ups and explained what needed to appear alongside the script.

Where the visual treatment mattered less, I left more room for the agency to use its own judgement.

I owned

  • Product story
  • Script
  • Technical accuracy
  • Diagram requirements
  • Mock-ups for key visual explanations
  • On-camera presentation

The agency owned

  • Filming
  • Editing
  • Production treatment
  • Creative execution where technical precision was less important

That division kept the responsibilities sensible. I owned the product story and technical accuracy, while the production team brought the specialist production expertise.

This was my first time presenting this kind of material in a professional studio.

A teleprompter is a very different experience from explaining something live to a customer.

In a customer meeting I would normally explain things more naturally and react to the person in front of me. Following a script at a fixed pace felt quite different, and some sections needed multiple takes before I got comfortable with it.

Once I adjusted, I enjoyed the process. It was useful experience in presenting technical material in a much more controlled format than I was used to.

The four professional films were only one part of how I used video at Surfly.

If a complicated topic needed to be handled asynchronously, I generally preferred a short screen recording or spoken walkthrough to a long email. It was often faster to make and much easier for the recipient to understand.

I used video differently depending on the problem:

  1. Market education

    Professionally produced, reusable content for questions many prospects shared.

  2. Active sales cycles

    Short bespoke recordings built around a specific customer, use case or technical question. These could also be shared internally on the customer side and reused throughout the deal.

  3. Repeated technical instruction

    Reusable tutorials when the explanation genuinely stayed the same each time.

That did not mean sending generic videos everywhere. In active sales cycles, we often recorded short demos specifically for the customer rather than sending something generic without context.

Reusable content is useful when the question is reusable. Otherwise, bespoke is usually better.

One of the most useful videos I made was not professionally produced at all.

Element masking was a powerful Surfly feature, but configuring it generated the same questions repeatedly. I recorded a straightforward webcam tutorial showing customers how to set it up.

It became the most-viewed video on Surfly's YouTube channel and was regularly shared by support and sales with customers and prospects.

Why it worked

  • Solved a recurring configuration question
  • Could be shared by both sales and support
  • Saved repeated explanations and calls
  • Became the most-viewed video on Surfly's YouTube channel

The value was simple. Instead of arranging another call or writing out the same instructions again, people had a resource they could send whenever the question came up.

The useful part of this project was not just being on camera.

This project brought together:

  • Deep product knowledge
  • Commercial judgement about what prospects needed to understand
  • Scriptwriting and technical storytelling
  • Professional on-camera delivery
  • Visual direction where technical accuracy mattered
  • Reusable enablement for sales and support

Understand the product properly. Understand what the customer actually needs to know. Then choose the clearest way to explain it.