Shorter and sweeter? The benefits of benefits for identity firms

Repurposing is fun.

Remember the four posts that I wrote earlier this week about communicating benefits to identity customers? Well, I just summarized all four of the posts on a single page on the Bredemarket website, The benefits of benefits for identity firms.

(And now I’m repurposing that page into a single, short blog post.)

The page concludes with a question:

Why is Bredemarket the best choice to help your identity firm communicate its benefits?

  • No identity learning curve.
  • I’ve probably communicated in the format you need.
  • I work with you.
  • I can package my offering to meet your needs.

For the complete page, click here. And if you are an identity firm that needs my services, contact me.

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

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

I knew I’d think of something else after I thought this whole post series was complete. But this post will be brief.

Benefit statements are not only affected by the target customers, but are also affected by the “personality” of the company stating the benefits.

As we all know, different companies use different tones of voice in their communications. A benefit statement from Procter & Gamble will read differently than a benefit statement from Apple, for example.

With that in mind, let’s turn to the example that I used in the third post in this series-namely, that the benefit of a one-second response time for computer aided dispatch (CAD) systems is that it keeps people from dying.

Death personified in Punch. By Punch Magazine – Original: Cartoon from Punch Magazine, Volume 35 Page 137; 10 July 1858 This copy: City and Water Blog, Public Domain, https://commons.wikimedia.org/w/index.php?curid=4465060

Not all companies are going to be that blunt about this particular benefit.

To my knowledge, SCC, Printrak, or Motorola have never explicitly talked about avoiding death as a benefit or their computer aided dispatch systems. Perhaps there IS a CAD company that does this, though.

This is why the development of benefit statements is often a collaborative affair, in part to ensure that the benefit statements align with the character of the company issuing them. Imagine the reaction if P&G promoted one of its soap products with a high-tech advertisement loudly proclaiming “PURPLE!” like the recent Apple ad.

Procter & Gamble ads are usually a bit more restrained.

Well, at least they used to be.

To be frank, Procter & Gamble is better at explicitly stating benefits than Apple is. Saving $100 a year on your energy bill is a benefit; purple is not. But Apple is communicating an implicit “Apple owners are cooler than mere mortals” benefit. Cold vs. cool, I guess, as well as an entirely different definition of “identity” that doesn’t rely on individualization. (If thousands of people have purple iPhones, this fact cannot be used to individually identify them.)

So you not only have to know your customer, but you need to know yourself so that you can describe benefits that are important to your customer in a voice that is accurate to your company’s “personality.”

This is why Bredemarket uses an iterative process in developing communications for its clients. 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 implement such an iterative process to help you develop that output. Contact me.

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

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

NOTE: After publishing the second post in this series, but before publishing this third post, I ran across other people in the identity industry who were asking the “So what?” question, but from a strategic perspective rather than a sales enablement perspective. I discuss this in my personal JEBredCal blog, in this post.

This is a continuation of two previous posts. In the first and second posts in this series, I initially 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). I also explained how benefit statements need to be tailored to particular stakeholders, and how there can be many stakeholders even for a simple procurement.

I promised in the second post that I planned 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. Unfortunately, I spent so much time talking about all the stakeholders that I never got around to that particular question.

I promise that I’ll get into it right now.

Two hours vs. one minute vs. one second

You may remember that in the first post, I listed several things that some people thought were benefits, but were actually features. The final three items in that list were the following:

  • 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 feature statements are very similar, yet at the same time very different. As you might have guessed, these feature statements are associated with three different products that are targeted to different markets.

Two hours: rapid DNA

I already alluded to the first of the three feature statements, two hour response time, in an earlier post in this series. Although I didn’t say so that the time, this is an important feature for the “rapid DNA” systems sold by Thermo Fisher Scientific and ANDE. These systems are used for multiple purposes, including

  • examining crime scene DNA evidence,
  • identifying deceased disaster victims, and
  • checking to see if arrested individuals are wanted for more serious crimes.

The two hour rapid DNA processing time offers different benefits for these different use cases.

  • As I previously stated in my first example of a “so what?” test, the ability to run rapid DNA at booking keeps dangerous criminals from being released by identifying those who are wanted for serious crimes.
  • A two hour processing time for crime scene evidence solves crimes more quickly, and again potentially puts dangerous criminals in jail more quickly.
  • A two hour response for disaster victim identification brings peace of mind to family members whose relatives may have perished in a disaster.

Depending upon the target audience, a rapid DNA vendor must tailor its benefit statements accordingly.

One minute: real time AFIS

Next, I want to look at the one minute response time, which is something that I used to talk about over twenty-five years ago when “real time AFIS” became a reality.

Because of the limitations of early computers, it used to take hours or days to compare the features from a latent fingerprint against the features of fingerprints in a database of known criminals. The old computers, even when souped up with special processing equipment such as hardware matchers and hardware fingerprint processors, took a long time to perform all of the calculations needed to compare a fingerprint’s features against hundreds of thousands of other fingerprint features.

Around the time that I joined Printrak, real time AFIS became a reality, where it became cost-effective and technologically feasible to size systems to deliver those fingerprint matching results in a minute. Today, the FBI’s Repository for Individuals of Special Concern (RISC) advertises that it can identify high-priority criminals within seconds.

At the time (1994), real time AFIS was a big deal, and the proposals that I helped to write emphasized that crimes could be solved more quickly (for latent/crime scene fingerprint searches), and individuals could be identified more quickly (for tenprint/booking searches).

One second: computer aided dispatch

To explain the third feature statement about one second response times, I have to fast forward three years to 1997, when the company then known as Printrak acquired the computer aided dispatch (CAD) and records management systems (RMS) unit of SCC Communications Corp. Printrak acquired other companies that year, but the SCC acquisition ended up being the most important, since it led to Printrak’s acquisition by Motorola.

(Allow me to go off on a tangent for a minute. When Motorola sold the biometric part of the business to Safran, it chose to retain the CAD and RMS portions, which remain part of Motorola Solutions’ portfolio today. One other tidbit: one of the key SCC people who joined Printrak at the time eventually left Motorola, and now works for rapid DNA vendor ANDE. As we Californians would say, it’s a small world after all.)

Now while there are some parallels between CAD and the systems then known as automated FINGERPRINT identification systems (AFIS), there are some key differences in the markets that the two products address. We on the AFIS side learned this the hard way when we introduced ourselves to our new colleagues.

“Hi, SCC folks, welcome to Printrak. You’re joining a company that sells REAL TIME AFIS that delivers results within one minute! Aren’t you impressed?”

A screenshot of computer-aided dispatch as being used by Toronto Fire Services. By Hillelfrei – Own work, CC BY-SA 4.0, https://commons.wikimedia.org/w/index.php?curid=88913432

The ex-SCC people responded, gently disabusing us of our pretensions to speed.

“Hello, new corporate overlords. We provide computer aided dispatch systems that send police, fire, and medical personnel to crime scenes and emergency sites as soon as possible. If our CAD systems took AN ENTIRE MINUTE to dispatch personnel, PEOPLE WOULD DIE. We use really powerful computers to get personnel dispatched in a second. Enjoy your real time AFIS…amateurs.”

So the company Printrak learned that it needed separate benefit statements, depending upon the product line the company was promoting at any given time. The CAD customers received one set of benefit statements, while the AFIS customers received a separate set.

Conclusion (finally)

In short, you have to know your customer so that you can describe benefits that are important to your customer.

And 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 2 of 3)

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

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 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.)

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]

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

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.

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.