Developer Marketing with Adam DuVander

Adam DuVander is an expert in developer marketing and the author of two books: Developer Marketing Does Not Exist and Technical Content Strategy Decoded. 

In this episode, we dive deep into the world of developer marketing, specifically focusing on early-stage companies building tools for developers and how to create engaging content for your audience.

What we cover:

• Adam's journey from journalism to developer marketing
• The importance of developer marketing for early-stage companies and its role in product growth
• Identifying your target audience and understanding their pain points
• How to create content without directly promoting your product, yet staying relevant to your target audience
• The concept of becoming a media company within your niche and providing value through content
• The importance of engagement metrics over vanity metrics for early-stage companies
• The Jedi Developer Mind Trick: how to showcase the value of your product without directly promoting it, especially for early-stage companies
• Examples from successful early-stage companies like LogRocket and Stoplight
• How to measure the success of your content and know if it's working for your early-stage company
• Tips on choosing the right topics that resonate with your audience and relate to your product
• Adam's new book, Technical Content Strategy Decoded

Buy Adam's new book here 

Creators & Guests

Host

Jack Bridger

Founder of BitReach

Guest

Adam DuVander

Author of Developer Marketing Does Not Exist. I help dev-focused marketers build a content strategy to reach more developers. Previously @zapier, @sendgrid

Editor

Elliott Roche

Freelance Podcast Editor

Producer

James McKinven

Founder of PodPanda

What is Scaling DevTools?

We investigate what it takes to grow a developer tool. Topics include developer marketing, DevRel, developer advocacy and developer experience.

Adam DuVander 0:00
I include a headline, you know, company you don't know releases product you don't care about. And, and you want to avoid anything that looks looks like that yet, that could be totally a template for a lot of those kinds of posts or announcements.

Jack Bridger 0:19
However everyone, you're listening to scaling dev tools, the show that investigates how dev tools go from zero to one. Today is a special episode because we are joined by Adam de Vander, who was our very first guest. And Adam is coming back on the podcast because he's just launched a new book. And I could not be happier for Adam to be here. Thanks so much for joining Adam.

Adam DuVander 0:43
Yeah, great to be back. Thanks for having me, Jack.

Jack Bridger 0:45
And in the intro, I forgot to actually do it, Intro to you, but you are the founder of every developer, you help develop the tools companies write really good content, and especially on the strategic side, and you are the author of the book, developer marketing does not exist, which is kind of become I'd say, it's the the book on developer marketing at this point. Is there anything I missed that?

Adam DuVander 1:14
And then the new book is technical content strategy decoded. And the reason that's that I wrote another one, when I've already written this. This first one is the first one is very much the kind of philosophy, you know, from having seen Developer Relations and being a journalist on developer topics. And now this new one is okay, we know the philosophy, we know how to approach this really tough audience. Now let's, here's how you actually do it. Here's the actionable steps to use to create more strategic content, the stuff that will, that will, they will actually want to find and consume.

Jack Bridger 2:01
Yeah, that's, that's really, really helpful. Because I know, especially at the earliest stages, it's very well to know, you know, the philosophy like, this is how it works, it's super helpful. But then a lot of the times you just kind of want to get your hands dirty. And you've you've got to be thinking about how do I get users coming in, in the next two months? And I feel like this is going to hopefully answer that. And,

Adam DuVander 2:27
you know, I think another thing that happens a lot of times is, it's really easy to look at those dev tool companies that have been around for ages and, and compare sort of what you're doing to what they're doing, and that you have to do all the things that they're doing. And that can be really overwhelming. And, I mean, so stripe not necessarily known for their content, but certainly documentation and, and all of that for like, you know, that developer experience. And I think that's one also where you look at and you're like, oh, how do I how do I do all the things that stripe is doing and do all of the publication that you know, someone else log rocket is doing. And the I think you can get overwhelmed by trying to do

Jack 3:16
too much. Yeah, I

Jack Bridger 3:18
think it's actually in many ways more valuable to know what shouldn't be doing at the beginning.

