I’d start this post by proudly making an announcement, but that sort of sentence serves the writer more than the reader. You’re here to learn how developer-focused companies reach their audience. I’ve been exploring developer communications for a long time, going back to my time writing code. I’ll be applying what I’ve learned in my new consultancy and no doubt learning plenty more, too.
Developer marketing—if you must call it that—is more about education than selling. It’s about discovering, feeling, and solving a developer’s problems. You’re a guide inspiring them to see what’s possible.
When you look at the best developer-focused companies, like Twilio and Stripe, there’s a natural developer flavor that comes across. While they start with great products, the communications effort comes down to understanding their audience.
Far too many attempts at developer marketing start with a focus on the product. That’s part of the equation, but too often that’s where it ends. If you’re only thinking about the what, you miss out on the real value in the why and the how.
You need to really understand what sort of problems your API or developer tool solves. If you’re a developer, you may be able to spitball your way to some ideas. If you aren’t a developer, you likely talk to more technical teammates, but the value could be lost in translation.
The absolute best way to understand your developers is to talk to them. That assumes you know who your developers are. If you don’t know that, there’s even more work to do. Start by talking to who you think your developers are and see what resonates. Developers are typically forthright with their feedback.
Figure out what the pains, frustrations, hopes, and desires your developers hold. Keep a log. It won’t take you very many conversations to get a good feel for where you can help. Though I’ve done some version of this in most of my roles, my time at Zapier is freshest in my mind. I jumped on many calls with users building on the platform and saw those insights enter into my writing, as well as product decisions.
Once you understand your developers, communicating becomes much easier. You can focus on the developer, not the product. Or, put another way I’ve espoused the last five years, share knowledge, not features.
This is where developer education and inspiration comes in. Developers are curious. What can you teach them? You already know their pains, so start helping them. At Orchestrate, we knew our best developers were starting something. So, we showed them how to add user login to their app. It turns out, you need a database to hold user accounts, and that’s what Orchestrate provided. That single tutorial drove thousands of visits over the years.
Simply cross-referencing developer pains with a couple of languages or frameworks can give you plenty of roadmap for months worth of developer content.
And that’s really what the best dev-focused companies do to reach their audience. They speak directly to how developers can solve their problems. And while they may attend events and otherwise reach some developers in person, the real scale comes from content: blog posts, guides, documentation, and more.
For the last 10 years, my professional focus has been engaging with developers: from writing tutorials at Wired—or writing an entire book—to working at API companies like SendGrid and Orchestrate. With each new role I learned more about developer audiences, how companies reach them, and the type of work I do best.
Not everyone is able to execute themselves on what seems like a simple two step process. First, understand your developers. Second, show them what’s possible.
I’ll be walking the talk on EveryDeveloper and helping the best dev-focused companies reach more developers.