Staying true to our mission to enable learning and experience sharing among community members, we have recently launched DevRelX sessions (hour-long, community-led discussions). In every session, community members present the topic they’re experts in and, together with a group of DevRel professionals, discuss challenges and share insights on various topics. To participate in future sessions, join the DevRelX community.
This article summarises the second DevRelX Community Session that took place on April 28, titled "Content for Developers: What and How". Karl Hughes, CEO & Founder at Draft.dev, presented tips and led a group discussion on:
- What methods can DevRel teams use to curate content that resonates with developers?
- How to find and pick your writers. Are external writers worth the trouble or do we need to hire in-house?
- How can we scale up our content production? What processes and tools are necessary?
Other session participants were:
Ash Ryan Arnwine, Director of Developer Relations at Nylas
Vera Tiago, Manager of Developer Advocacy at OutSystems
Alvaro Tejada Galindo, Senior Developer Advocate at Nylas
Elvis Kahoro, Developer Experience Engineer at Warp
The first problem most people come to when they start talking about content for software developers is “what do we write about?”. This is a really important question to ask yourself because what you're going to write about should make a big impact on who will write it, how much content you want to produce and how you're going to distribute that content. There are a few ways you can think about this and Karl started the session by highlighting a few key methods.
Karl: It all comes back to what is your overall company strategy around content, around developer evangelism or developer relations, and where does this fit in. Some organisations approach developer relations and developer content with a marketing-first mindset, and for other organisations that's support-driven. That probably dictates your KPIs. That is why knowing where you fit in is going to be really important in helping you determine your KPIs and deciding what to write about.
When you're getting started and looking for some ways to come up with ideas, there are four key things that come to mind:
1. Documentation
One of the most common ones is supplementing your documentation. Every software company that has a developer product is going to have some kind of documentation. Typically this documentation is public, which is great because it allows developers to take a look at what's possible with your app without actually having to sign up for full access on day zero. That means that making your documentation public is the first criterion. But then, what a lot of companies realise is that we need more than just dry documentation. We need a little bit more depth such as specific use cases or tutorials that will present users with examples of combinations, tools and tech that they can use along with your tool. It's really important to show you more than just the base documentation.
Such content can live within the documentation or a dedicated section called tutorials or examples, or use cases, and sometimes it can be found on the company blog. How to structure this content is entirely up to you.
Documentation and supplementing your documentation is the first key thing to begin building out as you start going into the developer market.
Ash: When you're thinking about those infinite combinations of tools and things that you can use with your APIs, do you have any favourite methods for just ideating on that? Do you sit around a table and come up with ideas? Do you listen to customers as the first thing?
Karl: This gets tricky when you're at the early stage because if you just launched the product you don't have enough customer base to tell you what you should focus on. If you have been around a while go, to your customer support team and ask them: “what we get asked about the most?”, “What kind of questions are coming up commonly around our documentation?”. If you are a developer advocate and you've got some community presence, go out there and ask the community what they'd like to see.
Starting from scratch
Otherwise, if you’re starting from scratch, you have to do a little bit of feeling and try to understand the direction of the developers you're trying to reach. For example, if you're a tool that's going to work really well for Rust developers, then you should go ahead and write Rust tutorials. While, if you're a more mainstream API that's going to be consumed by a general population of developers, you could start with Javascript, maybe Java if you have a more enterprise market, or Go if you have a more cutting edge market, or if you know that your customers will use that. You have to ask yourself what are our users going to ask for, where do we get the most bang for our buck?
The other way to approach it is if you know that there are certain niches where there are a lot of opportunities to grow. To make it specific, let's say you're a continuous integration tool and you're in a big crowded market with a lot of other established players, but maybe there aren't many continuous integration tools that focus on iOS development. In this case, what you can do is to start to build your content around e.g. the best way to do continuous integration for iOS development, or “here's how to use our tool for integration for iOS development”. Typically this is going to be more bottom of the funnel content.
Another common question for a lot of organisations is “how do we introduce new users to our tools that aren't already familiar with what we're doing”? That's where the next couple of methods come in. One is keyword research and the other is community research. These are worth talking about in tandem.
2. Keyword Search
Keyword research is a quite traditional digital marketing practice where you use a tool to understand what software developers are searching for, how much search volume there is and how difficult it will be to rank for these topics. For example, for someone in the data engineering space, there could be key terms like ”data governance” or “data operations”.
Though keyword research gets kind of a bad reputation because it sometimes tends to be associated with keyword stuffing and low-quality content, that's not really true anymore. Search engines don’t reward that kind of junky content as much as they used to and are getting better about identifying it.
If you write really good content that's actually genuinely helpful for developers targeting these keywords, you will rank high. On the other hand, if you write really fluffy keyword-stuffed articles produced by freelance writers who don't really know much about the subject, it's going to be a lot harder to rank for or keep your ranking even if you do manage to get the front pages. The best would be to blend the best of both worlds -
do your keyword research, know who you're targeting and then write really good content that works for your audience.
What I like about keyword research is it's predictable. If you use the tools correctly, you can usually tell which keywords are possible for you to rank for relatively quickly and you can get new traffic every month by just focusing on that.
Blog with Part 2 of this session will follow soon. There we'll talk about community research, understanding developer trends and how to find writers.
Kudos to Karl and the rest of the group for a session filled with learning. And a special shout to Vera for a very talented illustration summarising it!
Thank you, @KarlLHughes, @SlashDataHQ, @elviskahoro, @ashryan_io, @Blag, and MK, for the excellent focus group yesterday about Content for Developers - What & How. I got great insights about generating ideas, and I'm looking forward to the next one! #devrel #developermarketing pic.twitter.com/pajOeiE8LJ
— Vera Tiago 🥑 (@veratiago) April 29, 2022
Top comments (0)