# Benefit Layers: How to avoid sales fluff in devtools *I'm excited to publish our first guest post from* [*Zach Goldie*](https://www.zachgoldie.com/)*! 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*](https://news.ycombinator.com/item?id=36716258)*!* --- 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](https://lh5.googleusercontent.com/llMGMIuD0GdAQgBAOnGBbiQPzHd3tD39djpd7jPg4qydHAaXn-aTjEZ0dCL2ecBZlP9qCkx4yG0xkrZdAYF-_i_vJuYrcjmCQ0SAGYhalxDiiV0r3V9HBgttZhKy2wzjRlBXG_lQY47pgyCP5D-Mcc8 align="center") *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”. ![](https://lh3.googleusercontent.com/MqaGP5dBsYhrFdDNB5SizbqsYU30YwCf-tOVRh1Pk8-2J0icTqlxlE34e_8CJPphSu1oOVm4edxzJWqi8FtBomWCerISUlucSng892dsrCbjVxN07tTODLDUgadKBzxrt5d_Z_W1TOuBwbQXyYRtdyY align="left") 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: 1. Competing on specs, where more/faster is obviously better. 2. 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. ![](https://lh6.googleusercontent.com/4aRHDC63kOGer5k1KrfChcdXMKJ2AkLReEI4ubT2-VRJ0BMW3UqPFlRhXdifczTwoA4b3WnCFLjErkBMaNg_EweP2zw-EnvorKxZuTKfs5s1Aj62vlYt7Rl2O48_vWcd8j3gsBUjuk5WyaXO4Ivz7go align="left") *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. ![](https://lh4.googleusercontent.com/ynRwX82rc9nxgkt_CyPeXPWLFaUgY7Md7NoSjRfDDcSoAR4VSeRqVVTup8SOrUdZzodJTeoaGbTaDUTeRu04mOQbPlqNtEyM73TIA7yzKFDPQ2xPUVjE3tjvEGqKtBQX9eOBjv4Dbo2bT_-x3pls1Dw align="left") *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: ![](https://lh5.googleusercontent.com/Lf8ujBSGjMuepZAQaAdWg9QAtCJ1ag5HXd96y-milMH_Nvi3jCuDTSsSTxKk0wO5A-9onsibElE1_F31ODSBHBLP5zB5uBqUm5M4LxIPyENjj0hIZoLTtqKb63SFGcc8W9XAJLq5F6ndXDpD9Ohd_sk align="left") *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: 1. Use hyped-up language 2. Go more top level with the benefit 3. 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.