Features tell, benefits sell. Well, they used to.
What are you talking about?
Benefits are why someone would use your product.
Features are what your product does.
An example of selling by benefit is Salesforce:
Homepage title tag: Salesforce UK: We Bring Companies and Customers Together
Hero image: "Drive growth with magical Customer 360 experiences. See how Salesforce can help you unite data to make every customer moment more cost-efficient."
"Drive growth" is a benefit. This headline touches on what the software does "Customer 360 experiences... unite data", but that is still a little vague, and then concludes with "more cost-efficient". It's a benefit sandwich with a light feature filling.
An example of selling by feature is Datadog:
Homepage title tag: Cloud Monitoring as a Service | Datadog
Hero image: "Modern monitoring & security. See inside any stack, any app, at any scale, anywhere."
They lead with what it is.
So, which is better?
Marketing lore tells you that you must focus on the why, not the what. "No one buys a CRM, they buy a way to increase their revenue". I disagree strongly if you are working on a developer focused product, and perhaps anything.
This approach has become so popular that it feels tired and out-of-touch. Developers are especially sensitive to vague language when evaluating products. Hacker News provides a clear example of this – many new startups launch there, and a common criticism is "I have read the homepage and don't know what it does". I think it's because developers have to figure out how it all works, to plug it all in, in many cases, so details matter.
It makes me feel like I'm being sold to, by someone who doesn't know what they're talking about.
Worse, benefits-heavy and feature-light language makes it hard to know what you're actually buying. I can evaluate for myself what benefits something brings, I want to see what it does, and how it compares to other products.
Highlighting benefits makes sense, as a backup in case I don't get it. For executives who don't use the software, and certainly don't implement it – go nuts. For everyone else, benefits-oriented language is a poor user experience – it gets in the way of explaining the product.
What we've tried at PostHog
At PostHog, we've found this a lot harder as our product has become bigger.
We started off as "open source product analytics". This means people instantly know what we do, which is more important than saying something like "build a better product" or "understand your users better".
As we grew, we quickly built many more products into the platform. Today, we provide product analytics, session recording, feature flags, experimentation and a range of apps. This is when it got harder to decsribe what we do in a one liner.
We went for "Open Source Product OS. A suite of product and data tools. Built on the modern data stack.", then immediately included the list of them underneath.
This created a large debate internally.
We ran an a/b test, using your favorite open source product OS, and happily saw it had no impact on conversion rate. I see that as a win because it means we're not confusing users, and it means we are seen as wider than "just" product analytics, which will let us get wider usage from teams across lots of our products.
Users are as clever as you
Often, users do know the product category they're interested in. I know, for example, the approximate benefits a CRM brings, and I want to choose one that suits my team particularly well. Otherwise I wouldn't have been looking for one in the first place. Show me how your features stack up. Please don't tell me you'll "drive growth with magical customer 360 experiences" (Salesforce's homepage today) – this doesn't help me compare your product to your competitors, and it makes me feel like you're manipulating me instead of helping me decide if you are actually useful.