My DevRel Strategy Breakdown

I've found that most Developer Relations professionals struggle with defining strategy & measuring success. I myself have been through many strategy format revisions before landing on the best for my teams.

We don't have a magic user manual for DevRel or even all that many industry resources, even though we're all great at building resources for developers. Therefore, I wanted to share how I think about DevRel strategy and how other professionals are thinking about it as referenced in Developer Relations: How to Build and Grow a Successful Developer Program.

My strategy outline usually has headers that look like this:

• DevRel Objectives
• Developer Products
• Developer Audience
• Developer Journey
• OKRs & Goals
• Timeline & Milestones
• DevRel Programs & Deliverables
• Reporting
• Team Operations
• Budget

DevRel Objectives

The over-arching objectives of Developer Relations is Awareness, Activation, Engagement, Retention, & Innovation. When writing your team's objectives you should consider what your team will do both now and over the next 2-5 years. Your objectives should essentially stay the same over the life of your team, but you may find yourself adjusting these over time as well.

Question to consider

What is the purpose of your developer program?

What do you want your developer program to achieve?

What value will it bring to your organization?

What value will it bring to the developers you want to serve?

What do you want from your developer program?

Example Objectives

• Build programs and strategies to grow the developer ecosystem
• Build and maintain deep understanding of the developer ecosystem in order to advocate for and communicate developer sentiment internally
• Educate and support developers to drive success, innovation, and retention
• Grow and evolve our platforms to drive increasing value for our developers

Developer Products

Within your strategy you should define the developer product offerings that your team serves and how they fit into the wider developer ecosystem. I recommend you work alongside your product & product marketing functions to define this area of your strategy.

You should ensure that you can confidently outline the product value proposition to developers as well as product market fit.

Questions to consider

What is the relevance of the product to the developer?

The benefits of the product to the developer?

How your product is differentiated for the developer over competitors?

Product-market fit describes a scenario in which a company’s target customers are buying, using, and telling others about the company’s product in numbers large enough to sustain that product’s growth and profitability.

Developer Audience

Work will be easier if you have your developer audiences defined. You'll be able to associate channels, deliverables, and programs to the right audiences and make decision-making easier.

Your marketing team, especially if they have a developer marketing focus, should already have these areas defined as it's imperative for successful marketing. However, if your marketing team does not have defined segmentations, personas, & positioning, you may have to dive in and take the lead. You want to ensure the entire company leverages and understands the developer audiences defined.

Segmentations

Segmentations help you identify which developers are a part of your target market. Segmenting your audiences allows you to hit your audience target more easily.

There is a really great blog post on this—You're Targeting Developers. So Is Everyone Else.

Personas

Personas are a way to personalize your targets and humanize them. Depending on your segments, you should define 2-4 personas.

Positioning

Once you have defined your developer audience, you can begin to bring together positioning that you will leverage when targeting developers.

Developer-friendly positioning should cover questions like these

What type of product is being offered?

What does it do?

How does it make a developer's life easier or better?

Why should a developer use it?

Why should a developer choose it over competitive offers?

Developer Journey

The developer journey is similar to a customer journey. The developer journey map is a visualization that identifies the ideal path and experience a developer should follow.

It's a tool that helps you to think holistically about the experience from the developers' perspective. - DevRel Book

Within your strategy you should define the current developer journey map (per product). As well as clearly share what your dream developer journey map could look like. It's a great way for folks to be able to visually understand the progress you're hoping to make in DevRel.

I look at the developer journey map as a guide to many key areas of DevRel. It's a great way to track the programs you own and contribute to, but it's also a way to identify data points between each stage and touch point and develop tracking around them.

OKRs & Goals

The folks over at Atlassian know a lot about OKRs—I strongly recommend reading this post.

There's a myth out there that DevRel is hard to track. Sure, there are activities that we participate in that are hard to track or hard to prove the ROI of (since developers need 4+ touch points before they engage). However, DevRel as a function is not hard to track when you define your strategy clearly, set the appropriate OKRs based on your objectives, and create thorough metric tracking.

The objectives of your OKRs should almost always match your DevRel objectives you defined in the beginning. You may find yourself shifting the language slightly to better speak to leaderships goals in that quarter, but they should conceptually align.

Your key results should align to an objective, and should consider your company & stakeholder objectives & OKRs too. Key results should be written with the SMART goals framework in mind. You should send bi-weekly or monthly reports to your stakeholders and leadership updating them of your progress towards your OKRs.

