Yes. You read the title right. An answer to the worst nightmare of industry professionals in developer-facing roles. This includes people in Developer Relations, community managers, Developer Program Managers and more!
It’s not just us saying it; it’s the people in these roles who have expressed how challenging it is to prove the value an onboarded developer brings, and they have done so in podcasts, panels and 1 to 1 discussions we had.
That’s why at SlashData, we developed the framework that calculates the added value every onboarded developer brings in real dollars. In our thought leadership report, we show you how to calculate this dollar value by introducing the concept of Developer Engagement Value. The total value that a developer is expected to bring over a period of time either by using a vendor’s technologies themselves (direct value) or by inducing/supporting others to do so (indirect value). It is a forward-looking metric that takes into account the variable nature of developer behaviour and introduces a framework to calculate developer value in real dollars.
You can access the full framework here. Or read on for more information.
Why do you need to know the value an onboarded developer brings?
Developers are more than mere product or service users. Developers are unarguably partners and co-creators who add value that extends well beyond the direct revenue stemming from technology usage.
Many Developer Relations (DevRel) and developer marketing practitioners struggle to prove just how valuable an onboarded developer is, and, consequently, to justify their budget investments in DevRel. Even if they do get their budgets approved, they are faced with the problem of how to optimally allocate this budget to the different activities.
But are DevRel budgets the only reason why you would need to estimate the value that a developer brings? How about when launching a new developer product? Won’t you need a way to predict how many developers this new product will attract and how much value these new developers will bring?
For decades, Customer Lifetime Value (CLV or LTV) has been used to predict the value a client will bring throughout their ‘lifetime’ (length of relationship) with a company. Model setup and estimation was fairly straightforward at the time when all we had to worry about was direct revenue and transactional data. But in the developer ecosystem and in the era of network effects, indirect revenue, influencers, open source, and developer communities of all shapes and sizes… how do you capture value?
This is what we are after with the Developer Engagement Value.
4 key questions to answer first
Estimating the value that a developer brings is a daunting task, given the indirect value contributions and network effects intrinsic to the developer ecosystem. Challenges, however, begin a lot earlier in the problem definition process than the indirect value estimation stage.
Considering these four key questions will help us to define the boundaries of the problem better:
Whose value should you estimate? As discussed earlier, it’s not just those using your products. We posed this question also to our community of DevRel practitioners, and we got back a broad spectrum of answers. See the full report for a selected set of their responses.
Can you observe the developer journey? Time is a continuum and observing a developer’s journey uninterrupted in this continuum is one of the most challenging endeavours. Telemetry alone will not get you there.
How should you define ‘lifetime’? What is the time horizon for your predictions? How far into the future should you try to see and estimate value for?
Do you really need a dollar value estimate per onboarded developer? It depends on what your end goal is. For example, if what you’re trying to achieve is optimal prioritisation of DevRel initiatives, then a relative, rather than an absolute, value will suffice. If, however, you need a number for your ROI and budget calculations, then you do need a dollar value estimated.
The DEV framework
As we mentioned earlier, the concept of Customer Engagement Value (CEV) has been around for more than a decade. We built on the model proposed by Kumar et al. (2010), adjusting and extending it to capture all the forms of engagement that are typical to developers.
In a nutshell:
Our framework proposes a method of estimating the total value that a developer is expected to bring over a period of time, either by using your technologies themselves (direct value) or by inducing/supporting others to do so (indirect value). We call this the Developer Engagement Value (DEV), and it is a forward-looking metric that takes into account the variable nature of developer behaviour.
To arrive at the Developer Engagement Value, SlashData identifies seven key areas from where developer value stems – seven value categories:
Developer Direct Value (DDV)
Supporter and Skill-builder Value (SSB)
Peer Influencer Value (PIV)
Decision-maker Influencer Value (DmIV)
Developer Referral Value (DRV)
Developer Feedback Value (DFV)
Developer Contributor Value (DCV)
Then, factoring in data from its global developer surveys, SlashData can map all the evolution paths that the developer segments of interest can theoretically take in the course of a selected forecasting period.
The next step is to build models to find the link between developer value and specific initiatives (DevRel, developer marketing, pricing strategy, or product feature design) and finally provide scenarios which show you how each initiative is expected to change the value of each segment. The framework is fully flexible as it can be applied to a single product, to a group of products or across your whole business. It is also sensitive enough to pick up nuances between similar initiatives and, as such, can provide you with granular insight on specific activities.
What can the Developer Engagement Value framework do for you? How are you planning to use it? Dive in the full version and here’s to a brighter future.