Your DevRel content strategy in 50 minutes

Adam: All right, thank you all. It's great to see folks here and you are 50 minutes away from the start of your content strategy or hopefully an improvement on what you already have together. It is a process that you mentioned. The one book, I have a new book and this process that we're going to be going through is outlined in there. It's an abbreviated version of what we do with clients. And so I'm excited to get you all started and publishing some things that will attract the right audience. And I know there were a few people as they came in here said, oh, perfectly timed. And oh, this is exactly what I need to do. So that's good. But first I want to ask those of you here, who here has ever been Reddit famous? Go ahead. Alright, yeah, we have one. Or maybe Hacker News, right?

You've been voted up to the top right of Reddit well, and it is pretty cool and it feels pretty good. Have all those people coming and checking out the things that you have written. And I want to tell you about a couple of those experiences that I had. The first one was 2008 for Wired's "Don't stand in front of the screen" and one for for for Wired's Web Monkey resource. Now this delighted my editor. It was one of those things where throughout the weekend I kept going. I was like, oh my God, stop. Worst page. It's like I had no insight into the analytics on it, but it felt really good. Fast forward a little bit my time at Programmable Web and this one was the one that got the most traffic of anything I ever wrote. I wrote it in like seven minutes. Parse had this way where you can apply by sending an API request, perfect for Programmable Web, perfect for a dev audience, someone put it on Hacker News and just this is my version of the graph. I don't have the analytics anymore, but when something like that, and that's feels pretty awesome too. There I can see it was tens of thousands of people. Anyone want to guess? So the graphs like this right now. Anyone want to guess what the graph went like after that? Yeah, and if you want to do the sound effect too.

Yeah, yeah. Glasses off. No longer, no longer Reddit. Famous Hacker News, famous no longer feeling that high of that. And so though we may be talking about things that have the opportunity for this today, we're really talking about the things that are going to go and live longer than that one day. And I want to show one example of what that could look like for you. So this is something our team did with Algolia and it worked really well. This says it was published what last month? Well, it's years old, but they keep updating the date that shows you how well it is done. It was like a top 10 for a long time on their site. And this is something, the reason that I think this did well, it spoke to a developer problem. It was certainly related to Algolia, but it wasn't like if you scroll here, it didn't just say use Algolia linked to docs, right? It actually helps someone do this without using Algolia. So it really spoke to that developer audience. And so for the first, what I didn't mention at the top, you all got these, so I know you have something to take notes with. So we're going to have several points here where I want you to start to piece together what your strategy will look like. And we're going to start with you thinking about the best blog posts you ever wrote or your company ever. Roses.

What is that? Lemme write few notes of things that come to mind

And maybe identify what those attributes are. So I mentioned this Algolia Post. It was solving a problem that a developer might have before they discover Algolia not trying to sell to the developer, but what is it? Are you inspiring the community to build something new? What are the things that's, even if it is that blog post that made you Reddit famous, let's find out what the pieces are because something attracted people to that. And how can you take that and include that in the rest of this 50 minutes that we're going to do here? I'm going to give you a few things that why I've seen content fake. And then maybe you can use that to identify, oh, right, my best blog post didn't do that. Or Oh, all of my blog posts do. And the first one I already mentioned briefly, it's this overly promotional. If that Algolia post had been use Algolia, it is great. That would've been a fail. It is the classic announcement posts that is so inwardly focused and misses completely why someone would actually end up there.

And I think as DevRel folks, we know that, right? That's more natural, but we might be pushed by others in our organisation. Or if you don't have a DevRel title, you might be pushing some in your DevRel group to do things that actually look like this. It's not very hard to find something like that. By the way, normally I would just blur out logos or something on this. I don't mind this one. So you see multiple mentions of a product or company in a headline. And then this is the classic or the please to announce if you find yourself or others in your organisation including bits like that, that's probably a sign that you're being overly promotional or making it about you by comparison. You have things like this post for stoplight, which really is about making great API. How can you help people who are already thinking, oh, I've got this API keys, what are the things I can do? And all the way down to here, the open API, which is connected to what stoplight does as well. This one could get a little bit close to mistake number two. And our team wrote this. Mistake number two is the curse of the generic.

