I'm excited to publish our first guest post from Zach Goldie! This was an excellent read and I will vocally support more specific dev marketing any day of the week. The Benefit Layers framework is an excellent recommendation I'll be using.
Fantastic discussions ensued on Hacker News!
I’ve heard engineers proudly claim that they don’t fall for marketing, that they only do a technical analysis of a product and hate any sales fluff.
It can be tempting to accommodate this by only listing features without describing benefits.
Listing features is suitable for something like selling a laptop. Computers have well-defined specs so the seller doesn’t need to hype up why a GPU is helpful, they just need to tell you the metrics.
Empty overhyping won’t get you anywhere. But what about when the benefits of a feature aren’t obvious? At that point, you still need to pitch the benefits without taking it into fluff territory.
The Answer: Thinking in Benefit Layers
The answer isn’t black and white. Instead, I suggest finding the ideal Benefit Layer for each feature.
I define these as:
Feature-only - Skipping the obvious benefits
Direct benefit - Pointing out the direct effect
Knock-on benefit - Clarifying the bigger implications
Top-level benefit - Tying into a big picture impact
It’s tempting to go top-level to increase perceived value, but that usually leads to empty fluff like “Ship Code Faster”.
These are similar to a Five Why analysis, with each layer looking at the wider benefit of the one above. So, let’s look at when each layer is appropriate:
Feature-only
Some features are obviously desirable, in which case you can state them without benefits. Two common cases are:
Competing on specs, where more/faster is obviously better.
Mentioning a table-stakes feature such as having the typical integrations.
Instead of describing the benefit, use the space to go into details such as how you achieve the improved performance.
Direct benefit
If the implications aren’t immediately obvious you need to join the dots. To use a marketing example, not everyone would know that server-side analytics has a benefit of more accurate attribution data.
Direct benefits are a fairly safe bet. For some readers it might be slightly overexplaining, but to others it could be pointing out helpful implications.
Knock-on benefit
A knock-on benefit is the reason why the direct benefit is useful. It’s valid if your feature is something very unusual, such as if it’s augmenting a process in a way that’s not obviously beneficial.
Be warned, going up to this level can get you an eye roll in response if it’s misused. You also need to make a clear cause and effect link between the feature and the knock-on benefit.
Top-level benefit
It’s almost always best to avoid these. Yes, your feature might mean better testing, which means less time fixing bugs, which means more time shipping features...but “ship more code” will always feel vague and unhelpful.
If you’re the market leader where everyone knows what you can do, you can get away with this. Otherwise, don’t.
Just because Docker can get away with top-level benefits like this, doesn’t mean you should!
Example: Over-explaining stats
The introduction had this screenshot from CircleCI. Most of their site is solid, but this jumped out as too salesy.
How to fix this section?
The image does a great job of pitching the upgrade from free alternatives such as GitHub Actions, but I don’t think the Top Level Benefit is necessary here.
I’d probably go with Feature-Only, but even restricting it to the Direct Benefit gives a more sensible section such as:
My imagined alternative, focusing on the direct benefit
The benefits of a faster build don’t need explaining. Instead, they could write a simple subheading that is more directly tied to the speed and use the body copy to help reinforce how they achieve the claim.
What do to if it feels a bit flat?
Just listing a feature can feel underwhelming. If that’s the case, you have a few options:
Use hyped-up language
Go more top level with the benefit
Pull out exciting details about the feature
It’s easy to fall into option 1 or 2. Our “speed of creativity” example is a combination of both.
Option 3 is the hardest but worth the effort.
If the marketers at Circle CI worried that the build speed section isn’t compelling then they could have pulled out better details. Maybe they could give specifics about how it manages to build faster, or they perform a more statistically significant speed comparison test.
If you feel the fluff creeping in, take a step back to consider what details you can include to make a section more compelling.