7 (Not-So-Deadly) Steps to Create a Successful Developer Relations Program

Developer Relations (DevRel) is an increasingly important concept in the API world. It involves nurturing mutually beneficial relationships with API consumers, acting as a conduit between them and the organization, and advocating for their best interests.

Despite its growing importance, DevRel is often treated as an afterthought in most companies. Many don’t know how to execute the program properly—leaving DevRel to prove their value and return on investment.

Recently on our podcast, Adam DuVander and I spoke with Jeff Schneider, lead developer advocate at Asana, a work management platform.

Let’s dive into some vital lessons Jeff learned about creating a successful Developer Relations program.

1. Understand Your Target Audience

Jeff believes understanding your target audience is the key to crafting successful outreach strategies.

As yourself, what is the background information of the target audience, and why are you focusing on those markets?

Asana effectively manages its advocacy program by organizing its developer community into three different personas:

• Third-party developers—professional software engineers from outside companies who build integrations with Asana
• Second-party developers—customers from large enterprises who customize Asana for their own use
• First-party developers—in-house teams that build internal customizations

2. Gather Developers’ Viewpoints

“The most important thing would be to sit down and listen to developers or watch them interact with the API because they’ll give all the answers,”— Jeff Schneider.

Analyzing developers’ viewpoints can reveal things you didn’t know about your API. By listening and empathizing with them, you can better understand their needs and identify any missing details in your product. Conducting developer conversations can also help you create important documentation and case studies.

You can get your developers’ feedback through a variety of different channels, such as surveys, UXR (user experience research) sessions, phone calls, support tickets, face-to-face interviews, virtual meetings, and community forums.

Jeff also recommends engaging new employees, as they bring fresh perspectives to the table. If you ask new team members to build an app from your API, you can record any frustrations and frictions they encounter and use those as a base for improvements.

You can also create a developer preview group that gives feedback before any new feature is released. At Asana, Jeff presents new proposed solutions to his early access group and ensures it meets their needs before rolling it out to the marketplace. This allows you to quickly address any bugs before pushing live.

3. Build a Multifaceted DevRel Team

“I have a list of eight to ten sub-teams within Developer Relations,”— Jeff Schneider.

Developer Relations is not a one-man job. Depending on your organization’s business model and how the API fits into it, you can have different sub-teams within the developer relations department. Each advocacy band should have well-defined roles and responsibilities as well as clear communication structures between teams.

The sub-teams may include documentation, SDKs, internal evangelism, external evangelism, and a partner-to-partner engineering team.

4. Allow DevRel to Make Decisions

“I feel fortunate that we’ve been given the autonomy and structure to achieve our goals and work towards that North Star metric.”— Jeff Schneider

Although the Developer Relations team works cross-functionally with other teams within the organization, Jeff says they should have the autonomy to set their own function, mandate, and mission. This will enable the team to focus on big-picture goals without the need to constantly justify their work.

Asana has overarching, high-level developer relations goals that everyone works toward. However, the people closest to the work develop their own OKRs (Objectives and Key Results) based on the immediate near-term goals. By breaking down high-level goals into individual OKRs, you enable the small wins and keep teams motivated.

5. Measure Success

Look at retention and expansion metrics to measure the success of your evangelistic activities. Remember, it’s the quality, not the quantity, of your integrations that matters.

According to Jeff, customers that build products using your API are stickier than those who don’t. Furthermore, as more teams within the customer’s company continue to integrate with the API, the better prepared you are to expand.

6. Act on Feedback Structurally

Jeff emphasizes the importance of having a structured process for creating action items out of developers’ feedback.

For example, after collecting feedback from API consumers, you can:

1. Synthesize and categorize the most important takeaways
2. Rank your list of issues from most impactful to least
3. Submit this list to the internal API team

This will help create a more organized roadmap prioritizing high-impact solutions.

7. Provide Robust Developer Tooling

Jeff also recommends you provide robust tooling to make your API consumable. Having a comprehensive and easy-to-navigate developer experience is crucial.

To start, you need useful reference docs, guides, SDKs, and example code. Rather than hand-curating your content, you can use the OpenAPI specification to easily generate accurate reference docs. OpenAPI allows anyone to quickly determine how your API works and makes it easy to create and update SDKs.

It’s also important to learn from companies with successful API tools. By analyzing their implementation process, you can quickly learn the ropes and avoid common mistakes.

According to an Asana survey of about 13,000 people, the average person uses ten apps and switches between them 25 times a day. So, concentrating your tooling on a single source of truth can reduce your customer’s mental overhead and save you money.

Bonus: Don’t Forget Internal Evangelization

Before external evangelization, Jeff encourages you to run through internal evangelization to ensure those within the organization are excited about the API. If you can’t ignite excitement internally, it will be difficult to do so externally.

Show your internal teams the possibilities of the API and how external customers are valuably integrating with it to boost morale. Internal evangelization can also help to demystify the API so non-engineering teams can comfortably spread the word about its capabilities.

Subscribe to our podcast to learn more about how developer relations programs can impact your APIs.

And, if you’re curious about who runs our DevRel team, our go-to here at Stoplight is API evangelist and biking enthusiast, Phil Sturgeon. You can find him on Twitter at @philsturgeon.