How come this blog post or piece of content is living on your property? Why is it any different than what someone else could do elsewhere? And that's where you get these really bland, clearly going for keywords and nothing else sort of topics. This is the table of contents from one that I found. And when you go in, you've got to have a comparison table if you're going to compare all these and it's like you look and there's actually only a couple of things that people might care about here in some of the differences and it's really hard to get to. And then of course you get to the conclusion which says that they're all great.

It depends. That may be reasonable, but I say take a stand with that, right? If you're going to make a comparison, make one like Luis here did and say, this is the one that I chose. Or the opposite of that, right? But actually make a stand as you go and explain and teach. Really don't do it in a generic way. Okay? The third is it doesn't move a developer forward. So why would they come and see this? What is that next step? I love the hip hip array joke. I will tell that at barbecues all summer long. I would not put it in a blog post. Who's going to find it's actually a well trafficked blog post, but what is that next step? What does someone get out of coming to this? Compare that to something like this on LaunchDarkly, which talks about feature flex. Yes, that's a product that LaunchDarkly has, but also they have done a really good job for a long time of explaining and teaching and not having it be used LaunchDarkly linked to docs. Right? Okay. So I asked you all to write down a best blog post ever and maybe some of the attributes. Could I trade a book for someone sharing?

Sorry, firsthand I saw was back there. Yeah, so I didn't write it. It was someone else on my team. Technically I think I might have it be if you go back far enough, you edited co-wrote.

Audience member: Yeah, I changed the word basically a blog post about how to run SQL Server on a Macs, okay. SQL Server on MacOS.

Adam: And why do you think that that did well?

Audience member: Very niche problem. Not really covered anywhere else. It did directly tie into, like you said, the last point about does make developer down the stage. It actually ties into what we needed to do. Worked really well with that. Two things.

Adam: Awesome. So it sounds like it was strategic for the place where it was published also very much, which is great. Do other people, I know you're already, I have lots of opportunities for interaction. It sounds like lots of other people have 'em, so that's good. So you've got the starting point because we've got to use that and turn that into something more. All right, so a little story about me more than 10 years working at SendGrid, working with about a dozen DevRel members all on content. So my job, I ended it for web and then I went there and it was like I want to edit, want to change one word and make it really good. The entire SendGrid DevRel team, one of the mistakes that I made was attempting to have a really high volume of content that we published. So there was something like definitely every day, I think it was twice on Tuesdays, tech Tuesdays, why does a company that's supposed to be all about developers have Tech Tuesdays?

That's maybe another that's for the evening time conversation, but way too much. And so because of that, and this team was going all over the world doing hackathons and doing demos and things too in addition to me saying, Hey, write a blog post. Write a blog post. And so we got these topics. I mean this one at least does email, but that really, that dates it. But yeah, the first one, I'm not sure what that moves 'em forward or is connected. I mean we're going to lots of hackathons. So let's talk about hackathons. So there really wasn't a connection, it wasn't a cohesive strategy. If I could go back and do that again, we would have one great blog post that was connected to problems that developers have. And this team, remember you all knows the problems that developers have, so you are able to have that piece already. So that's what I would do differently. And I would apply this, which again in the book, but I'm going to tell you what the pattern is here for great technical content. So I've already talked about identifying the problem, something you all I think are good at in your interactions with devs, but then that angle to the problem, what is different about how you would approach that compared to others? And then finally the teaching.

And you can look for this, that Oracle headline I showed you, you could see where all three of these things are missing just in the headline. You don't even have to read the post. So you can kind of apply this pattern even at that high level, even at the ideation stage to make sure that you have the pieces of this in here. And what you can do is kind of look at these as dials and sometimes one will be turned up more than another and you can actually do that and we will to be able to create a strategy around the things that will apply to the pat pattern.

