How new security categories emerge: the Security Adoption Life Cycle (SALC)

Lately I've been talking with several "security pioneers": companies that are trying to convince the world to adopt new types of security products.  They are offering solutions for emerging security problems, or perhaps for security problems that have been around for a long time but for which awareness is still emerging.  What I've observed is that companies trying to pioneer a new security category often target the wrong kind of accounts in their sales process, and listen to the wrong feedback in validating their market assumptions.  They should be following what I call the Security Adoption Life Cycle, which can guide both whom to target and what feedback to value.

Here's what I mean.

A company solving a new threat type X nearly always leads with this picture, which is the same bogeyman slide referred to in my other post on security positioning.

Fig 1: Attacks of type "X" over time

The message is: "X matters more than you think; others are being attacked: you need to protect yourself."  The most common reaction to this pitch is going to be polite interest, maybe a couple of meetings, but not the kind of urgent action the vendor wants or expects.

The Technology Adoption Life Cycle and the Chasm

Geoffrey Moore described a Technology Adoption Life Cycle (TALC) in which early adopters and mainstream adopters behave in fundamentally different ways.  In his model, mainstream buyers want to reference others who are already on board, and they don't consider early adopters to be suitable references.  To be successful in the mainstream, then, a technology has to actually begin penetrating the mainstream; the early adopter phase is more-or-less irrelevant to the mainstream.  And the famous "chasm" (Figure 2) is where technologies fall that are successful with early adopters but never reach mainstream buyers.

Fig 2: Geoffrey Moore's Chasm model of the Technology Adoption Life Cycle

The other great insight of the Chasm model is in describing what types of customers populate each stage of the adoption cycle, as seen along the bottom of the diagram: the early market is driven by technology enthusiasts and visionaries, while the mainstream market captures pragmatists, conservatives and skeptics.

The Security Adoption Life Cycle 

More than two dozen new security categories have emerged and created substantial markets over the last two decades.  But for every one that has become mainstream, many more have never become established.  Why do some succeed and others fail?  The TALC offers a way to think about this kind of question in general, but my claim is that the behavior of security buyers is different from the behavior of buyers of other kinds of products, so the lessons of the TALC have to be adapted to be applicable in the security world.

What I'm talking about here is specifically the establishment of a new category of security product when that product is positioned as a way to make the customer more secure.  In many cases, as previously discussed, a new security technology is best positioned as a way to make the customer more productive, not more secure.  When that's true -- call it security-as-productivity -- then the standard TALC applies.  But there are cases where it's appropriate to position security-as-security, and in those situations, we should think instead about a Security Adoption Life Cycle.

Why would security products behave differently than other products in the marketplace?  I think it's a question of two different types of value propositions, the AND vs the OR.  In order to be secure, you have to block all threat vectors.  That's an AND value proposition.  The total losses incurred from all threat vectors will be dominated by whatever is the weakest link at any point in time, and a technology which addresses an issue that's not one of the weakest links will deliver less than linear benefit.  Conversely, a technology which helps increase revenue, or lower costs, etc., has an OR value proposition: even if it's not addressing the number-one problem faced by the customer, it still contributes linear benefit.

The AND vs OR distinction leads to two key differences between the Security Adoption Life Cycle and the standard Technology Adoption Life Cycle.  First, while there are still early adopters and mainstream adopters in security, there are no enthusiasts or visionaries to speak of.  Everyone's a pragmatist when it comes to securing IT, and thus we need a different dimension along which to distinguish early adopters from the mainstream.  Second, in the security world, everything is relative.  Because of the AND property, what's important is not the absolute impact or likelihood of a particular threat, but the relative impact and likelihood of that threat compared to other threats the customer is facing.

These two factors lead to a Security Adoption Life Cycle like the one pictured in Figure 3.

Fig 3: The Security Adoption Life Cycle

Early adopters in this model are not enthusiasts or visionaries - they are organizations who are currently experiencing losses, and they know they're experiencing losses.  The very first group has the highest urgency: they have detected an ongoing attack, and they have no way to mitigate it.  They've either turned off the system in question (think PlayStation Network during their 23-day outage), or they're leaving it on and eating the losses (think Starbucks gift cards earlier this year).  These folks don't have to wait for budget approval, and they don't worry too much about second-order concerns like automation & manageability.  

