I wanted to take some time to specifically explain how to communicate benefits to identity customers. And I’ll take a lot of time, addressing the topic in three planned posts.
What are benefits?
But what are benefits?
It turns out that many people don’t know what benefits are.
Over the years I’ve had occasion to ask people to suggest some benefits to include in a document. Sometimes I’ve received responses that are similar to these:
- This product is dual-purpose and supports both detection of speeders and detection of red light runners.
- This product captures latent fingerprints at 1000 pixels per inch.
- This product was a top tier performer in the recent NIST tests.
- This product can complete its processing in less than two hours.
- This product can complete its processing in less than a minute.
- This product can complete its processing in less than a second.
These are all nice statements, but these aren’t BENEFIT statements.
These are statements of FEATURES.
The last three examples illustrate the issue. In certain markets, a two hour response time is very impressive In other markets, a one minute response time will result in getting somebody killed. (I’ll address the differences later.)
In my recent post about case studies, I linked to a Hubspot article that explained the difference between benefits and features. I didn’t dive into that article at the time, but I’ll do so now. Here is how Kayla Carmichael’s article explains the difference between the two.
Features describe what the product does, setting it apart from the competition. Benefits describe how the product can help the audience. For marketing messages, it’s typically better to go with a benefits-heavy approach, because benefits are what makes consumers purchase.
The “so what?” test
As you can see, benefits are customer-centric. In another Hubsport article, Aja Frost notes that one way to tell whether you’re dealing with a benefit or a feature is to ask the question “So what?”
Let’s return to my first example above, “This product is dual-purpose and supports both detection of speeders and detection of red light runners.” Even if you’re a road safety customer, you may not care whether a particular device is dual-purpose or not.
Maybe you don’t care about both issues at a particular location on the road. If the road safety camera is placed on an interstate highway, red lights are obviously not an issue.
Maybe you don’t care about one of the issues at all. Perhaps local laws don’t allow for unmonitored devices that detect speeders.
Perhaps your agency doesn’t care if you have to put two devices—one for speed detection, one for red light detection—at the same location.
So if you encounter a statement that isn’t a benefit, you have to act like an irritating two-year old and ask “so what?” until you actually get a benefit statement.
“This product can complete its processing in less than two hours.”
“This product can complete its processing while the arrestee is still in custody, before the suspect is released.”
“This product can detect whether the arrestee is wanted for more serious charges while the arrestee is still in custody.”
“This product can identify arrestees who have outstanding warrants for murder before they are released to murder more people.”
Anyway, that’s the general concept of benefits vs. features. In a future post, I’ll dive into issues more specific to identity customers, such as when a two hour response time matters, when a one minute response time matters, and when a one second response time matters.
These differences make all the…um difference to identity customers.
In the meantime, if you’re an identity product/service provider that needs help in communicating customer benefits in proposals, case studies, white papers, blog posts, and similar written output, Bredemarket can help. Contact me.