So probably all of you have a list that may look like this one now and this similar, I had a big sheet at SendGrid, right? Lots and lots of things with the problem is that they're reactive. It's like, oh, we need to compare ourselves to someone. Oh, let's go and do that now, random. I mean why are we doing a Python tutorial? What's that even mean? Python tutorial And I needed another R. So really not that strategic. So that's the typical list. And what we want to do is use that to turn it into something that's a little more strategic. And so for this one, I'm going to just zero in on one of these here and try to figure out what does that mean. So if we dial up the problem on this one, really it's being more specific. It's who is this or what is the tool? So what is the thing that I want? And hopefully I would have something where this would make sense as a tutorial as well.

And this Twilio example, people expect Twilio examples to be like documentation focused. Actually this lives in the docs, but I bet that this pulls in a lot of traffic from people who haven't discovered Twilio yet because it talks to that problem. It's the very specific thing they want to do. They want to be able to send appointment reminders. They even know what language and framework they want to use. So again, back to this intro to DBT, what's it mean? How can we dial up the angle? How can we say what is it that we believe about this? So maybe it is this, read this before you use DBT for data science. So again, you're zeroing in data science and you probably have some edge cases that you're going to share with someone who is new to DBT. So these could be the same posts, but this one will do way better and be more helpful at the same time.

And this is a great example of that, having that, taking that angle. And so sometimes these can come across as a little like click baiting, but hopefully you back it up with what's in it. And Aiden did in this case, it's okay to break your API was lining out a whole case for basically his company is now part of Atlassian about if you know that an API breaks, it's okay to break it, you'll know you can fix it. And the real problem with breaking your API is you don't know that was the case. I saw some nods, I saw some sceptical looks and that's okay. That actually should happen when you're taking an angle. It's like that generic comparison, not going to generic comparisons going to get everyone to be equally isolated and you're looking for people to be into it and some not. And then finally teach. So guess this is teaching here, but again, being specific, where are they now? Where are we going to take using something else? How are we going to show them how to bring this into their world?

And there were many, many things I could use to show this. This is enterprise ready.io though, which I think is an example of going that extra step to make. This is an entire site that helps you become enterprise ready. And so each of these and many more are those sorts of educational pieces, but you don't have to go and build an entire site. How can you have that sort of teaching philosophy in to what you do? Alright, so go back to your best blog post or another kind of idea that's in your mind maybe goes to what's the version of intro DBT that's on your topic list and what does it look like for you to dial up the problem? And another way of saying that is how specific can you get with that problem?

Maybe it's the type of person who you want to read this or the tool that they are using the tool that they think is going to solve their problem, but really if they only knew that your product was going to be a much better solution for them, but you're not going to put that at the top right? That's going to be a by the way at the end once you talk them into it. So those examples that I gave for what had been one thing on the topic list that was a kind of uncertain topic actually became an entire article series. You could have all three of these and they do a different job. They're not going to have the same content there. And if you were a company where it made sense to talk to data scientists about how they might use dbt, these are great topics and you can probably already see there are more that you could do is you continue to turn those dials and say what are the different things that we could do with this?

So in the framework that I use, I call that a concept catalogue. So that series is the catalogue you have. That's one potential way you could go. And there are many different topics within that concept that you could choose. And so my biggest advice to those of you here who came in say, alright, I'm ready to be strategic with the content that I create or the DevRel team creates, is think in concepts, not in individual topics. What is such an important concept that you would be willing to bet multiple topics on that. And so the goal today and as you think about this afterwards is how many concepts can you create and then make the choice, and I recommend working with others to help you identify which of these is the best one for us to go for first. And so concepts contain topics and if you're having trouble wrapping your brain around that, one way that will either help or make it even more confusing is to think of it kind of as a tree.

