Creating Stickiness Without FUD

2011-06-11 22:22:10 by chort

I must be the last person in the world reading The Tipping Point by Malcolm Gladwell. The book is full of relatable concepts, but the one that's struck me the hardest so far is how a university professor was able to convince students to get tetanus shots.

For those unfamiliar with the story, I will summarize it. The campus health clinic was giving shots for free. A student merely had to walk in and request it. The experiment was to discover what the most effective way of convincing students to make the effort would be. The professor initially tried a few different styles of pamphlet, all with essentially the same information. Some of the pamphlets were more frightening than others. As expected, the students who had read the scary version initially reported being more inclined to get inoculated. As it turned out, only 3 percent of students actually got the shot and the version of the pamphlet they read had little to no impact.

The next time the professor conducted the experiment he included additional information in the pamphlets, specifically a map with the campus clinic marked and a readily visible schedule of when it was open. This time 28 percent of the students were inoculated.

There should be two obvious facts fairly leaping off the page at you: a) FUD doesn't have a lasting effect and b) the less work you force your potential customer to do, the more likely they are to buy.

The latter of these has been a pet peeve of mine since I got my first job in sales. It's also why I'm an avid Apple customer. This is also why Apple customers tend to buy more and more of their products, even though others deliver more features at a lower price. When it comes down to it, all the features in the world don't mean much if you have to do a lot of work in order to see any benefit.

I will give you an example which is true of almost every security vendor in the market (in fact, almost every technology vendor period). Imagine you're a sales engineer (that's the geeky person who explains all the nuts & bolts of a product to a potential customer). You work for an anti-$FOO company selling a Widget that is supposed to solve a customer's $FOO problem. Your engineering team goes off and builds this incredible platform with all these flexible tools that one can use to stop almost every variation of $FOO. The catch is when you take the Widget out of the box and turn it on, it's a blank slate. It doesn't do anything.

The customer is expected to create all the anti-$FOO rules, because naturally the customer knows what kind of $FOO is most relevant to them. Most companies won't buy a product sight-unseen. They want to try it out in their environment first to make sure it could actually solve their problem. As a good sales engineer, you realize you're wonderful Widget isn't going to look very compelling, so you spend a few hours configuring it with common rules that nearly every customer wants. The Widget gets through the proof of concept and you end up getting the sale. You do this the next day at a different company, the next day at a different company, and so on.

After a while you get tired of setting up the same damn rules every time and you put in a product enhancement request to just have those rules in the product by default. The product manager agrees it's a good idea and puts it on the roadmap for a release two years out. With every release a few features have to get cut due to being behind schedule, so you keep spending hours each week writing the same rules and eventually, 4 years from when you asked, the product actually ships with the common sense rules it should have had all along. In the mean time 3 more features have been released "just to get them out there" that don't have helpful default settings, so you start the same cycle all over again.

This might sound like it's only a problem for the sales engineer, but it's really a problem for the whole company. Only a certain percentage of your sales engineers will spend the effort to setup those rules, so you'll be missing out on potential customers due to the combine shortcomings of your product and sales teams. It gets worse. Although the initial rules might have taken your Widget through the proof of concept, the customer isn't going to put any more effort into configuring it. As you add new features, they'll go unused. Eventually your customer will have a really severe $BAR problem and go looking for a product that solves it, even though your product added anti-$BAR features two versions ago. Because you don't have any useful default anti-$BAR settings, your product will be discarded and you'll loose renewal revenue. Not only that, but the customer is unlikely to buy your future products because they'll remember your company creates shelfware.

Now let's think about how long it would have taken to research and implement sane default rules. Maybe a week or two per release? Were the two weeks shaved off your release cycle really worth losing the continued business of the customers that your good sales teams won, and the missed business that your poorer sales teams could have had with a more compelling product?

It's not only vendors selling products that fall victims to this. Nearly every open-source project I've ever had the displeasure of downloading code from does the same thing. Everyone is so obsessed with the "good enough" culture of "just get the features out there" that no one ever spends the small additional effort to make their products usable. Most of the time it wouldn't take much extra effort, maybe 10% more, in order to have a product that makes it easy for users to solve their problems. Instead, we all think it's sufficient to tell a customer they have a problem and our product can solve it and leave it up to them to figure out how.

Stop telling people tetanus is really scary and start giving them the damn map and clinic hours.

Add a comment:

  name

  email

  url

max length 1000 chars