It’s easy to caricature the relationship between marketers and developers as something like, “marketers are from Mars, developers are from Venus,” where they even don’t speak the same language. Or the (non-)relationship is painted as being downright antagonistic, with oblivious marketers trying to crowd their unwanted messages into the attention space of contemptuous devs.
How often have you been told, “Developers hate marketing?” More than once, I’ll bet.
So it’s not surprising that marketing to developers can feel like you’re trying to navigate a dangerous mountain path, where the signs that can lead to safety — or danger — are written in inscrutable hieroglyphs. “If I only knew their language,” you might think, adjusting your pith helmet. Like there was a Rosetta Stone of some kind that would let you translate your pitch into DevSpeak.
But seriously, it’s time to get over this mythology. We’re in the age of the Cloud, when all kinds of businesses, not just traditional technology vendors, need to win the buy-in of developers.
And that means developer marketing is part of the new marketing mainstream; we’re not journeying to an isolated Galapagos (or even a “Land of the Lost“) where the normal rules don’t apply.
Sure, the developer community has a distinctive argot and its own cultural norms, but you know what? The basic lessons we know about effective marketing still hold up.
The challenge isn’t language, but empathy
Consider inbound marketing. Now, I’m a natural skeptic about jargony bandwagons, but there’s a good reason this label took hold: It’s shorthand for how to market in the age of the internet; it’s a codification of the basic principles of how we should support our customers’ natural goals as they seek out useful information to help them make smart decisions.
Done right, it’s empowering for them, not just a way of enabling a commercial transaction.
Content is fundamental to inbound marketing. But the notion that it’s a Faustian bargain (“Let me tempt you with this white paper, but at the price of your personal data so I can spam you into submission!”) — just (click)bait for the (sales)hook — is assumed to be one of the reasons “developers hate marketing.”
But great content — for instance, relevant and informative e-books, guides and white papers — works as marketing tools because it truly helps a prospective customer be more successful.
Consider the content you’ve probably searched out yourself. If you’re a tech product marketer, it might have been a competitive landscape overview, like a Gartner report; if you’re an email marketer, maybe it was a how-to or best practices guide for optimizing across email clients.
I just read a thorough review of a new crop of analytics tools, some of which may help me understand how my customers use our website. I read it because it was written with my point of view in mind. It had empathy for the prospect’s wants and needs.
And empathy is the foundation upon which you build an effective marketing program. Even — especially — if you’re out to reach developers.
Listen before you speak
Guess what? Developers only want the same thing as any other customer: resources that help them do a great job. “What are the options out there for handling this part of my application’s data?” “Has anybody else worked around this bug I’m running into?” “What cool ways are other developers improving their toolchain?”
What’s developer-focused content? It’s code samples. It’s how-tos. It’s personal blog entries by other developers, walking through their approach. It’s talking with peers in social environments like Slack or Stack Overflow.
But first of all, to understand what they want, you’ve got to stop putting the cart before the horse: Stop talking and start listening.
Even if developers really were from Mars, speaking a whole different language, isn’t listening intently the only way you’d figure out what they were saying?
Eight tips for marketing to developers
• Learn to listen. Practice an attitude where you’re listening to what they’ve got to say, asking questions, while never breathing a word about A/B testing your tag lines or value propositions.
• Buy a developer a beer. You probably know one, right? Just sit down with a dev who’s in your target audience and have a real conversation about what kind of content would help him/her do a better job. Then even follow this up with focus groups or meetings with existing customer devs.
Hear what their challenges, hopes and dreams are, how they hope to impress their CTO — anything that gives you insight into how you can help them.
• Meet them where they chat, share and learn. That’ll mean online, at Quora, Stack Overflow, Stackshare, Dzone, even Reddit and other sites. And look for specialized sub-communities that might be focused on your segment or product type.
If you can handle conversations that get deep into the weeds about coding, try GitHub or one of the many platform-specific IRC channels out there.
• Avoid creating noise. Don’t waste their time, whether it’s by blathering in chat, spamming their inbox or using clickbait content that doesn’t offer anything original or useful. Anything you say should demonstrate constructive value and relevance.
• Know thy product. One of the biggest irks for developers? Getting waylaid by marketers who don’t even know their own product (or category) well enough to do a decent job of explaining how they can help the developer.
• Ban the b.s. Developers have a unique penchant for calling out any hyperbole or blue-sky claim: “You’re telling me your widget is the fastest? Let me just sit down and bench test that …”
They’ll test it, compare it and — just as importantly — talk to their colleagues and share their observations in chat or blog. If you’re speaking truth, they’ll spread the word; if you’re blowing smoke… well, I think we all know the meaning of the word “eviscerate.”
• Give them a worthwhile trial. Without asking for any commitment, let developers give your product an extensive trial. That’s not just good marketing; it’s good product refinement, too.
Many devs will happily diagnose bugs, suggest upgrades or let you know why you’re not a good solution for their needs. Plus, many aren’t in a position to be the buyer, but it’s their post-trial recommendation that will carry weight with their IT purchasing manager.
• Gather testimonials. If we haven’t made the point, it’s this: Developers listen to other developers. So get solid testimonials from satisfied developers who can clue in other devs on just how good your product really is.
But as with anything else, the “no-b.s.” rule applies here, too: Any testimonial has to be authentic and in-depth.
Comments