So we started with that intro to DBT and we got down to, okay, it's this article series about DBT for data science. And beneath that we have these three topics. Though you might see that you could have ones within those also, you might actually, as you zero in, you might realise, oh my gosh, airflow isn't the topic. This should be a whole concept and there should be stuff below that in that way. The reason I said it might confuse you is okay, now airflow is a concept, it's not a topic, but the idea is can it contain more? And you can go up from there too. Maybe you say, oh actually our best developer or best engineer already has lots of DVT experience. We want 'em to bring their workflows to our platform. Well you can go up and you could see that you could continue to build that tree and I recommended if you're like, oh my gosh, I don't know whether I need to go deeper or stop where you are and describe that first concept and you can go deeper and describe that concept. And as you do and as you are about to do, because I'm going to give you the time you do this, answer these three questions. So why is this concept important? So what is the problem? Let's going to attract someone here.

What will it cover? That should be the easiest part. You kind of have an idea of what you want to do in this and then how does it connect to the product? Some of you may have realised this is the pattern. What you can do is you can answer these and I mentioned sharing it with a coworker, someone else to kind of bounce it off of. And the way that I do this is I write them into paragraphs that basically answers to those three questions. So why is it important? Well experienced data scientists, I decided that these data scientists are experienced just not with DBT, right? Want to add open source data transformation to DBT to their toolkits. So lots of people want to do this, that's why it's important. That makes sense. They would come to us, it will cover these things. So that is what the heck is it? And then you tie it all together with the ones who need this will likely be interested in are I decided that it's a data storage product that we all have now. So great creates startups and I think we just in this room created a new one. Now we have a data storage product.

So your turn in the book you got or whatever you have out there, why is this concept important? What will it cover and how does it connect to our products? And for that, some of you, I know I saw some hands go up of self-employed or looking for work, you're the product, right? So as you're creating this strategy, it's the what do I know, what can I get out there? So you can kind of think of it that way. And I'm going to actually give you some time here and then I'll have a couple folks share. And if you just tap to your email, just go ahead and go back to that screen that you have and type the answers to this. But COVID got me used to that,

Audience member 1:

Quantify that profit metrics justify

Adam: Entirely. But that's definitely the next step.

Does anybody have them answer yet?

Are we supposed to be doing this on this blog post?

The concept around that, what would that blog post be a part of? What concept would that be a part of? What would a series that looked like that be a part of?

Audience member 2:

Yeah, so I guess for me the whole blog post would be saved for that accessibility on the web. Why is this not important? Namely because accessibility is very important because companies can be held liable and individuals can also be somewhat held liable if their websites or their products are not fully accessible with this concept. Covered accessibility is a broad topic, so it can cover anything related to sort of APIs that can make things more accessible. How do you utilise screen readers the best practises when building website for accessibility? And I'm not sure the third question, how does it connect to our product right now? Sort of freelancing, but it could connect to any type of software products. I dunno. I think,

Adam: Yeah, and the connection again, like I said, could be to you are maybe an accessibility expert and you can bring that to a company that's looking for it. And I would say the stuff in the middle, this is actually that second question is a good time to realise, oh my gosh, I have more here. You said there are APIs you could, that could be, there's probably more than one post in that, right? So there's a lot of different areas you could go into and each of those then you could bring them out and call 'em a concept and describe them in the same way. The tough part would be, this might feel a little like it's repeating. So you'll have to figure out why is the APIs around accessibility especially important if that's the I'm an API guy, so that was what I latched onto there.

But what you can do with all of these, that was really good. Thanks for sharing. I know I didn't give you that long to answer big questions. What you do with that then is you put it into that catalogue and that's really whatever form you want it to be. I've seen folks use a shared Google sheet for this. This is a much more kind of structured way. What I showed you before is actually again how I usually do it, which is just, I mean it's a Google doc with headings. The thing that I like about this one is that then you can go and you can say as you're prioritising to your point, you decide, oh that Heroku one based on conversations with the team. Maybe that's more important based on keyword research that you do to realise, oh my gosh, everyone is searching for this problem.

