Made by
Made by
ancient-architecture-columns-161085
To devise a developer relations strategy you must understand both your company’s needs and the tactics you can use to meet them.
The four pillars of developer relations
At Hoopy, the developer relations consultancy, we think of dev rel tactics as falling into four buckets that we call the four pillars of developer relations:
The pillars are all about what you do in your dev rel programme. When you build strategic initiatives to meet your programme’s objectives, the activities you choose will come from one or more of the pillars.
Looking at the four pillars, you can see that they divide into two halves. Outreach and community are what we’d typically think of as developer relations. Whereas product and education/support fall more into developer experience.
In practice, any developer relations programme needs to consider all four. Even if SDKs, for example, are not a direct responsibility of your dev rel team, you still need to plan for how they impact your developer community’s relationship with your product.
The AAARRRP funnel
The precise mix of tactics that you choose will depend on your broader strategy and where in the AAARRRP funnel the developer is.
Outreach is often the most visible part of developer relations and it comes in broadly two flavours: online and in person.
You can think of outreach as the activities you undertake in order to drive someone from not knowing your product to becoming a retained customer. Your outreach makes people aware of your product but also helps them to understand it, overcome their initial objections, and push through to make some commitment to using it.
This offers a great example of why the divide between developer relations and developer experience isn’t always clear. You can use outreach tactics, arguably dev rel, to drive someone from awareness to acquisition but your approach will be much more effective if you have high quality exploratory documentation, for example, which arguably falls under developer experience.
An active community around a developer-targeted product is a key requirement for many developers. A community provides evidence that people, other than the vendor, are using the API, cloud service, tooling, or whatever it might be. It also amplifies your developer relations programme’s efforts.
Broadly, community is about creating a framework that enables developers to be successful with your product. It’s the substrate through which your developer relations programme takes place. If nothing else, your developer community is a process for recognising the individuals who engage with your product and helping them to amplify your strategy while also meeting goals of their own.
Bringing it back to the developer funnel, community has a role to play in each stage but it’s most focused on moving developers from the acquisition through to the product stages. The social proof, additional support, and supplemental activities that a community delivers are all crucial in helping developers to feel comfortable about committing to your product.
Some dev rel teams are situated in their company’s Product Management department but others find themselves in Marketing, Engineering, or elsewhere. What role can those teams have in shaping the product?
We increasingly talk about developer advocacy, rather than developer evangelism. Partly that’s because advocacy is a two-way thing. As developer advocates, we advocate our products to developers but we also advocate on behalf of developers back to the company. If nothing else, a dev rel team should represent the voice of the developer in product discussions and ensure that developer needs are heard.
Often, dev rel teams become more directly involved in delivering the product. Some dev rel teams create SDKs, integrations, and other parts of the developer experience that are effectively an element of the product itself.
In terms of the developer funnel, dev rel’s role in the product is about moving someone from activation –– i.e. their first API call –– to becoming an active and committed user.
Depending on the size of your company, educating, supporting, and enabling developers is likely to be a responsibility shared by several different teams. You might have dedicated support, developer success, and developer education teams. In other companies the dev rel team might be responsible for all three.
Whether or not they are directly part of your team’s remit, your strategy should take account of the activities necessary to educate developers and to support them outside of your company’s formal channels. For example, knowing the process and capabilities of your dedicated support team will help you know when and how to pass a customer request from, say, Stack Overflow into your formal support system.
More often, though, your dev rel team’s role will be to offer support to developers who are not yet customers and to provide educational materials that your dedicated tech writers wouldn’t cover.
Education and support are essential to ensuring that developers can become productive on your platform and, so, they play a strong role in moving developers further down the funnel.
The four pillars of developer relations offers a handy way to think about the tactics available to you in pursuing your dev rel strategy. Choosing the precise mix that’s right for your company will depend on your programme’s objectives. If you’d like help in creating or fine tuning your dev rel strategy, get in touch.