What makes for developer buzz? Getting regular programmers to share thoughts and information in developer communities (not necessarily just social media). What makes them valuable is that their posts get engagement. So how do you ignite developer buzz? You give them a technical story to tell, then let them — and hopefully several developers like them tell it in developer communities all over the interwebs. Here’s the thing: You may use paid channels to promote the content, but truly persuasive developer buzz happens organically.
Organically shared information is much more authentic. For a highly skeptical community like a technical community, it has more impact. That is not to say the content that is shared can’t be paid for in some way — either paid for content creation or promotion or both. But don’t pay for developer-to-developer (D2D) sharing if you want to build authentic and persuasive developer buzz.
You need to build a story arc that is bigger than one piece of technical content. And it should be in the context of a technical resource hub of knowledge. Marketers are well aware of the three categories of content that follow buyers on the buyer’s journey, and they all have to be technical to varying degrees:
- Awareness. First, alert your audience to a problem — perhaps a hidden one, or unacknowledged one, or a problem that many feel is unsolvable.
- Education. Create content that helps the audience understand why it’s so hard to solve, and what a solution could look like. Don’t just give your solution, but give the rubric. This gives your audience room for discussion.
- Decision. Enter your company, the hero that has the much sought-after solution.
But, wait. There’s more.
For a technical resource hub that informs developers and incites them to share knowledge and talk about your content, you need more. You need developers to use your product, or at least want to, really badly. Then, they will talk about it. This developer’s journey is as important as the buyer’s journey, even if the developer is not the buyer. This is what creates the developer who chats up other developers on your behalf. To enable these developer community conversations, you need to create a technical content playbook using a combination of technical content assets.
Technical Content Defined
- Technology white papers. Long-form content that is technology- or concept-focused rather than product-focused.
- Thought leadership articles. Awareness pieces drawing attention to an overlooked problem that merits attention.
- Public documentation. Documentation designed for someone who has never encountered your product.
- Technical blogs. Blog posts — shorter-form content that announces deeper dives in the context of a technical problem, solution, or story.
- How-to’s. Technical articles about how to use your product in a specific system.
- Tutorials. Technical articles about how to use a technology or technique, not your product.
- Product overviews. Offers product descriptions and comparisons.
Here’s an example of how that could be deployed:
Technical Content Playbook: Play 1
- 3 “state of the nation” technology white papers about the tech in question
- 5 thought leadership articles, each around a specific problem in the space, how the problem is typically solved, and how product X solves it
- 3 product overview articles
- 20 how-to’s
- A set of 24 blogs covering 3 months
- A set of 48 social media pieces for sharing on Twitter, Instagram, Facebook and their Slack channel
- Public documentation
For the Road
Creating a technical content playbook is the first step in developing a resource hub that can support and build developer buzz. By offering valuable, deeply technical content, you hedge your bet that developers will use your content when participating in conversations with other developers. And presto — Organically, you have created developer buzz.