Maybe that should go higher. Or where's our product heading? These are the decisions you'll make to help prioritise that list. Again, best if you can bounce that off of folks. We do that internally. It's a thing we bounce off clients and then they say, oh well our Heroku plugin is going away. And you're like, oh, okay, let me highlight that and look it down to the bottom. We'll just take it out. Things that you learn. So putting those, you've got one of 'em already. I know I saw other people writing. I encourage you to turn the dials, go deeper and try to describe those. And really, I mean you're also just kind of making pace yourself with this, but it really does help. You can bounce that off someone else as well and turn those dials on the pattern, maybe go down through the hierarchy if that helps.

And then go and do this same thing on competitors. Think about how are they doing it, what are some things we should take from them? Marshall Kirkpatrick who was the first writer of TechCrunch editor read Wright in his in-house work he's done. He told me that he would watch the YouTube videos of every competitor every week. Anything they put out that week, he would set aside time and watch it because he learned from what are they doing. So the great thing is you know, have a different angle. So you're going to take something and you're going to use that differently when you go and look at what others are doing. And that's another way though. You can generate new ideas, not just this sort of idea from your best blog post ever, which is still a great way to start. How do you get some new ones?

So this is the big question that we ask every client and immediately they go, that's big. I'm not sure I know that, but what your product believes. And it was founded with some opinions going back to Aidan's, you could break your API. So what are those opinions? How can you get into those to be able to come up with those angles? So a few sub-questions that have helped me, what would a developer have to believe to choose someone else? And your competitor might be an open source tool, it might be completely doing it themselves. It might be the big name that you'd never want to mention but you are afraid of. And everyone always talks about

And then the question below here that I think gets it back to how they can find you is what's different about that developer who would choose your product in a world where they could choose that competitive solution, that open source tool, whatever it is, what's different about them that would have them choose you? And that's where you're going to start to get to the stuff that's going to differentiate you and have a much better chance of connecting to your product as well. And for those of you who are being bugged by marketing to create content, create content, there's the reactive way where you just kind of put together a writeup of the latest demo or events. And then there's the way you say, okay, if we're going to do this, if we're going to make this important to our DevRel team, can we make it connect to some things that really matter that you might actually know better than anyone else in the company?

Another stoplight example. So they are API design tool. So of course they have some content on API design, but opinions are baked into their tool and baked into how they see the world. And so that gets included in here as well. And so how would you develop an API? Very different when you come from the maybe design first philosophy as to just going and creating endpoint and then figuring something out. So much like that. Enterprise ready one, this goes on with lots of other things. These are more than blog posts, these are tied stakes in the ground. This is what we believe. And that's really the last piece I want to talk about is that kind of, and if you think about other fields have these continuing education credits and things that they have to do, it doesn't really exist for developers. We learn on the job, we learn from DevRel folks. And so how can you kind of think, oh, what if I was the continuing education for people who care about APIs and accessibility, what would that educational resource look like? And it doesn't mean you're going to make that resource, but it means you could take some pieces from that. This is one of my books and you've seen things like this before. You know what happens when you scroll at the bottom.

This things that someone who likes this also likes this other thing

In your education, in your teaching of your philosophy, this is super important. What are those complimentary tools? And so think through what would that continuing education course be and some of the ways to think about that. What's the subject, what's the categories? When I think of concepts that I told you about, maybe even think this was the categories of a blog, what would those be? Because those could be your concepts, your core thesis. So what are these things that are part of this? I'm going to give you some time to scribble down those. I'll take a couple of answers there. I still have some books left.

Audience member 3:

I have a question.

Adam: Yeah.

Audience member 3:

So the promo angle, teach pattern, does that apply to the concept overall when then they take what it makes sense. If your concept is high level then you may have pieces within that and the three that are some that are more focused on product that are more focused based on European and some that are more focused on implementing.

