Geva Perry's Blog

Marketing to Developers, Part I

Marketing to developers (software , not real estate) has unique challenges. That may seem obvious to some, but I was surprised to see how little information is out there about this topic. A Google search on "marketing to developers" yields a mere 331 results, only a handful of which are relevant to the topic and none of which systematically discuss it. Searches on "marketing to programmers" and "marketing to software engineers" provide even poorer results.

And of course there are no books specifically about the topic.

The most useful result I found were the comments on a blog post by Joel Spolsky (of Joel on Software fame) from about 2.5 years ago. Joel was asking for advice on how to market software to programmers and received some good responses.

The topic is of obvious interest to me as chief marketing officer at GigaSpaces, a company that makes an infrastructure software product intended for use by software developers.

So I plan to write some more on what I've learned from more than a decade of being involved in marketing to developers in one capacity or another, but in this post I'll just cover why I think marketing to developers has some unique challenges:

• Developers always think Build-or-Buy. The first thought that crosses a developer's mind when you try to sell them software is "I can build that myself - and better." The build-or-buy decision may be present in other industries, but nowhere is it as dominant as when trying to sell software to developers. As my old boss, Dave Parker, used to say: "At the end of the day, software is just ones and zeros." Meaning, you can code anything with a relatively small up-front investment. It's an extreme form of the Not-Invented-Here mentality, which prevails in many engineering organizations, combined with the fact that with software -- at least seemingly -- building yourself is a feasible option.
• Developers are tinkerers. They love to tinker with the product before they buy. If they can actually build a prototype, they will. If they can look at the source code, all the better (and it has nothing to do with any advantages of open source -- it is pure curiosity)
• Developers are religious. Technology religious, that is. Again, this may exist in other businesses, but software developers are down right zealots: Java Vs. .Net, Mac Vs. PC, SOAP Vs. REST -- to name but a few of the holy wars developers wage. You've got your open source fanatics, who sacrifice their economic prosperity for the cause. You have your Linux crusaders, trying to liberate the Holy Land of OS from the Microsoft infidels, or some other perceived "evil empire."
• Developers are cynical. They will be particularly resistant when they believe they are being sold to or marketed to. Now, this is becoming increasingly true of the general consumer populace, as we are told repeatedly by books such as The Cluetrain Manifesto or gurus such as Seth Godin, but it is especially true of developers. They will always try to challenge the marketer or seller, they will look for the weakness points and the corner cases.
• Like all experts, developers suffer from the Curse of Knowledge. I am referring to the Curse of Knowledge as described in the book Made to Stick. It means they cannot imagine what it is like to not know what they do. In all of my career I cannot recall a single software engineer who could really explain a software issue to non-techies in a simple way.

Obviously, some of the items above are gross generalizations, but I still think these are useful observations from a marketers point-of-view. Also, I want to apologize in advance if the overall points above may seem to some as negative towards developers. That was not at all the intent. I was trying to list the unique challenges of marketing to developers -- not the joys of marketing to developers. We are obviously talking about a profession whose members, as a rule, are highly intelligent, highly educated, open-minded and pleasant to work with.

So this is a first crack at the topic. In a future post I will address some of the strategies and tactics I've found useful when marketing to developers. As always, if anyone has any further insights, ideas, objections or comments, by all means.

UPDATE: This update refers to my first bullet above "Developers always think Build-or-Buy" [and a re naturally inclined to build]. After I published this post, I read the We See No Silver Bullet post by Bill de Hora. Basically Bill argues against Scott Rosenberg (author of Dreaming in Code) and his assertion in this Salon piece that programmers rather code themselves for wrong reasons. Bill claims they do it for right reasons. Whatever the case, it reinforces my claim that this is indeed the situation. From a marketer's point-of-view, you are facing this issue. And from personal experience I think that both are correct.

In any case, one of the comments in Bill's blog led me down a rabbit hole to this post by Jonathan "Wolf" Rentzsch, which led me to this one -- Programmers Don't Like to Code -- and the ensuing Digg post and discussion. Apparently this is a highly debated issue (not whether programmers do it, but why).

Update: more on Build Vs. Buy

Update: Owen Taylor's perspective on Targeting Developers

Internal Long Tails

When a few of months back I finally got around to reading Chris Anderson's The Long Tail, I didn't think it was particularly relevant to my marketing job at GigaSpaces. Don't get me wrong. It's a great book: well-written, insightful, well-researched. I just thought it is a good airplane read or lazy Sunday afternoon read, not relevant to my job as many of the other books I read. But somewhere in the back of my head it was gnawing at me that surely it must be relevant to GigaSpaces somehow.

About a week ago, returning from two weeks on the road for our two sales kick-off events for the Americas and EMEA/APAC , I was finally catching up on my blog reading. First, I read this post from Anderson. And more importantly, this one from Seth Godin. And finally it hit me.

Godin's is the one that really got me thinking about this, although his point was quite different from my conclusion. Seth is talking about how big companies should take advantage of their size and let their many employees have at it and blog to promote the company's long tail products -- those niche products that are not on the company's current promotional radar (more or less what he says).

But GigaSpaces is not a big company. And it really has only one product (with several editions), which is the reason why I didn't think the Long Tail concept applies to us in any way in the first place. But there is something about our product that lends itself to a long-tail-kind-of-thinking that I didn't see anyone address: It's an extremely feature-rich product. Meaning, it has an internal Long Tail.

So our marketing challenge is to decide what is the message we want to send out. Or in other words, which of our product's capabilities and benefits do we NOT emphasize? It is a decision we face every day with every document that comes out, even the "About GigaSpaces" at the end of a press release. And it is a bit like choosing which one of your children you love the most (or the least).

Thinking with a "Long Tail attitude" to marketing you can try and develop an "abundance" mentality. Sure, there will still be the key 1 or 2 messages  -- in our case scalability and performance -- you put out in your most public announcements and marketing, but we also address more niche messages in our various white papers, on our public wiki, blog posts, focused events (such as Java and .Net User Groups).

We are currently in the process of redesining our web site, and I am thinking about how we can take this approach. One idea we've been discussing is creating sort of "portlets" -- mini-portals -- for people interested in our product for the use of specific features or applications. That's a good start, but some of these things can be quite obscure, so you're still limited in what you can cover. Let me give an example.

One of the products capabilities is handling a situation software engineers call "slow consumer." We didn't mention this feature in our Version 5.2 release announcement, but we did put it in our more technically detailed TheServerSide.com posting. This prompted a question on the discussion thread, and eventually this blog post from Nati.

So blogs are obviously one great way to market the long tail of your product features, but I wonder if anyone has written something about approaches to this issue in a more systematic way. This is something I'll be thinking about in the coming weeks, and if anyone has any ideas they are most welcome.