Maybe this should go into #links, but I saw this post on HN on the short article “Benefit Layers”, which talks about how to best present your value preposition when trying to market a devtool to developers.
The gist of the article is that you should present the value you offer in one of three “Benefit Layers”:
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.
This is very interesting to me, as it mirrors the frustration I’ve felt with a lot of tools where the initial exposure just felt like marketing without any information.
The way it’s implemented on the Nix homepage right now is pretty decent:
Reproducible
Nix builds packages in isolation from each other. This ensures that they are reproducible and don’t have undeclared dependencies, so if a package works on one machine, it will also work on another.
Declarative
Nix makes it trivial to share development and build environments for your projects, regardless of what programming languages and tools you’re using.
Reliable
Nix ensures that installing or upgrading one package cannot break other packages. It allows you to roll back to previous versions, and ensures that no package is in an inconsistent state during an upgrade.
I think Nix is complicated enough that just presenting base features would be a bit difficult to understand, so these simple paragraphs explain the direct benefits and knock-on benefits. So as an intro this is quite good. But the way the features are presented right now is cumbersome, watching the codecinemas takes time and doesn’t allow me to glance at the functionality, though I’m not sure how that could best be improved.
The HN thread also has this interesting comment:
Developers are sick of vague promises and wary of black boxes.
Instead:
- Demo - reach Wow! in <10 mins
- Explain how it works
- Show how real companies use in prod
This seems like a great angle for an introductory talk, and I’ve started working on an outline for presenting Nix at my employer with this.
).