Blog Home

Creating Marketing Content Developers Actually Want

Creating marketing content for developers is tricky because content should reflect the needs of its audience, and in this case, developers are not your typical audience.

What developers want.

Most content produced for developers covers documentation and tutorials, case studies, use cases, code or project samples, and thought leadership pieces. But what do developers actually want?

Developers are pragmatic and solution-oriented; they want content that gets to the point and addresses the question, “how does this solve my problem?” Developers differ from normal audiences in that they are grounded in reality and want straight forward answers, void of vague statements or fluff pieces.

  1. Documentation and tutorials.

    The number one piece of content software developers want is documentation and tutorials; these should be technical, succinct, and factual. Most importantly, the documentation needs to identify the benefit of the product and how it solves the developer’s problem.

  2. Code and project samples.

    Developers are tinkerers at heart, and they want to figure something out first-hand, rather than just reading about it. Code and project samples provide a quick way for a developer to get acclimated and start testing features out for themselves.

  3. Trainings and meetups.

    Software developers seek out community because they are naturally skeptical of brands. I speak more about this in my other post, “What Is Developer Marketing?” where I explore the reality that developer marketing is not marketing. To put it simply, developers do not want to be sold to, they want solutions. Content and resources that facilitate peer-to-peer or 1:1 discussion is highly valued; it is why developer communities at Stack Overflow and Reddit thrive. The ability to create physical and digital content events, such as webinars, trainings, hackathons, and meetups encourage discussion with the community at large and provide needed validation, not from the brand itself.

  4. Developer diaries.

    These are not thought leadership pieces. Whether it’s a blog post or video, the point of a dev diary is that it is produced from the perspective of a developer; not a brand speaking to a developer. A dev diary is more functional and direct and will offer a line of thinking that discusses how a product or solution worked. As discussed, developers are more inclined to believe one of their peers than a company, and these are great for initiating conversations and sending a “you’re not alone out there,” message.

 

How to plan for marketing content for developers.

At a macro level, developers binge on content and are not shy about evaluating multiple solutions until they find one that fits. Creating a dedicated resource hub is ideal because it allows developers to peruse content at their own speed. However, an unstructured journey can lead to passive consumption and developers viewing content that might not be relevant or useful. For this reason, resource hubs should be complemented with triggered nurture emails and on-site suggested content to help guide developers to take meaningful actions. 

Curate content.

While developers find their own path, it’s incredibly important to provide a framework for them. Curating content for different segments of your audience helps them to hone in on assets they need right then and there. A best practice when providing resources for developers is to ask their level of familiarity and their objective, rather than assume everyone is starting their journey in the same place. Once basic information is understood, developers can then be nurtured via a personalized campaign precise to their needs, wants and requirements.

Marketing content for developers should be curated and suggested based on:

  1. Explicit preferences via forms or surveys.
  2. Implicit actions, such as previous content engagement.
  3. Relevance to their objective.

Speak to a broad audience.

It’s important to remember that every developer audience is filled with both seasoned and novice developers. Core pieces of your content should be written broadly enough to address any and every level of developer. I tend to lean towards writing for the lowest common denominator; experts can glance over the content and discern what is useful to them, but it doesn’t always work the other way around. A simple trick when building content is to provide both long-form e.g., whitepapers, documentation, and tips and tricks to appeal to all levels of developers, not just the experienced.

In the end, make sure the content is geared towards those considering using your product and need straight forward information to advise their decisions. The goal is to make the journey to adoption and usage of a product easier for the developer so they can become an advocate and promote for you within developer communities.

Embrace community.

Anything that promotes peer to peer interactions is great. Meet-ups, training sessions, and office hours are effective, whereas webinars, while good for introductory material, are not particularly engaging for most developers without accompanying Q&A’s or AMA sessions. 

Validation = advocacy. Take Amazon reviews for example—while most are brief and anecdotal, they do hold weight and play a big role in the decision-making process. This is the same for developers, but instead of reviews, they are seeing what their peers are saying about these solutions on sites like Reddit, Github, and Stack Overflow.

When building marketing content for developers, a company should look for ways to incorporate the voices of their communities and become partners with their most core ones. Seeking and establishing an active and content resource presence (as opposed to driving developers to your company site) encourages developers to provide their thoughts and validate or disprove claims in organic conversations. 

A developer diary is a great way to initiate developer-to-developer sharing and can lead seamlessly into a dev community to start an organic discussion. A good rule of thumb would be that any content that is not documentation should be driving to some kind of community.

Seek out feedback.

Get feedback from software developers. If you have the opportunity, set up a power-user program or some kind of feedback program where developers can engage and discuss a product’s features or extra pieces. Try providing forms where developers can submit feedback and opinions so they can feel like their needs are being met, and you can better create products and resources to fit those needs. Creating and bolstering community and sharing helps to build a more inclusive environment in which developers feel they are a part of a larger goal. This empowers developers to advocate for solutions both for themselves and on your behalf.

 

The Iron Horse insight.

Developers take umbrage with generic content and resources that are transparently self-serving. Address this issue by ensuring marketing content that targets developers is led by a marketer that was previously a developer or at minimum communicates with developers frequently.