And now for chapter two: Blog Posts. A lot of times, this is the only thing people think of when they think of developer content. And it's true that the blog is the most likely place to hold any content that you have that is developer-facing that's not already documentation. Blog would be the natural place to put it, which then raises another question of do developers even care about company blog posts?

And true, coming off of the Developer Experience chapter, you might think someone's going to come through and they're going to click on the documentation. They're going to click on the developer portal. They're going to download or login or fork or whatever it is that they're going to do to actually try using your developer product. And that is true. That is the natural experience that a developer has, once they've found you.

But blog posts are the most likely way for a developer to be able to find you in the first place, if you approach it in that right way of not talking about your product and using education over promotion.
One of the things that I wrote about in the book is the idea of looking at your blog as a publication. And the difference between a blog that you might be thinking of for like a company blog and a publication really has to do with what you're focusing on and that you aren't focusing on here's the latest from this company but rather here's the latest information that someone who's reading this publication might care about.

And even though a developer might not use your blog as a publication, it can be really helpful to think about it the same way that the New York Times or any other publication that you might read thinks about it. So there are certain areas that you cover and there are others that you don't, there might not be celebrity gossip in the New York Times.

I actually don't know whether they have a section for that or not, but you have politics and you have, worldwide issues. So what are those areas that you cover? That's what makes you a publication and being able to understand what the right developer that you want to find, what are the things that they would want to see in a publication and then providing those.

Now, you're going to find them still on a particular piece. They're going to discover you when they find one blog post, but that will help you to be able to have the right topics for them.

Another common question I get is how do I find writers? I'm not even sure that's really the right question or the one that the one that people are meaning to ask.

But I think the question behind the question is, okay we figured out this publication, how can we get more stuff out there? And it's true in the book, I talk about how it really is a numbers game of being able to have enough of the right content. But that's the key, it's the right content.

And so searching for a bunch of writers before you have figured out type of content that you want to produce that's in the wrong order.

Once you know, the type of content you can produce, if you want to find writers, so you can look internally, you can also look externally. Internally on your own team, developer relations if, that might be your team, might be partner team and looking at other areas within the company, those that know the problem space better. So sometimes that is product. Product knows the product really well too, though. So you have, to be careful about it being, not too product-focused.

But then externally is where you might find the best writers, because remember you're wanting to attract someone externally to this content. So an external writer is going to have a better chance of being able to understand that mindset that the reader will also have. And what you can do is you can find someone else who is writing right now on similar topics. That's another benefit of it being a publication.

A lot of times people ask how many posts should we shoot for? What should we actually publish? And again, that feels a little early when you don't have a lot of volume coming out already. I used to joke in a talk that the answer was two. And that if they said, how many posts per month should we have?
I'd say two. How many posts per week? Oh wow. You can write more than one post in a week? How about two? It's a good rule of thumb, but, I think it first starts with knowing who you want to reach. Organizing it around the problems and around, the beats that a publication would have, and then being able to find the right writers and the volume you'll get there.

Start small and look for consistent publishing is really more important than volume. There are other chapters in this book that are about other types of content that may actually end up on the blog. So I'll have more to say about that.

Probably could have written a whole, book about just blogging itself, for a developer audience and probably could have made all these podcast episodes about that as well. So I'm sure we'll get into that, but this has been the Blog Posts chapter of Developer Marketing Does Not Exist.