Adam DuVander 3:25
And, and so for stripe, one of the things that I I've written about now is in the book also is looking back at, like, the real lessons to get from stripe is to go back when they were small, or maybe not as small as listeners are now. But I go back to their original landing page, or one of the ones in 2011. And really, the stuff that they get there is like you can tell that they so understand the audience that is going to want to integrate payments, because payments in 2011 was much harder than it is today. There wasn't sort of copy paste up options. It was like, set up a whole, like merchant account and this other gateway thing and what are those things? Right? And they talk about that, on that original landing pages, like don't do this, you know, you don't need to do this anymore. And I think that, that shows how you can kind of get into the mind of the audience that will love the product that you have. And that's the stuff that I want to get from from stripe is like how did they do that? And become the stripe that they are now and and so looking for those ways to unpack how where that audience is. And then you know how can you how can you find the the high value things to do to reach that audience with that message? Yeah,

Jack Bridger 4:56
and how digging in like how can Start up, start to kind of move towards having that kind of that communication, the stripe had at that point.

Adam DuVander 5:12
Yeah, I mean, at some level, you have to, you have to really understands who that audience is. And so, I mean, I go too, into some ideas for how to unpack that in the book. But at some level, you definitely have to know, your audience. And I bet that a lot of I mean, if you're a small dev tool team, there's a good chance that you started that, that company because you knew this problem was big enough, that's that lots of other devs would have it too. So I think really, digging into that piece and understanding why someone would go searching for a solution like yours, is the way to get at what some of those topics are, and kind of be the so the first few chapters are about being a translator, and that that, you know, you who are responsible for technical content for a dev tool, you need to be that translator between those set of problems, those that the things that the dev wants to achieve, and eventually on your other side, the product, and there's a lot of space in between there. And so looking for the things that can kind of be that translation, or that connective tissue. In between there. I'm so one of one of every developer's earliest clients is Stoplight stoplight.io. And they saw their product is an API design tool needed by lots of large companies that have hundreds, sometimes 1000s of API's. But a lot of what the content that we've worked on with them has been around open API or JSON schema, the conventions and best practices around API's, what are the things that you should be thinking about as a team who needs to produce these API's in a consistent way? Right, so it's, it's really not about that product, it's more about the problem. And, and so being able to, to zero in on, on the ones that are going to have the most resonance with that, that audience. And that's where I think trying to do too much can go can go really wrong for especially a really small startup, and seeing what others are doing and trying to do all of those things at once. And so one of the things that I talk about in the book is, is to think more in concepts than topics, because a lot of times, it's just really easy to say, Oh, here's a new idea for a topic, let's write this lets you know, and you sort of are scattershot, random with, with how you're approaching content, maybe because you have heard, oh, we need to post every day or whatever you've heard, right, like, these huge volumes of content that are needed. And and instead taking a step back and saying, what are the what are the ones that we could that there's more than one topic here? Right? How Where's something? So in stoplights example, it would be open API is this huge data format. And there's so much that we could think about around open API. And really seeing that, I mean, that's probably more than one concept. You know, open API is kind of like I think of it like kind of like a tree, maybe it's my, my dev background. It's like, you know, going between nodes, right? And and so you have these sort of categories, that then you can get more specific and you can get more general, as you climb at different levels in that tree. I don't know if that's, if that's going there for you. So you have open API at one level, but then there could be really the data format within open API. Then there's the Collaborate, like how do you collaborate on Open API, and those are related but two really different concepts and which one of those you choose to go deep into, can impact who you're attracting to,

Unknown Speaker 9:48
to your content?

Jack Bridger 9:50
Yeah, that makes sense. So would a specific topic might be there, as you said, collaborating on Open API.

