I’ve been working on a large (30 pages in lovely PDF) report on developer relations and marketing, especially, though not exclusively, targeted at people like cloud and service providers who are discovering the need to cater to developers. It’s published now. As with most of my work, I’ve tried to inject a bunch pragmatic, tactical advice alongside just enough macro “trends and drivers” nonsense to make the case for why you should care and then how you should start planning what to do next.
The report is available for 451 clients, but here’s the key findings which summarize the meat-y parts of the report:
- Developers have played a large part in driving the success of companies like Microsoft and SAP, consumer websites like Facebook, and service providers like Amazon Web Services and DigitalOcean. These companies’ offerings can be traditional ISV software, SaaS,
infrastructure delivered as a cloud service, or even “Internet of Things” devices.
- While developers may emote a distaste for traditional marketing,they are actually very responsive to finely tuned developer relations and marketing programs. These programs revolve around understanding how developers fit into the offering’s strategies and plans, creating value propositions that appeal to the needs and desires of various types of developers, and ensuring that you “show up” to relevant developer communities.
- There are many developer communities, both on the Web and in real life; most of them will be third-party sites that are not under your control. However, as developer relations programs grow, gaining more budget and resources, building your own developer community may be beneficial.
- One of the strongest clusters of developer value propositions centers on speed and increasing productivity: getting software to production faster, ensuring very low barriers to entry to try out new technologies, and otherwise simply moving faster.
- “Content” (text, video, audio, documentation, and even source code) is one of the primary mediums for interacting with developers, and, depending on the type of content, it has many different applications in developer relations programs.
- There are many topics for content, but some of the more popular ones are educational materials about using your offering; “war stories” about how you solved a difficult problem; the story of how you made something (aka “sausage making”); commenting on industry trends and how your offering fits in; and case studies on how developers have used your offering. Documentation and source code are key types of content for developer relations programs.
- Documentation is a particularly important type of content – both “manuals” and narrations or tutorials that are in a more natural voice. With rare exception, every developer relations program should look at documentation as a core type of content. Source code and the social networks associated with sites like GitHub are also an important type of content that most developer relations programs should have.
- Conferences continue to be an effective engagement point for developer relations communities. They can range from large, vendor-centric events to small “unconferences.” Companies have reported to us that both types can be highly successful, depending on the tactics and conference.
You can always sign up for a trial to take being a client out for a spin.
Thanks to all the people who helped with it, esp. Claire Hunsaker and Barton George who were extremely generous with their time and suggestions, and of course my 451 colleagues who gave much input. The organizers of DevOpsDays Austin and SAP’s developer relations program staff we also very generous with their time and comments for the related case studies.
And, of course, I’m thankful for all that time I was lucky enough to spend at RedMonk pacing through the mechanics of getting non-developers to understand us nerds. If you haven’t read the seminal The New King Makers, go read that or much of this fancy PDF of mine will seem odd.