Sunday, April 6, 2008

The Anti-Bullet Test

I'm sick of generic feature/benefit bullet points. They're just too easy to make fun of. Here's a sampling from a website that will remain nameless to protect the guilty:

  • Easy to use
  • Robust features
  • Innovative systems
Really, it's easy to use? As opposed to what, difficult and temperamental? Robust, huh? Great, because it looks tenuously held together, the slightest breeze threatening to crumble its delicate construction, so it's good to know that, actually, it's robust. Oh I'm sorry, its features are robust, whatever that means.

If you want to not stand out from the crowd, use generic statements. The ones everyone claim. Would anyone claim to be non-innovative?

So here's Jason's Anti-Bullet Test: For each feature/benefit bullet point, construct its negative and see if that statement is ridiculous. If it is, it means the bullet is obvious, or at least unoriginal. It's not strong, it isn't adding excitement, it's not differentiating you from your competition.

Let's apply the test. The negative of "Easy to use" is "Difficult to use." That would be a pretty funny statement! No one would ever claim that, so throw it out.

The negative of "Enables communication" is "Blocks communication." Crazy; no one would admit their tool does that.

The negative of "Stores files as big as 100 gigabytes" is "Cannot handle very large files." Not ridiculous, in fact this is sadly true of most computer systems of any kind. It passes the test.

Here's a good one from our own product: "Integrates with seven version control tools." Negative: "Not integrated with seven version control tools." Not particularly funny; in fact this statement is true of all our competitors. So this statement differentiates ourselves in a specific way.

If you're using generic bullets now, you'll find that replacing them isn't easy! You have to really think about what's strongest about your product, about how specifically it beats the alternatives, and how make it pithy. This is a useful exercise in itself.

One exception to the Anti-Bullet Test: You can use a generic if it's your single biggest differentiator, and if you're willing to put lots of energy behind it.

A good example here is "Fastest." The negative is funny ("Slow operation means lots of time staring into stagnant progress bars"). But if you make it your highest priority, it can work. Make your bi-line "The fastest ____." Prove it with benchmarks. Explain how speed is not only about saving operator time (the obvious benefit) but how it enables entirely new features. For example, perhaps operation X is typically so slow that people can't take advantage of it. But since your system can complete operation X in two seconds, suddenly it becomes a feature. Even if a competitor technically has the feature, you make it practical.

All this is just another way of saying: Be specific, be fully committed, and tell the truth.