TL;DR marketing to developers is hard, and you are probably doing it wrong.
The unstoppable rise of the developer
My former Acquia colleague David Churbuck introduced me to RedMonk’s Steve O’Grady and his 2014 book about how developers are taking over the world, called The New Kingmakers. The idea is that successful companies empower developers to solve problems instead of getting in their way by dictating legacy technology and process.
It sounds obvious now, but it wasn’t so long ago that everyone who sold technology started at the top of an organization, typically the CIO, and worked their way down. Important technology decisions were made on the golf course or at the steakhouse, and companies like Oracle, IBM, and SAP sold billions of dollars of enterprise software this way for decades.
But the explosion of open source and cloud changed everything. Instead of waiting for technology to be handed down by the CIO, developers could now pick whatever best product they wanted, and quick deploy them on AWS, Heroku, DigitalOcean, etc. We even coined the term Shadow IT to describe the stealth adoption of unsanctioned technology. O’Grady captures this disconnect nicely in a Venn diagram:
So while the balance of power has clearly shifted to developers, many enterprise technology marketers continue to chase the CIO with old school enterprise software marketing tactics. Does this sound familiar:
First, we’ll create a whitepaper and put it befind a form. Then we’ll spam errr syndicate it to a bunch of opt-in(ish) email lists. Then our BDRs will call them Schedule a demo. Profit!
Ditch your traditional tech marketing playbook
One of easiest ways to fail at developer marketing is to fall in love with marketing best practices that were formed by companies who don’t sell to developers.
I’ll be honest: I’m jealous of my peers at companies like HubSpot and Marketo who market to marketers. It just seems so much easier. I know how CMOs are measured — how we buy — the language we use. I’m a good proxy for marketing to other CMOs. But I’m a horrible proxy for marketing to developers. I’m reasonably technical; I was a CS major, ran technical sales at a few enterprise software companies, and I’m currently the de-facto WordPress developer at RapidMiner. But I’ve never had to deploy code hundreds of time a day, scale a React.js application, or secure a bunch of Docker containers.
So just running the traditional one sized fits all tech marketing playbook isn’t going to work. The developer audience is particularly wary, and as O’Grady puts it:
Developers have, out of necessity, built up an immunity to traditional marketing tactics. Print ad placement doesn’t work because they spend most of their time online. Online advertising is ineffective because they block ads. Forced registration for white papers fails because they don’t care about your high level whitepapers. Media messaging is ineffective because the developers know more about the technologies than the reporters do. Analyst webinars are ignored for similar reasons. And if you throw a conference featuring your executives talking about their projects, expect your WiFi to crash as developers tune out the talk and hack their way through the sessions.
Respect the community
GitHub has millions of users. Over 100,000 users contribute to Drupal. MongoDB has been downloaded 20,000,000 times. RapidMiner has over 70,000 active users a month. The single most important factor in the growth of companies who sell to developers is the strength of the community. Even Microsoft gets this, open sourcing the hugely popular .NET framework to encourage even more adoption.
But successful developer communities aren’t built by marketing, and sometimes happen in spite of it. They almost always form organically around a product/project that developers love to use, combined with a a shared sense of purpose by the community to do something meaningful.
The danger comes in treating your developer community like a CRM or marketing automation system. Don’t expect that you can convert them with a lead form, “nuture” them with emails, harass them into taking a demo, and close. This approach works to a point, but it won’t the create the kind of sustainable value that comes from having a world-class developer brand.
Go into your developer marketing efforts knowing that many of the positive effects of building a strong developer brand are frustatingly hard to measure. But at the end of the day, developers only really trust other developers. You’ll have to have some patience to get the measurement right, and have conviction in the connection between longer term brand investments and the advocacy and revenue that comes from them.
Great marketing starts with great documentation, and deeply technical content
Your product might be the most important innovation since Sir Tim Berners-Lee’s World Wide Web, but if no one understands how to use it, you’ll quickly become irrelevant. Treat great documentation the same way you treat building a great user experience. It’s that important.
For example, Twilio, Stripe, and Soundcloud all have amazing (and up to date, that’s really important) documentation, complete with thorough tutorials across multiple languages, getting started guides, detailed API overviews, working examples, and more. Their documentation makes it easy (and fun) to use their products and APIs.
And their documentation is easy to find and use. When I ran marketing at Acquia, we had all of our excellent product documentation behind the dreaded lead form, much to the dismay of the engineering team. I argued for it, because this form was one of the best sources of “leads” without consideration for the negative impact it would have on our developer brand.
I think @acquia jumped the shark: requires registration to read even the most trivial Drupal Commons documentation? https://t.co/UG67YTfy4w
— Stefano Maffulli @ed@opensource.org (@smaffulli) February 26, 2015
Every few months or so, Acquia’s head of engineering would ask if we’d consider un-gating the documentation. And each time I refused, armed with the data showing how many leads were sourced via the documentation form.
But I was way wrong; the kind of mistake you make when you overweight short term goals like leads with long term objectives like brand building. Eventually we did the right thing and liberated all of our great documentation and you know what? All the developers who converted via our documentation forms ended up converting somewhere else on our site — webinars, product trials, etc — if they were really interested. None of our metrics went down.
Outside of documentation, creating great developer content requires deep focus and commitment. Developers aren’t going to read your lightweight ebooks and “10 awesome ways to speed your React.js app” listicles. Your content should try to be three things:
- Relevant. Is your topic relevant to your developer audience? Bring your own developers / experts / and community into the ideation process. It’s amazing how quickly you can fill a content calendar by just asking your users what they would like to read.
- Honest. Marketers love to spin. We love to write about all the game-changing, paradigm-shifting stuff our products do. But developers don’t grade marketing on the strength of our superlatives, they want to know what you really do.
- Actionable. Will the reader do something different or try something new as a result of your content?
For example, before the launch of Drupal 8 last year we turned a series of blog posts from Acquia’s Angie webchick Byron into the 40-page Ultimate Guide to Drupal 8. It’s still a popular resource for developers looking to move to Drupal 8, and it checks all three boxes.
Another example comes from Codeship, a continuious integration startup in Boston. With a tiny marketing team, they have built a blog newsletter subscription of over 65,000 users by providing detailed technical content on a wide range of topics. Some content is specific to Codeship, a lot of it isn’t. But all of it has been vetted for technical depth and accuracy, and is highly relevant to their developer audience.
The type of content doesn’t really matter — blogs, webinars, podcasts, etc. all can work. RapidMiner regularly gets over 2,000 people to register for our monthly webinars on data science. Andreessen Horowitz runs a great podcast on a variety of technical topics. Just make sure your content is relevant, honest, and actionable and it will do well.
Eliminate all your bullshit messaging
Most marketing copy is awful. The aforementioned David Churbuck of Acquia has a great perspective on the straight talk that is missing from marketing. David is former journalist, and the founder of forbes.com:
As a corporate communicator, a so-called “content marketer,” I have a conflicted view of the disease as both a carrier and critic. Without casting stones inside my own house, let me just say that I fight a constant, daily war against the forces of derivative babble-speak, and think, after over a decade within the walls of corporate communications (after two spent in journalism), that I understand the source of the pestilence.
David blames our jargon-laden bullshit addiction on the symbiotic relationship between: 1) the press, and their need to oversimplify complex technology 2) industry-analysts who reward vendors who speak with a common language and 3) Google, and our insatiable need to rank for every possible search keyword.
Our cloud-based platform will enable digital transformation through artificial intelligence <- Says everybody
— Tom Wentworth (@twentworth12) October 3, 2016
If you are really marketing to developers, then you need to write for them too. In plain English. Without hyperbole. And buzzwords. Developers want specifics. They want to know what you do, and don’t do, and exactly how you do it differently than whatever approach they are using today.
Take a look at your product page. Does it cover the specific technical details of your product, or does it regurgitate phrases that you are trying to rank for on Google or industry analyst-speak?
My colleague Ingo, the founder and President of RapidMiner, reminds me of this daily: there are over 1500 operators in RapidMiner Studio, but you’d never know it because we’ve buried them on our site. Our goal is to use product pages to narrow someone quickly into detailed technical documentation, tutorials, samples, etc. It shoudn’t take more than two clicks from the homepage to learn about exactly how RapidMiner does logistic regression or deep learning.
Note that the total bullshit filter doesn’t have to apply to your your mission/vision statement. It’s okay to aspire to inspire. For example, Kubernetes is “an open-source system for automating deployment, scaling, and management of containerized applications.” Yeah, that’s exactly what it is. But Nginx provides the more visionary “Flawless Application Delivery for the Modern Web”. But get to an Nginx product page, and you are one click away from the deeply technical content developers expect, like this on the Nginx Content Cache.
Lastly, if you are really the leading platform for something, you don’t really need to say it. And lets all agree to stop using “seamless integration”. There has to be a better way.
Make events a core part of your strategy, but do them differently
Developers love events. They are happy to spend their nights and weekends networking with their peers. Decisions that used to get made on the golf course are now being made over the weekend at camps, cons, and meetups. But your developer event strategy has to be more thoughtful than just sponsoring a tradeshow and staffing it with your sales team.
In some cases, you’ll have to do the traditional big tradeshows. If you sell security software, you’ll need to be at the RSA Conference because all your competitors will be there. If you are in the AWS ecosystem, you’ll probably sponsor re:Invent because of the huge developer audience. But don’t just staff your booth full of eager BDRs looking to scan “leads”. Make sure your booth is staffed with people who can answer technical questions and connect with the audience.
But there are lots of other ways to use events to reach developers without the high cost of big tradeshows.
Hold your own conference. Holding your first user conference is scary. You’ve got to build an audience from scratch. It’s expensive. You’ll struggle to get sponsors. You’re entire marketing team will be all hands on deck for months making it happen. But it’s so worth it, and it gets a little bit easier every year.
Jason M. Lemkin of SaaStr suggests that companies hold their first conference once they get to 100 customers or so, and I agree.
Participate in community events and meetups. The easiest way to get started with events is to find and supports the ones that are already happening. Chances are, there are already well established events happening around your product, and they would love to have someone on your technical team participate. Set aside some of your marketing budget to cover travel and arm your expert with plenty of swag.
Be creative, and have fun. You probably don’t have an unlimited marketing budget with and the ability to write a $500,000 check to become the Mega-diamond sponsor of every tradeshow. And thats okay, because brainpower and creativity scale much better than a marketing budget. Here are two good examples of creative developer campaigns:
- New Relic has given out well over 100,000 t-shirts, and credits them for a lot of their early traction. Seriously. Never underestimate the impact a brilliant developer wearing your t-shirt can have on a movement.
- DigitalOcean, in partnership with GitHub, runs an annual Hacktoberfest event to encourage contribution to open source. Make 4 pull requests from a bunch of open source projects and you’ll be rewarded with a fancy limited-edition Hacktoberfest t-shirt.
Why you should find a developer evangelist
Steve Francia was the Chief Developer Advocate of MongoDB, where he was responsible for the developer experience of MongoDB and led a large team of developer evangelists. He was an early employee and his evangelism team had a huge impact on the early traction of MongoDB.
What does a developer evangelist do? Their job is to lead the grassroots adoption of technology in a quest to win the hearts and minds of developers. There are lots of ways for evangelists reach developers — ranging from speaking at conferences to blogging code samples to participating in developer communities. Evangelists address the the trust gap that developers have with traditional marketing, and they provide unique insights back into the product team as they are often the closest to the users.
Whether or not they live in marketing doesn’t really matter, and they really shouldn’t. I’ve been lucky to work with two great developer evangelists over the past few years. eGandalf aka James Stout was a developer evangelist on my team at EPIServer. James was initially a customer and active participant in the EPIServer developer community forums. We hired James on the marketing team to increase engagement with our developer and partner community, through providing everything from direct mentoring and coaching to code samples and working applications for customers. James led our highly successly Office Hours program, a weekly Google Hangout covering a broad range of topics for EPIServer developers.
Even a single evangelist hire can make a difference. And the best ones aren’t made, they are found. Chances are there is someone already on your technical team who is playing this role, and would love to make the transition. So go find yours.