Features vs. Benefits

Off the Beat: Bruce Byfield's Blog

The other day, I received an announcement about a new distribution. That's not unusual; I receive announcements about new software each week. But what struck me about this one was that, while the announcement mentioned a few new features, it gave no reason why I should care about them as either a reviewer or a user. As a result, it failed to interest me in the distribution, and the sender of the announcement might have saved his efforts.

Or, to put the situation into marketing terms, the announcement mentioned features when it should have been talking about benefits.

Understanding the distinction
The distinction between features and benefits is one that all marketers learn. However, it eludes many developers. Why, I'm not sure. Perhaps because of a lingering meritocratic conviction that any accomplishment will be recognized without self-promotion? Or maybe it's the suspicion that anything remotely resembling marketing amounts to lies and deception. But the distinction is one that you need to understand if you are trying to get the word out about your project.

You can think about features and benefits as different perspectives on the same piece of code. The feature is the what, the description of what the code does. The benefit is the why, the explanation of how users benefit from the code or the reason they should pay attention to it.

For instance, the Amarok music player has a plug-in that fetches and displays any Wikipedia entry about the act whose music you are playing. That's the feature.
If you are trying to stir the curiosity of end-users, the benefit might be that they can learn more about musicians without specifically having to look them up. Or, possibly, you might tell them that hard copy liner notes are replaced by the latest online information. 

However, what benefits you mention depend on the audience. If you were trying to interest developers in Amarok, you would probably prefer to present the plug-in as an example of how easy it is to add to the code. 

Some features, too, will simply have no benefits for parts of the audience. For instance, if you had designed a new feature that allowed developers to code faster with Plasma, KDE's interface renderer, the chances are that you couldn't come up with a benefit that would interest ordinary users -- although they might benefit indirectly from the feature, the speed of development would be of little interest to them. Nor would a GNOME developer be likely to take more than passing notice. By contrast, the benefits to KDE code contributors would be obvious -- probably faster development time, or increasing the time to code by increasing efficiency.

About the only time that features alone are likely to make news interesting is when it is unique or has such a potential effect that it receives automatic coverage. Announce, for example, that you had a complete drop-in replacement for the Linux kernel, and people would investigate because the news is so unusual. 

Similarly, a few large projects -- for instance, Ubuntu, Fedora, KDE, and GNOME -- will attract people for no other reason that they are so well-known. Such projects don't need to mention benefits, because reviewers will look at them regardless.

Actually, though, it never hurts to mention benefits anyway. After all, some Ubuntu users would have no interest in a Fedora release unless it contains something special, and the reverse is also true. Also, you might get a more enthusiastic review if something in your new release interests the writer.

The point is, you need to mention benefits if you hope to create any interest. Even a charity or a crowdfunding effort is better off publicizing itself in terms of benefits rather than features -- a list of what you have done or hoped to do will never be as interesting as explaining to donors how they benefit from helping you beyond a momentary glow of satisfaction for being charitable.

Persuading reviewers
When I pointed out something of these ideas to the person who sent me the announcement last week (I was feeling charitable), they replied by explaining that the new distribution was intended for forensics, and improved on an existing similar distribution in several key ways. 

Suddenly, with that context, I noted the distribution as a possible future topic. However, without that additional information, I likely would have ignored the news. After all, when hundreds of distros exist, the release of another one is not newsworthy in itself.

In other words, a reviewer is as susceptible to benefits as any other potential audience. A reviewer is going to judge your announcement based on several well-defined criteria. The first is: "Do I want to take the time to research this software?" That is quickly followed by, "Can I interest an editor?" and the closely-related, "Will readers be interested?"
Ten minutes online will tell you the topics that a reviewer has covered consistently in the past. Another ten will tell you where the reviewer has published, which will suggest what various editors want. Armed with this information, exercise your ingenuity to figure out what benefits will tickle the reviewers' and possible editors' interest.

For readers, just think in terms of general end-users.

Armed with this information, you should be able to assemble an announcement that will be at least read. Reviewers won't always be as open to changing their minds as I was to last week's announcement, and, unless you demonstrate the benefits of reviewing your project, chances are that otherwise they will simply delete your announcement half-read. 

It's not that reviewers are unsympathetic, or unaware that they might be missing a story they'd love to cover. it's just that, like any busy people, they follow several general rules to help them manage their time -- and one of those rules is that if correspondents can't articulate what makes their work interesting, the odds are that the work isn't worth a closer look. Much of the time, that assumption works.

Nor will convincing a reviewer to take a closer look guarantee coverage. Any number of things -- whim (the reviewer's or the editor's), breaking news, lack of space -- could mean that even a story with countless benefits may never be written.

All of which means that generating benefits to catch the attention of editors and reviewers means going to some trouble with absolutely no guarantee of success. 

But although a general announcement may be quicker, it is even less likely to succeed. A general announcement is like a generic cover letter with a job application. It suggests that you don't care much. And if you don't care, why should the potential employer or reviewer?

Should your effort fail to produce an article, don't write the reviewer and ask why. Unless you are friendly with them, that question is only like to make the reviewer annoyed by asking them to explain themselves when they could be working.

Instead, take the initial failure as a chance to improve your description of your project so that you try again with your next release. And remember -- in most cases, talking benefits is going to take you further than a lifeless list of features, no matter how complete.