Adam DuVander 10:01
I think that's, that's probably. So I would consider that a concept. Because there are many ways you could talk about collaborating. And so within a concepts, you will end up with multiple topics. So you know, there could be using your open API, putting your open API doc into a GitHub repo so that so that all the changes are visible, at least within your organization, maybe even broader, right. So. And then, like, who writes the different pieces of the open AI? Doc? I mean, who decides what the paths are? You know, right, you can see how you can dig in even more to that. And maybe even you have you have engineers, and you have tech writers? Is there someone else that's in there? I don't, you know, right, like, depends on the organization, I bet a lot of organizations, it's entirely written by one of those audiences. And those of us listening here can probably think of the downsides of an engineer writing all of the

Unknown Speaker 11:19
dev facing documentation.

Adam DuVander 11:24
And also, there's probably some downsides to a tech writer writing all of the all of the various, you know, the, declaring the paths when they don't know how it's necessarily implemented, right. So a lot of a lot of things in there that you can kind of unpack, but if you were being scattershot, you might not get at some of those deeper

Unknown Speaker 11:47
topics. Whereas if you

Adam DuVander 11:50
can think through what those what those concepts are, then then you really make the the topics that you produce, count, or have the best chance of counting. And that's really the the idea here is to, to I mean, maybe you produce less, even if you produce the same amount, it's, it's being smart about which ones you, you take on.

Jack Bridger 12:19
Yeah, yeah, it makes sense. And it's like, you're kind of, you've got to work hard at picking your direction, and then double down in that kind of, I imagine you probably get better at it as well. So maybe it doesn't take as long to actually

Adam DuVander 12:36
yeah, you start start to get sort of that's, you know, that idea of what, what will resonate for sure. And there is some experimentation needs to happen to be able to, to get that. And there are certainly examples of, you know, posts that's have done well, that maybe I wouldn't have expected to write but, and then you hit on something that you you can do. Maybe that becomes a new concept at that point that you explore further. But, but when you're when you're starting out, you don't have the ability to just have that many shots that might end up going nowhere. And that's where, looking at some of the common mistakes that that companies can make or you know, founders can make in the in the content that they produce is if you can avoid some of those so that I mean the really big one that's I've talked about a lot I talked about it in the first book also because it's that big of a deal is that product focused content so the ones that were just go straight, straight on toward you should use our product or here's something brand new in our products. And that's really like common stuff to write especially when you're first starting out because that's what you want to share about but you'll you'll find that that won't have the same resonance as something that really talks about the problem that is why you built the product I'm other ones there's a there's a scene in the office the US office so sorry if I'm going outside the bounds of of of what you might have seen Jack, but I've

Jack Bridger 14:36
seen it twice.

Adam DuVander 14:40
Good. So there's one where where Dwight is somehow on the the party planning committee and and so it's Kelly's birthday and he has the break room just like has a sign that said says it is your birthday. And like the balloons are like barely filled, and they're gray. And it's just like so generic and boring. And I think of that. And I actually in the in the book I, every chapter starts with a TV or movie sort of reference that connects it. And that's 144. Why technical translators struggle? Is that office example? Because that like, that is exactly what a lot of technical content looks like the sort of technical content that doesn't engage. It's might be product focus, it's definitely not. Yeah, not something that's going to engage in is kind of kind of generic sort of content doesn't have an opinion in it, it is just fact it is your birthday. This is how this API or dev tool is used, right? And, and so looking for ways to be a witness, like a problem, or the thing that would get a dev there in the first place, or reason why they would care about it is naturally going to be much, much more engaging than something that's just kind of just the facts. Yeah,

Jack Bridger 16:14
yeah, that makes a lot of sense when you put it like that. Yeah. And is there like a kind of, is that like, a gray area over where it's like, kind of Sabir about a new thing? But like, if you really want to kind of promote this new thing that you've just built? For instance?

