- A common understanding/reminder of the company goals.
- An understanding of the general activities that you should and should not be pursuing.
- A common understanding of your team's purpose and values.
- Alignment between current initiatives and themes.
- A list of current initiatives that clearly identifies the themes that they accomplish.
Developer Relations teams generally have limited resources, be that time, money, people, or anything else. Therefore it makes sense to ensure that you spend your limited resources wisely. Having a good understanding of your company and your audience will help you maximize your impact and ensure that your efforts stay focused. In this section we will be examining your company's goals and how they align with your team. We will use this as a basis to understand the team's purpose and overall goals which will then allow you to align your initiatives.
First let's dive into some background information on the DevRel funnel:
"A handshake is worth more than a click" - Tim Falls
There are many reasons to engage in developer relations. Some of these are listed here:
- build awareness
- get usage
- trust
- credibility
- nurture long-term relationships
- explain complicated tech to people who know more than you
- encourage peer support & recommendation
- value customers even if the person's company cannot pay for your product right now
These reasons all align with some part of the DevRel funnel. This DevRel funnel is closely related to Dave McClure's AARRR metrics which has been extended by Phil Leggetter to work better for your purposes. [1] [2].
\ /- Awareness (of the platform and what it does)
\ /- Acquisition (e.g. registration, sign-up, download, install)
\ /- Activation (e.g. first API call, active usage in app)
\ /- Retention (e.g. active users after 30/60/90 days, use of new features)
\ /- Revenue (e.g. users that pay to use the platform)
\ /- Referral (rare but valuable -> community champions)
\ /- Product (involvement in building and getting feedback on product)
Note that at each stage of the funnel some drop off occurs. People that are in the late stages of the funnel are generally heavily invested. Those are the people that you can bug more with questions and who will likely want to give you feedback on your product.
To help with the understanding of where typical initiatives fall Phil provides a handy disambiguation:
| Awareness | Acquisition | Activation | Retention | Revenue | Referral | Product | |
|---|---|---|---|---|---|---|---|
| Docs & Reference Guides / How tos | x | x | x | ||||
| Library development | x | x | |||||
| Quick start apps | x | x | |||||
| Blog posts, Tutorials, Hacks | x | x | x | x | |||
| Webinars | x | x | x | x | |||
| Event/Meetup Sponsorship | x | x | |||||
| Talks, Meetups, Conferences | x | x | |||||
| Support, Zendesk, StackOverflow, Forums | x | x | x | ||||
| Pre-sales technical discussion | x | x | |||||
| Alpha/Beta Programs | x | ||||||
| Office Hours | x | x | |||||
| Capture developer feedback | x | ||||||
| Help company recruitment | x |
Outreach activities like blogging, conference and meet-up talks, as well as hosting meet-ups and peer commentary can cause developers to become aware of your product. Awareness can be broad or deep, depending on, for example, what type of blog posts are written, what you do when you attend conferences, and what kind of talks you give at meet-ups.
Acquisition comes from activities like blogging, personal interaction, or meetups. It is important to meet developers where they are. On top of that, marketing should never be obnoxious to developers. When talking about the competition, it is best to stay graceful. If the competition is the better choice for your user, tell them that. Misleading developers causes more harm in the long run to your numbers and your reputation.
From acquisition, the next step is activation. This can be helped with documentation, quick-start apps, great SDKs and good support. The focus here should be to make developers successful. If the drop off between acquisition and activation can be measured and seems too high, this can be an indicator of problems in the onboarding user experience. Cristiano Betta has produced many resources that are helpful in evaluating and improving your product's developer experience [3].
Once your developers are on your platform and have made their first API calls, you want to make sure they stay for a while. Retention can be achieved by providing a community around the products and, of course, great documentation. Keeping track of users' activities can indicate user experience issues, documentation issues, or community issues.
Ideally DevRel's should not be measured on making money but rather focus on bringing developers through the door. Your goal should not be to sell but to help and lead. Aggressive selling may cause damage to your and your company's reputation. However, depending on where you work, revenue may be something you are measured on and you may be expected to demonstrate a Return on Investment (ROI). In this case it is important that you strive for an agreement about the impact you can achieve.
One of the last stages in the funnel is the referral stage. This is where you want to ensure that staying in your community is worthwhile for users. Champion programs are more and more popular in the DevRel community. The DevRel Award-winning Joe Nash talks about how to build scalable champion programs [4].
The last stage is product, where developers contribute back to your product development. In this stage there is general quite a bit of personal interaction and community work. Acknowledging people for their contributions can go a long way.
If you locate any significant drop offs, these are areas that you can work on improving. Note that some drop off is normal and you should not expect every user to advance through to the referral or product stages.
To conclude this section, let us look at the 4 general overarching themes that team's tend to go for. Here are a few examples of people that do well in those curated by hoopy [2] :
| Theme | Company |
|---|---|
| Awareness | Glitch |
| Engagement | Outsystems |
| Conversion | redislabs |
| Perception Change | Microsoft |
All of these campaigns are examples of very well done DevRel work. They are also examples of very focused work towards a goal. No company does the best at everything or even aims to do that.
- Decide where the created resources should live (GitHub/Google Drive/...) and ensure this is accessible to the team.
- Find your company goals and ensure you are familiar with it. You may want to print a few copies so that your team can work with them without their laptops.
- Prepare a presentation of the DevRel funnel (or print out the above section for your team).
Look at your company goals for the year (if applicable). This will give you a better idea of where you are headed overall and how your team fits into the broader landscape. It may come in handy to jot down a summary of the company's goals.
Here the organization overview chart from [Step 2](../Step\ 2:\ Know\ your\ team\ &\ initiatives) will come in handy. You should not focus on the entire funnel. If you have many teams that are in this space, ensure that any overlap makes sense. This may be different for the different products. It may stretch over multiple parts of the funnel.
Bonus: If you have metrics for different parts of the funnel, this will help you figure out where your focus should be. Look for obvious drop offs that you could address.
Which part of the funnel will you work on for which product? Will you be increasing awareness for your product? Should you be working on increasing retention? Themes that work for one company will not work for other companies so make sure to base your choices on your situation. Do not choose more than 2 overall themes to avoid stretching yourselves too thin.
"What developer relations should mean to a company really depends on what the company's goals are." - Phil Leggeter [1]
What is our DevRel mission statement?
Go through the list of initiatives and discuss whether or not the initiative fits with your mission and your themes for the year. Add the theme and how the initiative aligns to it to the document.
If an initiative does not have owners assigned to it or has other missing parts, this is a good time to fill in the gaps.
You may find that this process shrinks your list of current initiatives which will make you more focused. For these dormant initiatives, keep the documentation around but mark it clearly as dormant. Make sure to note down any actions that need to be taken to leave the initiative in a good dormant place (e.g. informing stakeholders).
Too much on your plate? Decide how to priotitize with the Allthethings Prioritization Matrix.
- Working through these exercises beforehand will help you in the actual planning meeting. Ensure, however, that you let the team take the lead as they may have other ideas.
[1] Phil Leggeter on the AAARRRP funnel.
[2] The content of this section is based on a training by hoopy.
[3] Cristiano Betta has multiple very good talks on Deadly Sins in Developer Onboarding and Live API teardowns which are incredibly valuable in teaching you how to approach developer experience.
[4] Joe Nash speaks about scaling external advocacy without losing your soul.