The fallacy of not selling features

“Sell benefits, not features”. This maxim has long been cemented as gospel. The logic runs that users are not all that interested in buying your product. What they are really interested in buying is improved efficiency, or an easier life, or a better version of themselves.

Indeed, this is compelling logic. The problem is that, particularly for any kind of technical product or business service, this logic is half-baked. It assumes that users disregard detail and that they buy purely emotively without wanting proof of marketing claims.

In reality, overlooking specific features can be confusing for users. Benefits and features are not at odds like the maxim implies, and you can afford to neglect neither.

Features versus benefits

While it is true that benefits and features are not diametrically opposed, they do have apparent differences. A feature is something that your product explicitly has. A benefit, meanwhile, is the outcome your product more generally creates – whether that is a quantifiable result or an emotional upshot.

So, the feature is the precise “what” that makes up your product or service. The benefit is the promotional “why” that emphasises why those features are game-changing for the user.

Feature-selling and benefit-selling both represent distinct tactics. As Jason Fried puts it: “‘Here’s what our product can do’ and ‘Here’s what you can do with our product’ sound similar, but they are completely different approaches.’”

Pushing features to the backseat

The comparatively dry nature of features has seen them take the backseat in favour of a benefits-led approach. Apparently, “people simply don’t care about features“. It is argued that features are “technical and irrelevant“.

Benefits, meanwhile, are compelling. They paint the user a picture of how much better their life could be with your product, allowing them to envision all the incredible gains that await.

From this angle, the core reasoning behind the “sell benefits, not features” maxim is perfectly sound. It makes sense to put the focus on the user and their problem, not on your product and its many nuts and bolts.

As with anything, however, blanket statements like “Method A sucks; Method B rules” are too broad to just accept blindly. In this particular instance, it is a fallacy to deny the impact that features have on the user’s final purchase choices.

In fact, failing to showcase your product’s features adequately can be the difference between onboarding a new user and losing them to a competitor.

The switched-on user

It would be best if you appealed to the user’s emotions by selling benefits. However, you still need to back up that emotive patter with real substance.

Today’s users are tech-savvy and switched-on. In a market saturated with millions of similar products, applications and services, users are increasingly accustomed to witty marketing spiel. So, you cannot merely make claims and expect users to swallow them unquestioningly.

In other words, you need to give your benefits the backing of some supporting proof. It is your features and their technical specificities that will provide that proof.

For example, you might claim that your product keeps the user’s data super-safe, with no need for them to worry about any data loss or prying eyes. As this article puts it, “Benefits alone can leave the reader thinking, ‘Yeah, right.’” You still need to state how you do what you claim – what features power those sunny upshots.

A big glowing picture that tells a story is great. When it comes to the crux of converting, however, details matter. For instance, a mobile services provider might be selling the benefits of freedom and availability by allowing lots of data in a set package. While leading with the benefit is fine, the user still wants to know just what their data allowance is. They want the technicality.

The business tech scene

This attention to the technicalities is magnified in a business context. When searching for a business product or software service, the user will likely already know the benefits of that solution. Your target market is already savvy to your software space.

If, for example, the user is seeking a live chat solution for their website, they are probably already convinced on the benefits of chat. If they are looking for a CRM system, they no doubt know how value-added a CRM would be to their operations. Likewise, if the user is seeking a business process automation tool, they are doing so with their eyes wide open on the efficiency and time-savings to be gained.

So, unless your product is in the unusual position of being first-of-a-kind, you are selling in an established market. This makes a benefits-focussed approach largely redundant; the user does not need to be sold on whey they should use your product.

This is precisely where you need to sell features. In a scenario where every solution to a problem boasts similar benefits that the user is already aware of, technical details differentiate. Transparency of information, not artistic advertising, is what this informed class of user is ultimately looking for.

Indeed, the business user is starting their journey armed with criteria. They may have prepared a formal RFI, or they may have a checklist for which the solution needs to tick a set number of boxes. This is where your benefits, no matter how compelling, cannot help. Features, numbers and fine print are what cinch the deal.

Feature-selling and the user experience

Commonly, feature-selling gets a bad rap as a negative factor in the user experience. It forces users to consider the cogs that make your product turn; to wade through jargon and tables when they may only be looking for one broad function.

This may be true for more straightforward products. For business services and software solutions that are larger in scope; however, a focus on features can help the user out no end. As mentioned above, it can save time when running through criteria. Instead of the sizzle, they can cut straight to the steak.

After that initial research, however, feature-selling is also more beneficial to long-term user satisfaction than you might expect. This is because you will end up attracting users who are perfectly suited to your product.

These users want you to cut the fluff and help them identify whether you have the specific set of tools they need. If your product is a match, they will know so quickly from looking at your features. Then, they will be more likely to stay after a sale. After all, your product was chosen for its exact fit against needs – not on vapourware promises or clever sales pitches.

A need for balance

So, does this mean that a features-first approach is categorically better than a benefits-led approach? To answer, an earlier statement bears repeating: blanket statements like “Method A sucks; Method B rules” are too broad to accept blindly.

Conventional wisdom is usually wrong and is always worth questioning. Rather than following maxims like “sell features, not benefits”, first seek to understand underlying functions. Features have a valuable function when communicating with users, as do benefits. Indeed, each complements the other.

Ultimately, you know your market, you know your product, and you know the users you are trying to attract. So, you know best what kind of features-benefit ratio is most fitting. Ditch the maxim and do what works for you.

Please note: this article was originally published at