Adam: Yeah. Yeah. So the concept you have will have elements of all of the pattern, but some of those dials will be turned up more than others. And certainly as you're talking about a continuing education course, you're probably dialling that teach way, way up. But there's still a problem they have where they're going to find that and they're going to choose you over someone else because of the opinion that you have on that problem. Anyone ready? Alright.

Audience member 4:

What is your expectation course in the sense of creating a develop champion programme around your content to basically promote in my case observability for the full stack. So being certified and being able to have those staff that an IC to your company around outages.

Adam: And so how do individual developers talk about observability

Audience member 1:

Performance and reliability of rock application, having that language and having beta and metrics to be able to describe the impact? Sorry, four.

Adam: Yes. It sounds like plenty in there to be able to create an educational course around, and that was one of the conversations I had over lunch was just a reminder that most companies aren't on the cutting edge that all of us are on. And there are companies with individual contributors who are reading about this stuff and saying this is important and kind of going into a void Reddit, there isn't a lot of support, so how can they get that

Audience member 4:

Support?

Adam: Anyone else with what are you going to teach? Yeah,

Audience member 5:

I guess maybe you seen [unclear], but now there having to be error evolution. I think that when mental AI is not the detect thing, in this case, the teaching would be like, Hey, what are the key concepts that each of you should know us basis?

Adam: So what do you need to know about AIand who needs to know it?

Audience member 5:

Exactly. Right.

Adam: Everyone.

Audience member 5:

Well not necessarily that. Yeah, I guess you need to know what is the good step to good start. Okay, so I say hey, you start learning AI into intro and just to get the basis because you should understand the lingo without automatically everything else. It can. Yeah. After that the structure of the code very often be like here four, five topics that for up just get yourself when together people join.

Adam: Right? And so you would've come up with some of those categories or some of those. Exactly. Right.

Audience member 5:

The difference because everyone knows ChatGPT and for a lot of us ChatGPT, this is the only, this is just like people are [unclear].

Adam: Yeah. So if I were you, I don't know if that's a real example or if that's just what you thought of, but if I were you, I would think about who that is. I was at Aaron's talk. I would say that it was for fa ai sceptics. And so is this like, oh you don't think is going to happen. Here's what you, yeah, you don't need to go deep into it. Here's what you need to know. I think starting to would be like it's already happening, what you need

Audience member 5:

To know,

Adam: Right? Yeah. So yeah, zeroing in on who that's for I think is a key piece there. Okay, so I'm going to give you the quick recap. If you didn't get a chance to snap, I'll pose by each of these. So have that opportunity for what we learned here, avoiding the content fails. That was don't be promotional, don't be generic and make sure that you don't have something that's with that there's a clear step forward. Alright, the pack pattern. I heard it was great to get some questions that included it and kind of questioned that. Which of these things am I doing? So again, problem angle and teach. And even though I was too lazy to change where these are on each of the slides, they always were the same level. Remember you can turn those dials, in fact you should. And turning those dials is what will help you create those concepts and help you figure out the different places that you want to focus, the different angle, the different problem, and be able to fill your concept catalogue, which is the next one, and fill it with things that are important and that are going to be connected to your products, to your problem that you're solving.

And really be the core of what you can dip into. If you figure out this is the concept we're going for first, you can have the rest of this year and more on this one concept that you thought of today. And you know what, if it doesn't resonate the way you think it does, you go back to your catalogue, you go back to the pat pattern and you start to figure out what are some other areas we'd want to look at. So these are the three things that you all are going to do. And when you do them, you get to put on the sunglasses. And it doesn't matter whether what you create is red makes you red fantasy. When you've got something that is bullying people in that solves their problem and allows you to educate them on the direction that will help them most. And I know the people in this room are the right ones to do it. So thank you for coming and talking about this today and go out and make those strategic posts. Thanks.