The Most Common Mistake in Product Demos, Marketing Collateral and Tech Docs
Ever since I started working in technology, I’ve watched companies make the same communications error again and again. When talking about their products, they start by talking about “how it works” or “what it does”.
Here’s a secret: hardly anybody cares how it works. They may say they do, but what they really mean is this:
How will it make my life better (where ‘better’ means ‘more fun’ or ‘more productive’ or ‘longer’ and so forth)?
I Built It and Here’s What It Does
I first observed this phenomenon when I worked as a technical writer, writing and editing software manuals. I’d often review support documentation for a product that was written by the software engineers who built it.
Inevitably, the docs would itemize the product’s functionality, often by describing each interface element: “The Save button enables you to save your work” and so forth.
It’s an understandable mistake among developers. They built it, and they’re describing how it works from their perspective.
The right way to write docs (and any product collateral) is to focus on tasks, not functionality. If the user will be saving files, then provide a topic called “How to Save Files” or “Saving a File”.
But before you get into the nitty-gritty details, you need to answer that all important question: how will this make my life better?
Our Marketing, Ourselves
The same problem occurs in marketing. In the Web 2.0 world, there’s a trend toward builders also acting as marketers. Most of the time this is a great idea, and I favour a deep, rich, constant connection between the product creators and the product’s users.
As we’ve seen, however, builders can be too close to their creations, and tend to discuss them in ways that may not resonate with their potential users.
Returning to my tech docs roots for a moment, there was another reason to promote the “how it makes your life better” angle. In corporate settings, the people using the software normally aren’t the people who bought it. It dramatically helps with adoption if you can clearly express the software’s benefits to its users after it’s been through the purchasing department.
Show, Don’t Tell
I was reminded of all this while watching an online demo for Freebase. From what I can gather, Freebase is a Creative Commons-licensed database for just about anything. The dream, I think, is that it will become a hub for structured data sets that application developers can use in their programs. It’s easy to see incredible potential for the emerging generation of mash-up-based, widgety web apps.
Watch the demo. Leaving aside the fact that the narrator sounds barely conscious, it’s actually pretty good. However, at around the 45 second mark, the demo falls rapidly into the trap of ‘what it does’.
The narrator rushes through the intro. “Freebase is a shared database of the world’s knowledge”–hang on, I want to know more about that! Instead, we plummet from the promising 10,000-foot view into the guts of data types. I know the demo is targeted at programmers, but they want to understand the big picture as much as anybody else.
Even though it’s called a ‘demonstration’, I’d recommend spending less time under the hood and more time on user education, explaining why Freebase is a boon to web developers. I’d apply that old chestnut ‘show, don’t tell”, and show off a bunch of apps that are already using Freebase.
Customers and Context
What I’m really talking about here is context, and how you should always think in customer-centric terms.
This also helps in the early days of a product’s brand. Ultimately your customers are going to decide what your product is, and what bucket it fits into. However, if you’re constantly feeding them context for your products, then you can help influence how they frame you and your competitors.
The most immediate example of this is the iPhone. Sure, it’s got a bunch of killer features, but the messaging from Apple has been clear and consistent:
“How does this phone make my life better?”
“It makes me cooler.”