Adam DuVander 16:33
Yeah, well, I have talked to and I think in the first book, I, I mentioned that announcement posts are, they're the hardest to write. And that I read a ton of them when I was the editor of programmable web. And, and it's so the, the phrase that I always look for is proud to announce, like, that was the one where I knew like, my eyes would glaze over. And I would be like, Okay, this is just a, this is just a product pitch, right? I think in those cases, thinking through how is this going to be used can make that better to the gray area talk about is at some point, you do have to say we have a new thing, and you want that to come pretty darn early for someone to know, but know that the thing is new, and that it's that it's there, but really having that foundation of why should I care about it? I include a headline, and you've probably heard me say this before of the, you know, company, you know, you don't know release this product you don't care about and, and you want to avoid anything that looks looks like that yet, that could be totally a template for a lot of those, those kinds of posts or announcements. But I think we're a startup can sometimes go on this is that, like, you want to you're doing a lot of work. And so you want to tell people what's new. And so maybe you have this sort of like release notes, kind of blog posts, but then you go to the blog, and it's like the last five posts or release notes, great, you've been doing stuff but they all kind of blends together. Where as you can imagine if, if each of the things that you care about is listed there even at the top, even if it happens to be release notes that's within it, that that would make you would you would be able to choose which of those five Should I look at not just release notes for April of 2023 or whatever, right? Like whatever the the headline is that you might use. So I mean, a huge part of that's the headline, but then how is the actual post framed? Also, and I think it starts with that headline, so you're able to, to figure out what is the what is the thing that's new? Why should I care about this? Yeah,

Jack Bridger 19:06
yeah, that makes sense. Yeah, it's really helpful. And then so once we've kind of like got some sort of a direction on like, the kind of content that we want to create maybe narrowed down to some topics and where we're kind of focusing in on that. What kind of stuff are you seeing like the kind of successful content

companies not companies but

that all startups do

Adam DuVander 19:35
Yeah, I'm I I'm not certain that this would be a good like brand new company strategy, but the it's one to to think about and it comes down to that same concept topic thing which is thinking about if you if your entire like if you were a media company, which is some of my background right have I have writing for companies that don't have products. So being a journalist, what would kind of your beat be? What would your the categories be? And being able to think in that, thinking that way, and that's where I mentioned log rocket earlier, they have a great front end, primarily front end Dev Blog, that really would work as its own kind of media site. I mean, it would be right. Like, if I was wanting to learn front end, it would be right up there with, you know, any other front end resource that doesn't happen to have a product, which log rocket as a product that is for front end, devs. So I think being able to think of, what would that that area be that you would focus in on? And how can you be helpful, even without your product like that is I'm, I'm seeing that work for companies like log rocket, they do it at a much larger scale than probably you will as a, as a small team. But being able to see the beginnings of that is, I think a strategy that will will pay off you'll find some connection in those early topics that come out of those concepts, but then you're sort of planting those seeds for what could later become a large property that that happens to also support

Unknown Speaker 21:39
your product. Yeah, and,

Jack Bridger 21:42
Adam, one of the things that is always really hard. I think, especially as a startup, when you're putting a lot of things out there is how do you know if it if it's good? How do you know if it's working? How do you know if you should, if you should do more of it?

