4 things developers really wish every marketer understood
Contributor Josh Aberant shares the good, the bad and the ugly of developers’ marketing experiences.
The challenges (and myths) of marketing to developers can feel boundless at times. Indeed, the apparent chasm between marketers and our technical customers can be daunting — and the stereotypes sometimes run both ways. But the remedy is a deceptively simple one: empathy.
We’re hearing a lot about empathy (or the lack of it) in popular and political culture today. At heart, it’s about listening to another person tell you their experience. It’s about listening to someone else’s point of view — without interjecting your own.
So rather than blathering on with my opinion about what developers should want from marketers, I thought it might be better to let some of the developers with whom I work tell me in their own words about their marketing experiences: the good, the bad and the ugly.
When I asked in our internal and developer community Slack channels, I wasn’t disappointed. Here’s some of what I heard.
I am not your nerd
The first response I received when I asked what marketers should know about developers was very personal:
“I’m not a stereotype. I’m social, pretty well-adjusted, and don’t respond only to Star Wars memes.”
Just like software user personas, buyer personas have their place. They can help focus efforts and messages and remind us that we’re marketing to humans, not rows in a leads database. But to be honest, I’m not a huge fan. For a practice that’s intended to create empathy for our customers, it often doesn’t work that way.
The reason is pretty simple: Most of us rush through that empathy-building exercise. We reduce personas to stereotypes. We use mental shorthand to project what we think our customer looks like, rather than… I dunno… asking and getting to know them.
So — “developer.” If you’re marketing software and services infrastructure, develops systems or development tools, you probably have defined a developer buyer persona somewhere in your marketing plans. Be honest: Is that guy (yes, guy) named Sheldon, a kinda geeky comic book fan, a gamer and a cola-guzzling introvert who doesn’t really enjoy the fresh air of outdoors?
Yeah. It’s time to retire the tired tropes of what a developer looks like.
These are not the memes you’re looking for
If you’re marketing to developers, I bet your Twitter feed has included its share of puns about the Force. And references to Azeroth. And perhaps a bit about Bash. Sure, fine, but what’s the thing developers wish marketers would stop doing?
“Pretending to ‘get’ certain ‘lingo’ and trying a little too hard with humor.”
We’ve all experienced the awkward feelings (or eye rolls) that come with not being quite in on the joke. Or when an outsider appropriates a subculture’s language. It doesn’t work, because it’s not authentic. And authenticity is a key part of empathetic communication — with developers, or anyone else.
So if you (yes, you) can authentically crack wise about Emacs and natural 20s, great. Own it. But don’t pretend to be something you’re not. Authenticity — marketing in your natural voice — beats faking it every time.
Gotta get it right the first time; that’s the main thing
I hope it’s self-apparent that if you’re a marketer, you need to understand your own product. Like authenticity of voice, technical accuracy is crucial if you’re marketing to developers. Don’t try to get away with faking it:
“Sloppiness — trying to talk about tech but doing it wrong, anything that communicates ‘this was not written by your fellow engineers’ — it’s going to tank a pitch pretty fast for me.”
Take the time to learn what you’re selling. If your business is making a technical sale, you’ve got to hire marketers who have the technical knowledge (and even working development experience) to communicate with precision.
After all, what’s the alternative? Websites and product pitches that betray a fundamental lack of knowledge about your developer customers’ needs and how your solution works. That’s a deal-breaker.
Get out of your own way
Creative marketers love visually powerful ads; a benefit statement that also works as a subtle dig at a competitor; or expertly rendered feature pitches. But what do developers actually want when they’re in buying mode?
“Tell me a clear price. Give me direct access to trying something as quickly as possible without getting in my way. Show me what the app looks like and what people do with it. Be straight with me, and I’ll be straight with you.”
Could this developer’s request possibly be more clear? I can’t tell you the number of conversations I’ve had in different organizations where the question of whether to publish a transparent price list was the right thing to do. (Answer: yes.)
And certainly, every step we can take as marketers to help reduce both the procedural barriers and the conceptual “mental taxes” that get in the way of getting up and running in our apps will better serve the needs of our developer customers.
If marketers’ product content and the sales pitches that follow come at the price of speaking to developers’ actual decision-making process, then it’s not effective marketing — it’s solipsism.
And that brings us back, full-circle, to the notion of empathy. It’s understandable that a lot of marketing to developers falls flat. Not because it’s not thoughtfully conceived or well-executed, but because it’s speaking to and functioning for a different audience than we claim it to be.
Think about the clear advice these developers shared with me. How well does your marketing fare when examined in that light? I’ll be candid — my own is a work in progress, but I strive to achieve the straightforward tone and clarity these developers describe.
So, honestly, who is our marketing serving, our customers or ourselves? One of those is the opposite of empathy. Until we get that right, developer marketing will remain a frustrating exercise for us and our customers alike.
Opinions expressed in this article are those of the guest author and not necessarily Marketing Land. Staff authors are listed here.