Developer relations is the combination of activities, programs and tactics to get developers using or developing for your organization’s product or ecosystem. The goal of a good developer relations team is often to make your organization’s product or ecosystem the first choice for developers. (You may be doing this just to sell more of your product or you may be doing this because you believe your product’s mission helps make the world a better place. You are still trying to get more developers using your product.)
What’s the goal of a good developer relations plan?
Your developer relations plan needs a goal that you can focus on. You need to be able to measure the results of your activities so that you know what you should do more of and what you can do less of.
Some potential goals for a good developer relations plan might include: (Some of these by Patrick Chanezon.)
- Increasing the adoption of your organization’s product. Example: more people using Firefox.
- Increasing the number of available complementary goods. Example: more 12 factor apps running on Cloud Foundry.
- Providing an opportunity for developers to profit. Example: an app store for developers to list their applications.
- Growing the number of people that benefit. Example: training companies, consultants, app providers.
- Reducing the cost and risk of using your product.
- Increasing the percentage of developers that are developing only or mostly for your product.
- Increasing the network effects in your ecosystem.
- Decreasing the cost of adopting your platform or increasing the cost of leaving your platform.
- Creating an environment where developers just assume they’ll use your platform.
- Encouraging third party tools, trainers and consultants for your platform.
- Creating a community of volunteer advocates.
Some developer relations groups also act against the competition. I don’t think that’s a long term strategy. Your product and ecosystem have to be good.
What are the stages of a developer relations audience?
You can move from one stage to the other using many different techniques. Breaking down the stages a bit further, you can map how specific evangelism activities like blogging or talking, might take you from one to the other.
Who should you have on your developer relations team?
While we usually talk about developer relations as teams, we also need to look at their functions. While each team has a primary function, functions are often shared between teams. Mozilla has outreach and content teams. Google is also organized this way, as presented in a talk by Patrick Chanezon.
- Outreach. Creating awareness of the product or ecosystem among developers. Most outreach efforts include evangelists. These are people that go out and speak, engage with others, teach enough to get people started, write blog posts, let large numbers of people involved. They are typically most involved in the outreach and awareness part of the program.
- Content. This includes tutorials, documentation and examples. Making sure that developers that are interested in the platform have the materials they need to learn it. This team should include technical writers, educational experts and programmers. These are the people that are most involved in the online training part of your program. They write documentation that lets people learn how to use the technology. Sometimes they write the examples. Sometimes they create training or online tutorials.
- Support. When developers start using your product, they will need people to help answer their technical questions or help resolve the bugs they find. This team usually consists of support engineers. They are around to answer questions, help people get going, create code examples. Often when bootstrapping, this function comes from the evangelists but it’s really a different type of personality and role. This team is most likely to provide valuable feedback to the product teams.
There’s another couple of roles worth calling out.
- Program managers. A successful developer relations program often relies on programs. These might be things like a world wide community run, simultaneous events or a “free phones for apps†program.
- Key stories/participants/case studies. These are people that have a story that successfully highlight what you are trying to do. And, while they might not be evangelists, they are competent spokespeople. You talk about them, point people at them, highlight them, enable them to tell their story and help them spread it.
- Event managers/coordinators. Smaller groups might have several volunteers. Larger organizations might have lots of volunteer meetup or hackathon organizers and maybe even a paid staff team to support them.
- Community management. Whether or not you have an official community manager, there are probably numerous people helping out with “community management” whether it’s onboarding new contributors, reviewing patches or answering questions on the mailing list.
What are the key components? What types of tools and projects are useful?
It’s useful to first look at your project’s strengths. Do you have a large community? Strong contributors? A highly followed blog? A strong culture of global meetups? A clear brand?
Some of the projects and tools you might consider are:
- Programs that support your goals. For example, Mozilla ran Phones for Apps.
- Messages/materials. Developer relations can either include product marketing and press or work closely with those teams to develop messaging and materials that support the goals and the audience.
- Events. Events can include everything from monthly meetups to hackfests to large annual conferences. Many teams often divide events into the organization’s events, sponsoring others events and sending speakers to events.
- Training. As people join your ecosystem or start using your product, they are more likely to stay if they can get the training they want. Cloud Foundry has “dojos†– a place at several member organizations where interested developers can go train with a more experienced member for six weeks.
- Examples. A key component of learning is being able to see how something is done and copy it. At Mozilla we created Demo Studio to allow people to share and build on others work on the web.
- Documentation. Documentation is key to a project for two key reasons. One is discoverability and the other is learning and support.
- Contributors. Depending on the type of product or organization you are supporting, you may want programs in place to specifically support contributors. This may be as simple as swag or as involved as official titles and budget for programs and travel for them.
- Feedback mechanisms. An important part of many developer relations teams is providing feedback mechanisms for users to give feedback to the product teams. It helps to put into place objective tools and mechanisms for this.
- QA forums. Question and answer forums like StackOverflow have become critical to how developers expect to find help when they are working. Having a standard place where your experts will be will help.
- Membership. Often membership can support the different groups you want to grow. You can have users groups, contributor groups, advocacy. You can use titles, mailing list membership, swag and travel funds to distinguish and reward them.
- Discussion. A place where people can come and chat and “hang out†with your community is important. Q&A forums often give them answers but not a sense of belonging. Also discussion groups are often an easier way for really new users to get started.
- Advocates. Recognize our key advocates and give them a megaphone. Connect them with the press and speaking opportunities.
What does your Developer Relations plan and group look like? What would you add to create your ideal plan?