Measuring DevRel Success - Thinking Outside the Funnel

I've been working in Developer Relations now going on 5 years and I've seen a lot of attempts to measure the activities of DevRel teams. There is often a lot of ambiguity about how best to measure the work that DevRel does. Do you utilize the AAARRRP model from Phil Leggetter, the Orbit Model from the Orbit team, the traditional sales funnel or something else?

Regardless of whether your DevRel team has adopted either the AAARRRP or the Orbit model to measure itself internally, chances are other elements in the business, from decision makers to other verticals like sales and marketing, see your function as part of the funnel.

This is deeply problematic.

Before I explain why let me just take a moment to explain what the sales funnel is.

What is the sales funnel?

The sales funnel is essentially a visualization to describe the processes a potential customer goes through until they become a confirmed buyer. The "top of the funnel" is the widest opening and contains all the people that become aware of the product. It then proceeds through various stages in "the middle of the funnel" like interest, evaluation and desire, until it reaches the very "bottom of the funnel," which is making the purchase decision.

It is quite tempting to put DevRel activities at the top of the funnel or near it. After all, what are all the community activities, presentations at conferences, tutorials produced and more if not to generate awareness, interest, evaluation and desire?

This is not accurate though, and let's describe why. We'll begin by offering a succinct encapsulation of the difference between two commonly conflated disciplines - developer marketing and developer relations.

Developer marketing and developer relations: what's the difference?

Developer marketing is crafting engaging advertising content with the explicit aim of attracting new customers from a developer persona.

As Pratim shares in this tweet thread, the very terms elucidate the distinction. Marketing is transactional whereas relations is a long-term investment of mutuality.

A developer marketing campaign will always have a call to action (CTA) objective directly tied to an increase in purchases, sign-ups, data ingest or whatever the financial metric for the business is. An ad campaign in targeted developer podcasts will be measured against things like new customer acquisition goals and the journey of the customer can be very clearly tied from hearing the campaign on the podcast to making a new purchase.

Developer relations exist in cooperation with developer marketing, but it is not developer marketing.

Developer advocates seek to build engagement and catalyze community growth. The engagement itself is a goal. The catalyzing of community is a goal. They are not strategies to achieve a goal, they are the goal themselves.

A CTA for developer marketing might be "create an account today!" whereas a CTA for developer relations might be "explore our open source issues you can contribute to today!". The difference is clear.

Why though would a business invest considerable resources in an organization that is measured not directly by new customers and increase in revenue? What's the value for the company?

Why businesses (should) create developer relations teams

Jeffrey Bussgang and Jono Bacon in an article in Harvard Business Review back in 2020 explained the value proposition for businesses to invest in community building:

While communities generate tangible value for businesses — such as content, events, online advocacy and marketing, technology production, customer support, and education — it is the intangible value that members derive from the experience that makes these environments truly “sticky.” Human beings are fundamentally social animals. Behavioral economics and psychological research have taught us that we fundamentally crave a sense of connectedness, belonging, mission, and meaning, particularly when performing our work. Theresa Amabile’s The Progress Principle and Daniel Pink’s Drive both demonstrated that making progress towards a shared mission is the most motivating force a professional can feel. Communities deliver these benefits, creating a sense of shared accountability and a set of values while preserving individual autonomy.

Bacon and Bussgang continue that this tapping into the innate human desire for shared accountability, connectedness, and belonging delivers for companies through the following:

• Enthusiastic members help acquire new members, resulting in lower customer acquisition costs and a tight viral loop.
• Members are loath to abandon the community, resulting in increased retention and therefore improved lifetime value.
• Members support one another, resulting in high gross margins due to a lower cost of service.

What is true for human beings in general, is certainly true for the subset of humans that work as software developers.

This is why companies that focus on developers should create developer relations teams. It is to build a "sticky" community. That is to say a lasting, durable, resilient and enduring community.

Developer relations teams do that in various ways and the specifications of the role will vary from team to team. Nonetheless, it all involves some combination of 1-to-1 conversations, 1-to-many presentations, content creation, improving the developer experience in the company with SDKs and support libraries, and building a tight feedback loop between the users and the teams building the thing itself.

How do you measure this work then if it is so intrinsically important to the business but not tied to the sales funnel like developer marketing is?

Measuring developer relations

The work of developer relations must be measured against its purpose and goals. Indeed, every organization in a business must be measured against its own goals. The problem becomes when a company decides to impose the same measure of success on every aspect of the business. This is complex sometimes with DevRel because it often exists inside a well-established organization, like product or marketing, and it is quite simple to apply the measure of success of the parent organization to the DevRel initiative, try to avoid doing that if you want your DevRel team to be as "sticky" as the community you hope it will foster.

What does it mean to measure developer relations against its purpose and goals? It means going back to the first principles of DevRel in your business and drawing indicators of success from there. What are the biggest needs for the DevRel team in your business?

• Improving the developer experience with the product?
• Growing the participation in the open source projects?
• Increasing knowledge of the company in specific developer communities?
• Building a library of useful content to help unblock developers building with the product?
• Something else? Some combination of the above?

Determine what your highest priorities are within the domain of building community and then draw specific, measurable, realistic and time-bound goals starting from that place.

No matter what you do, do not directly tie the success of your DevRel team to money spent or increased data ingest or some other similar metric. Those are important goals, without a doubt, but the work of developer relations does not neatly shape itself in a way that allows for easy and accurate tracking of activity X to $ spent. Trying to do so will only frustrate the professionals working on the team, causing them to shift the work from what they should be doing to instead working to make sure they "appear successful" and eventually leading to burnout and high rates of employee volatility.

Sharing the good news

Precisely because developer community building is a long-term investment that does not fall within the parameters of the sales funnel it becomes too easy all too often to forget its actual business value. It is incumbent upon the leadership of the DevRel team to consistently and constantly manage up by making explicit and obvious to business leadership its value and how it is successful.

DevRel professionals cannot assume that leadership and teams outside of itself understand intuitively how it is contributing to the overall success of the business. Those lines must be drawn for everyone else, and the leadership of the DevRel team has to be socializing that all the time inside the business. That means, in many instances, creating lots of colorful slides with graphs, charts and text in very large font sizes. The more the DevRel team and its leadership do that, the better understood they will be internally, and the more they will be able to thrive.

Companies whose primary audience is developers will usually seek to build a developer relations team early on because they have heard they need one to be successful. Yet, they often go into the endeavor without a clear understanding of what that team is meant to do besides "going to events" and "speaking to developers". This sort of ambiguity can eventually lead to frustration as the costs of the team continue to rise, and it becomes difficult to measure its outcomes for the business. Communicating from the beginning the objectives of the team, creating clearly defined measurements based on those objectives, and constantly sharing both those objectives and the results of those measurements with the business at large, will help significantly create clarity and shared alignment on the DevRel function in the business.