The second, closely related group has slightly less urgency.  They've solved the immediate pain such that the system is running and losses are stopped or contained; however, they have solved it in a temporary way, perhaps by reducing functionality or performance, or taking on unscalable manual tasks, or opening other risk vectors that are considered lesser evils.  This group needs a solution that can cover at least the medium term.

What links these two early-adopter groups is that their needs are reactive.  Buying behavior is entirely different from the typical preventive needs that drive security customer purchases.  Security technologies cross over from early-adopter to mainstream when they attract Group 3 buyers, who are actually the first adopters of the preventive value proposition: although they have not yet experienced losses, they consider this threat vector important enough relative to all other threat vectors that they are willing to allocate current budget. 

Like in the standard TALC, this early mainstream group bases its purchases on references of others.  But in the SALC case, early mainstream buyers care a lot about the experience of Group 2 - in fact, the first adopters of prevention will be those who personally know others that have experienced losses.  The chasm in the SALC is of a different nature from that in the TALC.  In the SALC, the reactive early adopters are key to motivating the mainstream.

Finally, the laggards in security adoption are those who wait for a best-practice document to be published by analysts, standards bodies, or regulatory agencies.  By the time these best-practices are recognized, the SALC is already on its downslope; the technology category is established; and the question is generally no longer whether an organization will use the technology, but which vendor.  The emergence of a Gartner Magic Quadrant for a category is a good signal that it's reached this stage.

A pioneering security technology will be evaluated differently at different times in the life cycle.  See Figure 4.

Fig 4: Product requirements, reactive vs preventive phases

In the Reactive part of the life cycle, the product only needs to do one thing, which is stop the losses from occurring while allowing service to be fully operational.  And the job of sales and marketing is to find the folks who are actively under attack.  I call it "ambulance-chasing" -- the vendor needs to have good information sources to hear about customers who are compromised, and a rapid-response approach that can go from first meeting to deployed solution in less than a week.

An important characteristic of the Reactive period is that your product has to already work.  The customer's hair is on fire, and s/he doesn't have time to "partner with you on defining product requirements," or any of that standard-issue stuff.  The decision is binary, it's immediate, and it's price-insensitive.

(Many vendors offer a 30-day or 60-day trial installation.  If you're in the rare situation where the customer is actually experiencing losses but doesn't know it, and if your product can detect those losses, you can move the customer instantly from preventive to reactive.  Mostly, though, that doesn't happen.  In most cases a security product sits in a network for a month or two and provides a lot of interesting visibility, but no smoking gun.)

Now, I said at the top of this post that security pioneers often target the wrong kinds of customers and listen to the wrong feedback.  What I've seen, in particular, is pioneering companies spending a lot of their time trying to sell prevention.  They use the bogeyman slide to demonstrate to a prospect that their chosen threat vector is Really Scary, and they then ask the prospect if they are interested in a technology that addresses the vector in question.  Usually the prospect will say yes -- partly to be polite, and partly because s/he genuinely would like to plug every security hole.  The error arises when the vendor overestimates what that expression of interest actually means.

The preventive buyer will only pay for your technology if it's among their top-3 or top-5 concerns in the current budget cycle.  So the right question for the preventive buyer is not "would you like to plug this security hole," but rather, "where does this issue rank among all the issues you care about addressing this year?"  Most pioneering security technologies are not yet in a large organization's top-5 concerns.  A pioneering technology will only get to the top-5 when there have been enough real losses in peer companies, and when those losses become known to the community of preventive buyers.

One implication is that preventive prospects can't validate a new category.  They can absolutely illuminate deployment barriers and other necessary-but-not-sufficient conditions of adoption.  But if they're not experiencing losses, then they actually don't know themselves whether your threat vector is more or less likely to justify a mainstream preventive purchase than a different vector.  You have to be the expert on that question yourself.

The net of all this is: if you're trying to launch a new security category, don't spend too much time early on with preventive prospects.  Find the reactive prospects who have immediate pain.  If you can't find them, then you may not be solving an important enough problem, and it might be time to pivot.