Tag Archives: benefit

Communicating benefits (not features) to identity customers (Part 2 of 3)

[Link to part 1] | [Link to part 3] | [Link to part 4]

(Updated 4/16/2022 with additional information on benefits.)

This is a continuation of a previous post, in which I explained the difference between benefits and features, and why you sometimes have to act like an irritating two-year old to convert a feature into a benefit (the “so what?” test).

As I promised in that previous post, I plan to 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.

Who are identity customers?

Before I dive into response times, let’s explain who identity customers are, because not all identity customers are alike.

When I use the term “identity” at Bredemarket, I am referring to any technology that can be used to identify an individual. This does not just relate to biometrics (fingerprint identification, facial recognition, etc.), but to any of the five factors of authentication that can identify an individual. A physical or digital driver’s license. A fob. A secret handshake. A geographic location. Even a password.

Obviously there are a ton of customers that use identification technologies, and they care about a ton of things.

Well, what if we focus our discussion and talk about a SINGLE product, such as automated biometric identification systems (ABIS)? We can market to all ABIS customers with a single set of benefit statements, right?

Um, no.

ABIS can be sold to all sorts of different customers, ranging from local police agencies to state welfare benefit administrators to national passport issuing agencies.

Well, what if we focus our discussion and talk about a SINGLE type of customer for a single product, such as the local law enforcement agencies that buy ABIS? We can market to all local law enforcement ABIS customers with a single set of benefit statements, right?

Um, no.

If I am going to sell an ABIS to the city of Ontario, California (sorry Thales), these are the types of customers (or target audiences) that I have to cover with separate benefit statements:

By FBI – http://www.fbi.gov/news/photos, Public Domain, https://commons.wikimedia.org/w/index.php?curid=18500900
  • The field investigators who run across biometric evidence at the scene of a crime, such as a knife with a fingerprint on it or a video feed showing someone breaking into a liquor store.
  • The examiners who look at crime scene evidence and use it to identify individuals.
  • The people who capture biometrics from arrested individuals at livescan stations.
  • The information technologies (IT) people who are responsible for ensuring that Ontario, California’s biometric data is sent to San Bernardino County, the state of California, perhaps other systems such as the Western Identification Network, and the Federal Bureau of Investigation.
  • The purchasing agent who has to make sure that all of Ontario’s purchases comply with purchasing laws and regulations.
  • The privacy advocate who needs to ensure that the biometric data complies with state and national privacy laws.
  • The mayor (Paul Leon as I write this), who has to deal with angry citizens asking why their catalytic converters are being stolen from their vehicles, and demanding to know what the mayor is doing about it.
  • Probably a dozen other stakeholders that I haven’t talked about yet, but who are influenced by the city’s purchasing decision.

As you can see, there are a ton of people who are going to read a proposal to provide an ABIS to a city, and they all have differing needs that need to be addressed…and different benefits that have to be emphasized.

Benefits of a feature are customer-dependent

Now let’s take one of my feature statements from my first post and try to convert it to a benefit for one or more of these stakeholders. I’m going to choose this one:

  • This product captures latent fingerprints at 1000 pixels per inch.

Right off the bat, I’ll tell you that 1000 ppi latent fingerprint capture doesn’t make a bit of difference to the majority of the stakeholders. Paul Leon isn’t going to care. The purchasing agent SHOULD care (1000 ppi data requires more storage than 500 ppi data, which translates to more cost), but probably isn’t going to know that he/she should care.

With the possible exception of the IT personnel, the only people that care about 1000 ppi capture are the examiners who use crime scene evidence and use it to identify individuals. And needless to say, the examiners that concentrate on face or iris or voice or DNA data aren’t going to care about a fingerprint capture specification.

So if I’m writing a proposal to the city of Ontario, California, I’m going to make sure that the latent fingerprint capture section of the proposal discusses my product’s ability to capture latent fingerprints at 1000 ppi.

Wait for it…

SO WHAT?

Absent the benefit of standards compliance that ensures that Ontario data can be processed by state and national systems, the chief benefit of 1000 ppi latent fingerprint capture is that it provides a higher probability that examiners can positively identify criminals and solve more crimes.

An explanation: because latent fingerprints are often of poor quality – the criminals don’t usually take the time to ensure that the fingerprint evidence they leave at crime scenes is readable – latent examiners often benefit from having higher-resolution 1000 ppi latent fingerprint images, rather than the lower-resolution 500 ppi latent fingerprint images that were common in 20th century fingerprint systems. This higher resolution can make it easier for a latent fingerprint examiner to match a latent to a criminal’s tenprint fingerprint from a previous arrest, leading to the “solve more crimes” benefit.

So you’re going to come up with separate benefit statements for examiners, separate ones for livescan operators, and separate benefit statements for each of the stakeholders. And each of these benefits will be enumerated in the section of the proposal that the individual stakeholder will read. (News flash: hardly anyone reads the entire proposal; they only read the section that pertains to them.)

(4/16/2022: For additional information on benefits, click here.)

What’s next?

Well, I never got around to my two hour vs. one minute vs. one second question, and this post is getting long, so I guess I’ll address that topic in a third post.

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.

Communicating benefits (not features) to identity customers (Part 1 of 3)

[Link to part 2] | [Link to part 3] | [Link to part 4]

(Updated 4/16/2022 and 4/18/2022 with additional benefits and customer focus information.)

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?

When you write a proposal, case study, or other document that is targeted to identity customers, you need to communicate the benefits to the target audience.

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?”

(4/18/2022: For additional information on customer focus, click here.)

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.

By Mindaugas Danys from Vilnius, Lithuania, Lithuania – scream and shout, CC BY 2.0, https://commons.wikimedia.org/w/index.php?curid=44907034

“This product can complete its processing in less than two hours.”

SO WHAT?

“This product can complete its processing while the arrestee is still in custody, before the suspect is released.”

SO WHAT?

“This product can detect whether the arrestee is wanted for more serious charges while the arrestee is still in custody.”

SO WHAT?

“This product can identify arrestees who have outstanding warrants for murder before they are released to murder more people.”

That’s better.

(4/16/2022: For additional information on benefits, click here.)

What’s next?

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.

Stay tuned.

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.