Don't set too many OKRs! You should have 2-4 objectives with 2-3 key results.

Example OKRs

• Deflect 75% of support tickets by providing scaled support opportunities in H2
• Convert 100% of support ticket topics to improvements across our one to many developer resources in H2
• 35% of developers launch successfully within 6 months of registration
• Impact at least 25% of product features based on feedback captured from developers in H2
• Improve activation—moving from evaluate to learn in the developer journey—by 25% by the end of the year

Timeline & Milestones

Timelines & milestones provides folks reading your strategy with a high-level view of your intentions and plans. I tend to plan on a quarterly basis, but the timeline below actually shows mid-quarter efforts as well.

The idea is that your milestones should align to your OKRs, and the timeline should align to the work you're committing to do to accomplish your OKRs in that timeframe.

DevRel Programs

Now it's time to dive into the work you're going to do to accomplish your objectives and nail those OKRs.

DevRel programs are where you drive impact for your developer audience and accomplish your OKRs. In this area of my strategy, I land on which programs we will launch or improve based on my objectives, and from there begin to bring together the work that we'll do.

In my strategy document I will outline the program, the objectives it accomplishes, and how it will contribute to my OKRs. I then link to a separate program plan that outlines further details around the program and project I'm planning as a part of my strategy. Leadership can get a high-level view from what I share in my strategy doc, but if they're looking for further insights, they can review my program plan.

When I'm presenting strategy to leadership I try not to commit to every bit of work the DevRel team will do. We can't speak to the ever-changing technology that we constantly have to keep up with. However, we can speak to what we plan to accomplish with some details of how.

Reporting

Let's bust the myth that DevRel is hard to track and report ROI. There are some activities that are harder to track than others, but your team impact and OKRs should be crystal clear.

Company Goals & Metrics

You should always be tracking how your work contributes to the company goals. Establish a way to capture metrics around the company goals and where DevRel made an impact.

For example, your company may have a goal to increase users. As you're reporting on your work, ensure you're capturing the data necessary to be able to point how your team is increasing users on the platform.

DevRel Goals & Metrics

This is where you track your DevRel OKRs and how your programs are contributing to those OKRs.

You should also be continually reporting on how you're doing the following:

• Drive developer awareness
• Improve developer activation
• Cultivate developer engagement
• Strengthen developer retention
• Inspire developer innovation

Activity Metrics

Activity metrics are where you track the success of your work & deliverables. Not only do they help you understand how you're contributing to your OKR's and the company's, you're also learning about how your work succeeded or didn't succeed. Better understanding which deliverables land successfully with your audiences is a key need in DevRel. You have to constantly be experimenting, learning, and trying again.

Your activity metrics may point you right towards OKR impact, while others may need to be analyzed based on the scenario. In the following example, you should be tracking the results of your deliverables (to better understand if those deliverables would work again) as well as the results of the event—leads captured (in-person & remotely).

DevRel Program: Events for Awareness
Campaign: Sponsor & Speak at ExampleConf
Campaign Goal: Capture 200+ leads at ExampleConf
Deliverables: Blog post announcing our presence at the event (lead captures), social media promotion of event (engagement & impressions), deliver presentation at event (est. heads in seats), setup & staff our sponsor booth (lead captures + convos)
CTA: Visit our booth (tracked by lead captures)
DevRel Metric: # of leads captured, leads that converted to users
Company Goal: Drive product demand
Company Metric: # of users converted

Community Metrics

You should establish metrics for your community that you routinely track against that continually speaks to the impact your community is driving. These should be included as a part of your DevRel reporting. Your community metrics should align to the goals and objectives of your community forum. Which OKR does your community contribute to?

• Number of community-answered forum questions
• Number of content written by community members
• Number of tickets deflected
• Number of active users
• Number of community ambassadors
• Traffic stats
• etc.

If you're trying to figure out what metrics to track and how to understand your impact, check out this Airtable view where I share example success metrics for DevRel programs.

In Summary

I love building strategy docs, slideshows, writing OKRs, and making sure it all tracks back to the objectives. However, it is a time consuming process. If you're looking for a time estimate, I would give yourself 4-8 weeks to work through discovery and getting to know the company & product deeply, and at least 4-6 weeks to draft, request feedback, improve, and present your strategy to stakeholders.

Looking to dive deeper into drafting DevRel strategy and learn even more? Join my upcoming mastermind group.

Grab the DevRel Book at 20% Off