Promoting Perl's Features versus Benefits

Maybe the world needs a book called "Business Thinking for Know-it-All Techies". Certainly the Perl world does.

After a very pleasant conversation with the criminally underrated VM Brasseur at this year's Open Source Bridge Conference, I decided to improve my copywriting skills. Certainly I've been accused of perpetuating content-free, slick marketing on the Perl world before, so why not undercut that libel a little bit by figuring out how to communicate better with real users and real customers?

This lead me to several books, chief among them the worth-ten-times-its-price The Copywriters Handbook.

The high point of the book so far—a technique I've used on three projects in the past week to great results—is to distinguish between technical features and customer benefits.

In other words, while experienced Perl masters might say "Perl 5 is great because you have access to the CPAN", that's a feature. The benefit is that "80% of most programs has already been written". While it's technically true that the Modern Perl book covers primarily Perl 5.12 and 5.14, the benefit is that "the book demonstrates the current ways to write great code". While the as-yet unlaunched value analysis site a couple of us are launching for small investors has the technical feature "updates analysis after market close every day", the benefit to customers is "gives you the best advice possible whenever you check it".

Listing features in terms of features (for the sake of their own obvious technical good, of course) and not expressing them in terms of what they mean for users is where a lot of my previous evangelism for Perl 6 went wrong, of course. It's easy to list off multiple dispatch and continuation passing and gradual typing as if you were competing for a Fields medal in multiparadigm integration, but when I code, mostly I just want the code to work.

On the other side, I suspect that a lot of the reason that experienced Perl 5 programmers don't really care when non-Perlers sneer "Does it have function signatures yet?" is that (even though it'd be grand not to have to write my ($blah, $blahblah, $blahblahblah) = @_; all the time) it doesn't really matter. It's a minor inconvenience compared to the ability to get stuff done.

Even so, it's important to acknowledge which parts of Perl get the benefits-not-features idea right. For example, consider the module POD skeleton format, where a one-line NAME explains what the module does, then a SYNOPSIS shows an example of working code, and this all happens before a description and detailed technical walkthrough of how to use it. When this format works, it works well.

My experience so far has been that the exercise of comparing features to benefits takes some time, but yields great results. Try it yourself; it's easy. Grab a piece of paper and make two lists. On the left side, write all of the distinct technical features you consider worth mentioning. When you finish, write on the right side a benefit from the customer or user point of view corresponding to that technical feature. Sometimes there's overlap, and that's okay.

When you finish, you should be able to do three things. First, you should be able to identify distinct themes in your benefits. Sometimes these will surprise you, and that's good. Second, you should be able to rank the benefits for each particular audience by priority. If you have multiple audiences, so much the better—you've unlocked an extra-credit achievement. Finally, you should be able to write better prose explaining why your product or project matters to each audience by arranging the benefits in a logical order. (Your skill as a writer matters a lot here, but even if you're still learning how to write effective persuasive prose, the act of thinking in terms of customer benefit is already a huge improvement.)

Now imagine if the Perl world could practice and polish this skill in our technical communications. Sure, it's marketing and obviously evil, but don't we pride ourselves on helping people do the things they want to do?