I’ve been working in developer relations for nine years now, doing evangelism and developer education. I’ve tried, read, and watched a bunch of different content. It’s helpful to me to categorize them into four different buckets based on the type of content. And these can be any kind of content, say a blog post, a conference talk, a video, whatever. I’ll use a mix of content here, some that I worked on some that others did. And There are so many types of developer stuff that you might have - APIs, Platforms, Specifications, File Types, etc. - that I’m calling them widgets here. And most of my examples are from Docker because, well, that’s where I work now. But developing this model was instrumental in getting me to Docker.
Inform is the content that says “Hey, we have this widget! You probably didn’t know about it, or maybe I’m just reminding you about it. Here’s why you should care, and how to find out more info.” This is a core evangelism exercise, spreading the good news about a particular product. You generally don’t dive too deep into how to use it. Here’s a video that fits this category, which I did for the Docker 1.9 release.
Help is the category that says “So that thing we have, here’s how you use it.” This is generally beginner content. Help content is the bread and butter of Developer Content. It helps developers understand the details of how to use a particular developer widget. Reference documentation falls into this category, as well as basic how-tos. For a good example, this doc on how to Install Docker Mac OS X
Inspire is the “OK, so you know about Widget A and Widget B. Here’s how you can use them to do this common task. And maybe there’s this thing you never thought about that is surprising but a very important feature.” This can range from something really simple, like a blog post on Getting Started with Docker Toolbox and Compose to something more complex like Dockerizing a Node.js web app.
Delight is a fun category. With Delight type developer content, you talk about things that excite developers. Generally it’s something that pushes the limits of your widget, doing something most people wouldn’t do but shows off the capability of the platform. In this example, two Docker Engineers talk about building Dockercraft, a Minecraft UI for Docker.
It could also be something about how you built the widget. For an API company, particularly, this is a brand building exercise. People won’t necessary be able to able to replicate what you did, but they leave being more confident in using your widget. This is a great example from Google from a few years ago where two Googlers explain how Google keeps it’s Maps up to date.
Obviously, not all content fits easily into one category or another. In my experience, short content (for videos, that’s under 10 minutes) should only fall into one category. And longer form content should have a maximum of two types of content. Any combination works, but trying to do more than that confuses your audience about what they are taking away from it.
OK, I lied. There are actually more than four types of developer content. However, these are the four most effective. I’ve seen a lot tried, and a lot fail. The most important first step is to decide your objective. What do you want to do for the person consuming your developer widget. Everything else should flow from there.