One thing I've consistently had to relearn in developer marketing:
"Talk benefits, not features" doesn't work!
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
and that really resonated with folks (heard some really good feedback from senior github people). excited to return to this topic with a better framework (https://pbs.twimg.com/media/F03sDA6agAEBf_M?format=png&name=...) for when to communicate with benefits vs features
But drinks barely have any features you can market. If they do, they're front and center (less sugar or calories, more vitamins or minerals, sparkling or non sparkling)
Same for cigarettes and other similar products.
Some people may prefer the flavor of one product over the other, but at the end, it's purely about lifestyle and the feeling of a brand, and that is shaped by marketing.
So if I create a brand around a drink I can just run a few commercials on TV to associate my brand with something people want (like I don't know, being percieved as sexy by the opposite sex) then I will have a successful business?
It only appears to work if you think that kind of advertising is how they got to their market position. Usually it's not.
Let's Docker for an example.
Docker did not get adoption because of some cliche marketing on their landing page. It got adoption from people doing tech talks and tech demonstrations and several companies writing blog posts about how migrating to Docker saved them from the headaches of deployment they were having before with the ad-hoc systems.
Complex enterprise tech gets sold by other means, usually personal relationships with key decision makers, and maybe some amount of bribery, who knows.
Docker failed to sell its commercial products to enterprises relative to the OSS adoption of its container runtime, at least at the venture scales they committed themselves to
Afaict what was being sold:
* Artifactory (hub): plenty of companies doing fine.. for product different than what docker did
* DC OS (swarm): managed k8s etc doing fine too.. but diff product again
They seemed close to PMF for both... But never quite hit it?
Selling to enterprises is hard.. I'm not sure what the lesson is here beyond git stars not being revenue, nor guaranteeing that it can turn into revenue. Successfully building one thing but selling another means you have to do 2 hard things not just 1.
Maybe a good analogy: Bloomberg has great reporters whose content goes out for free... But that's not what sells the terminal and data feeds
I’ve never sold dev tools, but this resonates with me as a buyer.
The other thing that I want to know, where I’ve had remorse in the past, is how much effort it’s going to be to integrate the tool with my current processes and workflows. I don’t want to change my processes, and I don’t want to find that I cannot get that wow because I’m using this homebuilt process over here or this specific third party tool over there or because we’re migrating to cloud in 3 months.
I don't think this is true... It's more nuanced than this. Developers are much more skeptical of a "benefits" pitch, and care more about a "features" (and limitations as mentioned above) pitch. However, if you're just pitching a developer, you're probably only pitching the user, not the buyer. The buyer VERY much cares about the benefits, otherwise they're not buying. The buyer won't using a single feature, so that type of marketing is lost on them.
This is the challenge: the right message (features or benefits) to the right person (user or buyer) AND at the right time!
Thank you so much for this! This structure is so simple, but super effective in helping me lay out my own thoughts. I'll try this during my next internal presentation. While not a sales pitch, I am trying to get people hooked on a tool I use a lot and really like, but it's so complex that I really struggled to structure my thoughts about why you'd actually want to use it.
One thing I've consistently had to relearn in developer marketing:
"Talk benefits, not features" doesn't work!
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
and that really resonated with folks (heard some really good feedback from senior github people). excited to return to this topic with a better framework (https://pbs.twimg.com/media/F03sDA6agAEBf_M?format=png&name=...) for when to communicate with benefits vs features