'Developer Marketing Does Not Exist': Adam DuVander

InfoQ recently sat down with Adam DuVander, author of the book “Developer Marketing Does Not Exist,” which teaches marketers how to authentically engage with developers as a way of attracting them to a particular product.  Adam is a developer turned journalist turned marketer.  He’s tracked the rise of APIs as the editor of ProgrammableWeb and his journalistic approach - combined with his developer background - has provided him with the unique ability to empathize with software engineers when it comes to content creation.  

InfoQ: How did you get the idea for the title of your book? If it holds true, should we all be looking for new jobs?

DuVander: Ha! Don’t worry. Developer marketers exist! It's their job to make sure developers don’t think the marketing exists. The idea for the title came about because the best marketing won’t look like marketing to the right audience. That is especially true for developers and other technical audiences.

InfoQ: It’s a fairly common mantra in our industry that all developers are “marketing averse.”  How did this happen and why won’t developers give us their phone numbers?

DuVander: It comes down to trust. Developers have been burned by marketing promises before. If it seems too good to be true, it probably is. The downside here is that even the great developer products, the ones that are as good as they say, need to watch out for this signal. One tiny thing to look out for: don’t use words like “simple,” “easy,” or “scalable.” A developer’s job is to spot edge cases and those words can’t possibly be true for every situation.

InfoQ: In software development, we have this concept of “the developer experience,” and there are many discussions happening today around how to improve it via a mix of tools, processes, and culture.  What does “Developer Experience” mean from a marketing perspective?

DuVander: The very first chapter of the book covers developer experience, which a lot of people translate as “documentation.” First, it’s more than that. And secondly, I put that chapter first because it’s foundational. You can attract all the developers you want to your content, but what if the experience afterwards is terrible? That’s why it should matter to marketers, too.

InfoQ: What is “Time to Hello World” and why is it important?

DuVander: This metric gets a lot of attention in developer experience circles. While knowing the exact amount of time isn’t that important, you want developers to have a smooth first experience. What I think gets missed in this concept is why you should care about it. The goal is not hello world (the simplest possible project). The goal is to take the next step. I get much more excited about what comes after hello world.

InfoQ: What role do sample applications play in the developer experience?  What makes for a great sample application?

DuVander: At their best, sample applications are use cases put to code. They are an excellent next step after hello world. Sample applications inspire solutions developers might not have thought about or help them see how your product addresses their problems. The very best sample apps will have complete code and a tutorial to provide context. I know it’s kind of trite to mention Twilio or Stripe related to developer experience, but… one of my favorite examples is Twilio’s appointment reminders sample app. It’s actually seven examples, once you take language selection into account. It uses Twilio’s product, but it’s laser-focused on a specific use case.

InfoQ: In your book, you talk about the ‘DX Index’, a rating system that consists of 13 criteria used to measure the developer experience around API documentation and website.  Can you highlight some of these criteria and why they’re important?

DuVander: Of course! We’ve already talked about a couple of them: getting started tutorial and sample applications. Another important one is programming language support. You’ll have a much better chance converting a developer if you already have tools for their language. Can I share one more? This is a deeper cut and it’s often outside a marketer’s control: a self-serve experience. Developers want to try out your product without talking to someone—that’s why they won’t give you their phone numbers!

InfoQ: Software developers naturally want to begin being productive with a tool or product - writing code, as it were - as soon as possible.  Are the ‘developer experience’ requirements different for a software architect?  What about other, technical, ‘decision maker’ roles?

DuVander: Yes, we’ve found there’s usually an analogous experience for other technical people. You might frame your product around complementary tools rather than programming languages, for example. Architects still want to understand how your product works and the best way is to see it in action. I know Apple sells a lot of devices sight unseen, but I bet they sell a lot more after someone gets to use it.

InfoQ: Creating - and more importantly, maintaining - a developer blog can feel like a daunting task.  What are some of the fundamentals - not only for consistent content creation - but for quality content creation?

DuVander: Oh my, that’s a huge question! First, consistent does not necessarily mean high volume. I could tell quality content published on a regular basis over something that isn’t very technical or is hastily published. You want to create evergreen, relevant content. And stay away from vanity metrics.

InfoQ: What’s the difference between a tutorial and a technical guide and where does each one fit in the developer marketing funnel?

DuVander: The way I’ve defined “guides” in the book is very different from tutorials. In fact, they each have their own chapters. Guides are usually a higher level, explaining a topic completely outside the context of your product. A tutorial is more likely focused on solving a very specific problem, with the exact steps to complete it. A guide may contain a tutorial as one element, but a tutorial might also live on your blog, in your documentation, alongside a sample app, or even on someone else’s site.

InfoQ: How can SEO tools be used to determine what content to produce? Are there any tools that you’d recommend?

DuVander: SEO tools help you understand the words developers use to describe their problem, as well as a rough idea of the relative number who use those words. That’s valuable, but it’s not everything. We use ahrefs on our client projects, but you need to think way beyond the keywords that come back. What’s the story that can tie these keywords together? How can they be framed so there’s relevance to your product?

InfoQ: One of the central tenets of your book is to help developers solve problems that don’t require the use of any product.  This might sound counterintuitive to a marketer tasked with driving engagement and sign-ups for a particular product.  How are the two ideas actually connected?

DuVander: There’s a reason I call this the developer content mind trick! It is counterintuitive. This type of content helps developers let down their skeptic guard. When you talk about problems outside of your product, you build the trust that you know how to solve those types of problems.

InfoQ: If the problem(s) that your product claims to solve do not yet exist in the market, how should you approach talking about your offerings?  

DuVander: Companies and products are founded on opinionated solutions. Another product may not solve the problem the same way, but the problems are still there. This can actually be a great place for a marketer to start with content concepts, something we teach in our technical content strategy training. If you know what developers will attempt to build without you, you’ve found your biggest competitor.

InfoQ: On the digital marketing front, what’s the difference between advertising and sponsorship?  Do they typically have different metrics and success criteria?  Can you share an example?

DuVander: Advertising typically allows you to measure conversions right away. You might even pay per click on a broad platform that allows you to target the right audience. That’s great, but developers will be at their most skeptical, if they’re even there. Many developers have ad blockers and other technology to filter these messages. And that’s before you get to their most powerful filter—their brain. Sponsorship, on the other hand, allows you to access a community through someone who has already built trust. The downside is that it’s much less trackable, but it builds goodwill with developers. 

InfoQ: What are the advantages of ‘renting an audience/community’ vs. building your own?

DuVander: Here’s the good news: you don’t have to choose, because one of those isn’t possible. You can’t build a community. You can only participate in existing communities and nurture the developers that show an interest in your product. From what I’ve observed, it’s hard to be successful by purely buying access. You need to follow that up with meaningful interactions. Content certainly helps there, but this is a much bigger topic that likely involves developer relations depending on your type of company.

InfoQ: What advice would you give to marketers looking to reach developers in 2023?

DuVander: It’s an exciting time! There’s a lot of opportunity to solve big developer problems. All signs point to organizations being asked to build more with fewer resources. Technical products like yours help make that happen. Be strategic about how you deploy your content. A lot of your success is determined up front by how well the content addresses real developer problems and whether you can educate authentically.