I’m just about the give a short presentation on developer relations and marketing at our HCTS conference. For those who didn’t make it, here’re the slides and the “script” I typed out. As you may recall, I wrote a large report on this topic published back in August. It’s been fun talking with people about over recent months.
I often type out a “script” for presentations, not something I actually read, but just something to figure out what to say. Here’s the script for this one:
Hello, I head up the infrastructure software team at 451. Part of that is focusing on software development, developers. Back when I did real work, I was a programmer for a decade, so to me, the old saw applies: the answer is developers, what was the question?
More seriously, if you study the IT industry as I do, you notice a common trend: developers seem to gravitate around successful vendors and platforms. Sure, there’s a chicken and egg, cause/coorelation issue, but if we look at some big names, it’s obvious that having the good graces and favors of developers is key to making money in for many technology companies.
In the 90s and 2000s, Microsoft’s was a developer powerhouse, and still is, with countless applications written on its platforms. AWS rose to prominence rapidly from nowhere largely fueled by developers desire to run application on their platform. Similarly, Softlayer (now owned by IBM), expertly targeted developers as a core constituency. And, of course, there’s Apple, which is really cheating as an analyst to use as proof of anything.
We’ll get to some lesser known examples, but the message here is clear: developers matter a lot in the technology world and learning how to “market” to them is key for many vendors in this space. That’s what this talk is about: how to market to developers.
Now, as much as I like to be hyperbolic and categorical, not all technology companies need to worry too much about developers. Aside from the obvious cases – you’re selling middleware, IaaS, or PaaS – there’s an interesting heuristic to use to figure out if developers matter to you. As this timeline from Geva Perry shows, the role of developers in IT buying has been enabled by friction removal in the IT procurement cycle. If I have to go through months of fancy steak dinners and procurement paperwork, developers will have less of a role. If I can just download a database, install it in the public cloud, and go, there’s virtually no friction…and developers will more and more be the primary movers for IT procurement decisions.
Again, metered IaaS is an obvious match, and PaaS, of course. Look at your go-to-market – really map out each step it takes from concept to quote to cash – and see how much friction there is. The less friction, the more likely developers will be an important constituency.
Here’s two examples of that Heuristic at work: DigitalOcean and Atlassian.
DigitalOcean is one of the handful of SSD-fueled cloud providers out there that developers are flocking to. They do excellent product and developer marketing. Just like there’s less friction when you remove spinning dishes, the IaaS nature of getting to a blinking cursor in minutes to near frictionless. Developers love the easy performance boost SSD brings and the love how easy it is to sign up. As our recent reports on them show, this has resulted in 30% m/m growth and rocketed DigitialOcean to the 5th largest hosting company in the world according to Netcraft.
Atlassian is another example. They’ve been at it for years, putting out developer tools (requirements tracking, version control, etc.). They’re famous for having “no sales” and instead have removed so much friction from their GTM that developers can easily get their tools. And the tools are good. As you can see, Atlassian has been able to grow revenue from $59m in 2010 to $149m in 2013. That’s amazing consider that, you know, “developers don’t pay for anything.”
Both of these companies are good at developer relations and marketing and have harnessed developers to grow revenue. Let’s look at some highlights from my recent report going over tactics.
First, let’s define the goal of developer relations and marketing. I borrow this idea from several folks in the field, and it’s that you want to establish your technology as the de facto standard. Think Windows, HTML, Linux, the LAMP stack, the iPhone. Each of these became one of the top short-list choices for developers. Not all of them were “industry standads,” or even the #1 in the market, but they became de factor standards.
The result is that developers do all these activities in my Smart Art here:
- they consider using your technology
- they try it out
- if they like it, they word of mouth it
- they’ll purchase it (if it’s available to buy)
- and they’ll use it
This is pretty classic stuff, but the point is focus your goals around establishing your technology as the de facto standard. You can do other things, but it’ll be more difficult: you’ll have to convince people that your “exotic” thing is needed, like high-end Unix boxes vs. Linux and Windows.
How do you do this? A lot of hard work and time. Really. There are no simple solutions. As analysts marketers ask us for the quick wins a lot – esp. towards the end of the quarter and year ;)
To give you a sense of what a developer marketing program will look like, here’s some examples.
You’ll do classic things like advertising
You’ll provide white-paper level research to help developer understand and evaluate your offering
Training is a large part of developer relations, and also a revenue opportunity: you’re indoctrinating people
You’ll also need to understand developers needs. Right now, that has a lot to do with APIs and documentation for how to use them. APIs are becoming the de facto standard for how developers interact with platforms, and you’d better figure out your plan there. You’d think docs were obvious, but it’s shocking how often vendors miss this.
At the code level, developer marketing is also often done in code. I call that “code as marketing.” You might source extenstion, do some biz-dev to get others to do it, or lucky enough that your community can do so.
And there’s lots of publishing. Lots. The Internet is the primary channel to reach developers and stuffing that channel is all about content.
Staffing wise, this could be a partially dedicated person, but pretty quickly you’ll want someone fully dedicated who can keep all the threads going in their head. Also, they’ll start to establish a personal brand, credibility in the space. Developers actually like people, just developer-y people.
The team can obviously grow. SAP’s team is massive, and it has massive effect.
So, you’ve got a notion for what it looks like. How do you plan what to do?
Don’t just throw up a blog an start typing. Take some time to plan. Get some ice-tea and patinad table like these hipsters here and establish goals.
And don’t forget that you’re doing this for business reasons. Talk with sales to find out how you can help them with deal flow and closing. Talk with product management to see how you can be a bi-directional channel for driving product direction.
Know what you want to accomplish with your developer marketing program so you can measure and meter funding. Once you have the developer in hand, you need to pass them off to someone who can make money from them.
Obviously, you need to establish metrics so you can track progress and argue for more budget and corporate oxygen. I find that most people rarely base-line current performance how they’re currently doing before starting a new project, so that’s a good start: otherwise how do you know if it’s working or failing?
Finally, make sure you understand who “your” developers are. One off project lone wolves in coffee shops, startups, other vendors, enterprise developers? It drives what comes next.
So, what appeals to developers? It of course depends on how long their beard is.
More seriously, while there’s different types of developers, there are some core value props that usually work.
Developers like speed. They want to do more with less, they want things to compile quicker.
Many of them (not all!) want to try out new technologies. Their worth is all locked up in their head, so each time they learn something new, they become more valuable. Any many of them just like learning.
To that end, they like stability in their knowledge. It takes a long time to learn Java or node. They want the investment to pay off. Don’t be changing things around all the time.
They like solving riddles and puzzles. That’s what programming is, what tends to separate it from more “factory” like work.
The business side is simple: someone else comes up developers and tells them the requirements, what the code must do. This is where a lot of “enterprise grade” features come in like compliance, audit, and regulations. Developers generally don’t care about that, but they like satisfying the requirements.
And, while they may act – and dress – like they care, they care a great deal about getting paid. Those 128 gig iPhone 6 Pluses don’t pay for themselves. Developers rank themselves by pay like any one else. Money means freedom to developers, like most people.
Let’s close out by highlighting a few tactics from the report.
First, show up! Developers are very social, esp. online. There are numerous “communities” that they rely on for their work and entertainment. GitHub is popular, Hacker News, Stackoverflow, and numerous other sites. Large developer marketing programs like SAP even setup their own, highly successful communities.
We did a survey of the early mainstream DevOps market recently and found some interesting results there. Obviously we like the analyst reviews, but it also shows that “traditional” outlets are valuable to.
Find where developers are and go there.
So, when you show up, what’s the work product?
Content can take many forms. Blog posts are good, podcasts can work for certain types of developers if done right.
And look at everything as a “store front”: support forms, your docs, demos, and other “marketing material.” All of this, if tracked and experimented with properly is can the ether your developer marketing program flits about in.
Books can be oddly effective if you write one that’s a definitive “how to” of a narrow topic. I profile one on code reviewing that helped drive growth for SmartBear before it was acquired.
Presentations, webinars, and talks are always good as well. Check out what goes on daily at InfoQ. It’s documenting the tribal knowledge out there, which is incredibly valuable in a knowledge economy like developers.
Here’s some specific topic ideas, all of them good.
Let me highlight one, a wicked problem solved.
Back in 2012 when Thailand was flodded, Backblaze had a problem getting cheap hard-drives from its supplier. So they arranged employees to travel around the bay area and beyond to buy hard drives at CostCos and Best Buys. Developers loved this story. It’s a classic puzzle to solve in an almost subversive way. I know many, many developers who love and use Backblze.
Stories like this come out from other companies.
Also key is explaining your “philosophy” on the industry and even culture. To go back many years, as it was called then “37 Signals” used their philosophy of rebelling against Enterprise Java to help advance the adoption of rails and their own products.
So, other than reading my full report and doing crazy amounts of consulting with me, what are some tangible next steps?
Understand how developers will drive revenue and growth. How do they fit into your value chain?
Figure out who these developers are. There’s probably at least three types, if not more. Know them, and how long their beards are. And then go talk to them!
Start with some cheap experiments. Have a beer and write-up what you think is wrong with how things are done; record a screen-cast of an obscure feature in your platform; rise-wash-repeat. Just do something!
As you learn what works, get a regular cadence for content production. Blog posts, podcasts, docs, code, whatever works.
Finally, never forget that your job is to move product. Engage with sales and product folks to fit into their pipelines and process. If you round up all this developer favor, how do you deliver that into your companies money makers?
So, that’s a really quick overview. If you like reading, there’s a full report on the topic available. There’s a lot more in there like:
- types of developers
- the role conferences play
- more on different channels and mediums, topic ideas and content
- and several large and mini-case studies of what’s been successful at for other companies.
Speaking of case studies, we’ve put together a panel of folks who’ve been successful at developer marketing and relations and we’re going to debrief them now to help you understand developers more.