How To Decide On What Features To Put In Your Demo Movie

This week on the Simplifilm blog we're going to describe the specific steps that go into making a Simplifilm Demo Movie.  This is part 1 of the series. We'll cover all of this in-depth sometime soon.

We call the first step the concept. We're looking to explain things so that people can understand it. What we call the concept is demonstrating the pain that people have, and telling a story that solves it.

Step 1: Consider Each Feature, but Make a Short List

Our first step to a great software demo movie is to examine all the features of a product and then decide what to include and what to leave out. Most of the time, product creators want to include a jarring laundry list of features so people can get it. But that's not what sells video work. What sells is understanding how the product will benefit the user. Throwing features against someone will confuse most people.

We know.

We test and measure everything.

If you include too many things, you'll have one of two problems. No. 1: Your script will be too dense, and  you'll be talking like the micro machines guy, No. 2: You'll wind up so long that people will tune you out. (Hint: keep it under 75 seconds if you want buyers.)

So, we want to include three features or so. There are occasional exceptions to this, if there's a natural 4-step workflow, or if there's something, such as an engineering product, that requires more complexity. But resist this. The natural question is: What three things do we want to know to make this sale? Figure out from your customers why they actually bought.

The famous Ivengar Jam Study informs us that less is more—the fewer choices people had to process the more likely they were to make a purchase. Less is more.

Some notes: In an explainer video, we might get to more featuresExplainers aren't really made to sell anything, they are allowed to be more low key and educational. That's their point.

In a public walkthrough video, which is designed to ramp up new customers, you can also go a little longer. People already bought—and a lot of times these are used as a sales video.

Conversion videos (what we specialize in) are fairly technical in nature and you have to make sure you respect the audiences time and intelligence and get to the point.

Show High Impact Features—Use Transitional Phrases To Get People To Understand More

We want to show high impact features. Don't worry—we can use transitional or inclusive phrases like "and so much more," while showing the other features on screen for a beat or two. In our visual channel, we show what other things the software does. We do it quickly, but people can understand it immediately. We can either do a short walkthrough of the experience, or about three features.

The ideas is that people will retain this at the end of the video and be motivated by your best features to take action and do more.

We will have more than enough material to be effective. People don't buy features, they buy stories. We either visually execute a list of features, or we can tell a story about what their life will be like after they use this product.

A caveat: our product-oriented videos have always outconverted the character driven schlock we are seeing pop up everywhere. We've replaced that sort of work on a few occasions and done better. The "cartoony" stories distract from the product and exist to entertain their video creators, not to sell anything. We focus on the product and weave a story around it. This takes skill, it's way harder than cartoon animation, but it also converts.

We have never been beaten in a head-to-head with any cartoony/character animation production. This is how we get lookers into buyers.

Show Step-by-Step, Core Features And Differences

How should we define a high impact feature, versus something that's merely presumed to be part of it? We have to show concretely that the product is usable. The parts of the interface the demo shows should demonstrate that the software's UI/UX people have a fluent understanding of design. If it doesn't make sense in our demo, probably you should go ahead and rethink some design elements.

However, a good design isn't a feature. It's an expectation at this point.

We also want to avoid wasting time features that are assumed. The "assumed features"  vary by industry—but think of a spell checker as part of a word processor. It's assumed. It's part of every word processor. We don't want to list the things that are blindingly obvious. If every single competitor has it, we list it in the "and so much more," or hinted at in a carefully wrought sentence. A three-point breakdown isn't needed.

What we need to talk about is either the steps to getting the desired result or the things you can make (or accomplish) with the software.

Some examples:

So, for a web dev business: Step 1 would be to pick a design. Step 2 would be to add features. Step 3 might be to "go live." (See Media Stove)

For a website plugin that ensures your privacy, you'd probably want to say just how that the website plugin ensured it. Example: we flush your cookies, run everything through one of 39 proxy servers and we recognize and reject 99% of tracking pixels. (We just made that up.)

You have to balance between technical proficiency and telling a story. People don't buy features, they buy a story.

We'll talk about tone and balance next when we talk about Step 2, the script.