Adam DuVander 21:55
Yeah. And that's, that's probably a, a potential downside to that be a media company. concept is that great. If you're getting in a media company, you want all sorts of like, page views, and then that gives you ad views? And you know, dot dot dot profit, not the case, if you're a dev Tool Company, right. So, um, so I think looking, looking in and recognizing the numbers that really matter, they might not be the sort of vanity metrics like lots of us that's, that you're thinking of, you know, being number one on Hacker News feels awesome. But then it goes away the next day, right? And, and so, really looking for, not only does someone come to this content, but do they read it? Do they take any next step, which might be other contents. So looking more for engagement metrics than, than pure view metrics. And then that can also inform those those topics that you will pursue? Because you can ask yourself, What's the likelihood that someone reads this? And they say, that there's a next logical step that you have something for you have another piece of content? Or you have documentation? Or would they sign up because, because that's the next logical step to take from this piece of content. And so that gives gets you away from things that might people might consider top of funnel huge volume, sort of things. I mean, we had a real client, who had a like, a, a jokes, like a developer jokes, blog post, that was their number one blog posts. But like, I'm not going to tell you who they were and what but you can already know that that didn't connect to, to their product, right? Like, you don't even need to know what their product is to know that, that a developer jokes post didn't connect to their product. I'm and so yeah, lots of views feels great to have this steady stream. But there's not a connection to the product. And even like, like, who's what developer is looking up developer jokes, like it might might be like, friends of developers who are wanting to impress them with their ability to tell developer jokes. Right? So it's even not even the right audience who's finding that and yet it you know, has developer in the name it? It's a there's technical topics within the within the post because you have to write about technical things to be able to understand the jokes, right. Like, it seems like it's technical content, but it's it's not like being technical is not A technical content is not enough. And you want to be able to, to draw the connection between things, which I understand is like, on one hand probably seems counter to what I've said about don't mention the product to be away from the product. But that really gets back to why I put three chapters about translation. Is that like that is your job is to be able to make that translation between those ads. And so that comes down to Yes, how you how you the work you do in between there, but also choosing those topics in the first place, that have a logical connection to to your product, would that ever would someone who's interested in that ever be interested in your product? So going back to the stoplight example that we did earlier, it's really easy to see how someone who's looking at open API looking at api best practices, they might be interested in an API design tool. And how someone who is reading this great front end dev resource might be interested in a tool that helps them understands errors and other problems in their front end code, which is what log rockets product is. So it doesn't have to be a direct connection. But it's, you know, it's kind of the the people who are interested in this are interested in this kind of thing from like E commerce, right, like you have to be able to have a similar kind of approach to the content concepts that you arrive on. And then yeah, and then looking at, do we see that there are signs of engagement here that would lead us to continue to invest in this concept?

Jack Bridger 27:00
Yeah, yeah, that makes sense. So it's like you're, like, feasibly would they buy with the person reading this bit? Be interested in your tool? And are you seeing evidence that people are reading it?

Adam 27:16
Yeah, exactly. Yeah,

Jack Bridger 27:19
I really liked the example that you spoke about in the first episode we did. The Jedi Jedi developer mind trick?

Adam DuVander 27:29
Yes. Yeah. Yeah. And that is, that is definitely embedded in in here too. Right. That's, and so the the idea for the quick, quick recap on what that is, it is describing how someone would solve a problem, the problem your product solves without using your product. And that the deeper you can go in there. And I probably gave the example of LaunchDarkly, which does this really well. And there's a great talk from the one of the cofounders of LaunchDarkly, about how, when she did an engineering degree, she had to build a hammer, like a physical hammer, and she was given wood and metal, and some plastic and a blueprint. Like, this is how you build a hammer. And she spent 80 hours or more building this hammer, and it wasn't even that good. She said. And right, this is a hammer that you can go down to any hardware store and get off the rack for for not a lot. Right. And but going through that process, and seeing like, wow, it actually takes a lot to build a good hammer. That definitely would work for her. I bet she's never built another hammer. She's She's definitely buying hammers, right. She learned Yes, I could build a hammer, but I don't want to and that's what the mind trick does to here are this. The solution which might seem simple to you, actually has a lot of edge cases that you haven't thought about yet. So let me tell you about these edge cases. Let me tell you how to watch out for them how to how to solve for them. It's pretty hard. Oh, by the way, we've already solved them. Like that's kind of the the the argument and it's not even an argument because the you know, a lot of times people will say oh that's build versus buy. Like I know all about build versus buy well build versus buy document probably comes in a PDF and it makes a head on case for you should buy this obviously. Here's how much it costs you to build it and yeah and and the mind trick does not go head on. It's you know, it's the these are not the droids you're looking for it's it's the you, you can build this but by the way you don't want to

Adam 29:55
Yeah,

Jack Bridger 29:56
like you actually do set out to share the secret To tell them, Okay, this is how you actually had, these are all the considerations like, with if someone was sufficiently motivated, and maybe in many cases, maybe ill advised, then they could go out and build, follow it and build this thing themselves.

Transcribed by https://otter.ai