Why we sell features, not benefits
Marketing lore tells you to focus on the why, not the what. It's wrong.
Welcome to Product for Engineers, a free newsletter created by PostHog for engineers and founders who want to build successful startups.
This week’s theme is: Features > benefits
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 Fullstory:
Homepage SEO title: “Build a more perfect digital experience | Fullstory”
Homepage headline: “Happier customers. Healthier bottom line.”
Homepage strapline: "Your bottom line depends on the quality of the digital experience you offer your users. See what’s working—and what’s not—with all the data you need to make smarter decisions, faster."
“Build a more perfect digital experience” is a benefit, as is "Healthier bottom line." The strapline "See what’s working—and what’s not" touches on what Fullstory does, but it’s still a little vague. It then concludes with "make smarter decisions, faster". It's a benefit sandwich with a light feature filling.
An example of selling by feature is Datadog:
Homepage SEO title: “Cloud Monitoring as a Service | Datadog”
Homepage headline: “Modern monitoring & security”
Homepage strapline: "See inside any stack, any app, at any scale, anywhere."
Datadog leads with what it is.
This approach isn’t just for developer tools. Finance and HR platform Rippling manages it in a sector often dominated by flowery benefits language:
Homepage SEO title: “#1 Workforce Management Platform | HR, IT, Finance
Homepage headline: “Magically Simplify HR, IT, and Finance”
Homepage strapline: “Rippling lets you easily manage your employees’ payroll, benefits, expenses, devices, apps & more—in one place.”
While the headline “Simplify HR, IT, and Finance” is a benefit, the strapline clearly outlines exactly what Rippling does. Rippling backs this up with this simple, unambiguous feature module right below:
Why features > benefits
Marketing lore tells you to 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.
Why?
Because this language has become so ubiquitous, 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 products work, to plug it all in, so details matter. Benefits language 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.
There’s a balance, of course. You need some benefits language as a backup for people who don’t get it. For executives who don't use the software, and certainly don't implement it – go nuts. But, for everyone else, benefits-heavy 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 meant people instantly knew what we do, which is more important than saying something like "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 describe what we do in a one liner.
Last year, 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 saw that as a win because it meant we weren’t confusing users, while communicating we were more than "just" product analytics.
More recently, we refreshed our homepage and updated this messaging to emphasise:
Who PostHog is for (engineers)
That we’re an all-in-one tool.
There's some benefits language here, but we still focus on what PostHog actually does, and the key features are highly visible. The anti-pattern here would be language like “simplify your data stack.”
Further down our homepage, we include code snippets with examples of exactly what you can do with each product in our platform. We trust customers to understand the benefits of these features to them.
The Golden Rule: Customers are smart
Generally, 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, not how you'll help me "make smarter decisions, faster". It doesn't help me compare your product, or understand your usefulness, it just feels manipulative.
📖 Good reads
A software engineer's guide to A/B testing – Lior Neu-ner
An intro to A/B testing for software engineers. Learn how to devise good A/B tests, implement and monitor your tests, analyze your results, and avoid common A/B testing mistakes.
Fundraising Advice – Tracy Young
Fundraising tips Tracy Young, the former co-founder/CEO of PlanGrid. “The best investors can discern your intentions with remarkable accuracy… Avoid posturing or lying to yourself about your startup’s purpose and impact.”
A/B testing examples from Airbnb and YC's top companies – Ian Vanagas
"Good artists copy, great artists steal." To help you become a great A/B test "artist", Ian Vanagas researched how Airbnb, Instacart, Monzo, and other top YC companies run successful A/B tests.
The Psychology of Design – Growth Design
A great resource on cognitive biases that impact how your users think and use your product.
💸 Apply to PostHog for Startups
Get $50,000 of PostHog credits for your startup. That’s:
30 million events. Analyze events, create funnels, build dashboards and more. All in one platform.
50k session replays. Watch user sessions, with console logs and network performance tracking. No extra code needed.
Over 4 billion API calls. Run multivariate experiments and complete safe, staggered rollouts with feature flags.