In our book, Developer Relations: How to Build and Grow a Successful Developer Program, we dedicate a number of chapters to examining the achilles heel of Developer Relations - how to define and measure the value created by Developer Relations.
The are many contributing factors to why demonstrating value has been a long standing issue for Developers Relations. The diverse surface area of activities that are rolled up under the term "Developer Relations", varying organizational contexts, and a disconnect from sales and revenue generation are just a few examples.
As a DevRel leader, you should want to demonstrate that an interaction with your Developer Program leads to the higher likelihood of a Developer adopting your product, which therefore directly contributes to your company revenue.
However, in realty there can be significant elapsed time between a developer first being exposed to your technology and the point they adopt it. They may even be working for a different company by the time they find a suitable use case. So how do you connect those dots?
To frame this business challenge, we summarized and contrasted the characteristics of Business to Developer (B2D) Business models with traditional Business to Consumer (B2C) and Business to Business (B2B) business models in Chapter 8 of the book:
B2D differs from more traditional business models, primarily because you are not selling to the ultimate end user of the product. You are selling to a Developer/Company that will take your product to create or enhance something that they sell to their own customer.
The second challenge, is just because a Developer starts to use your product it does not guarantee that the value for your company will be realized at that point, or indeed ever.
You may have done a great job of inspiring them, enabling them, and walking them through how to integrate it into their stack, but if their product is not successful in its own right, it is unlikely they will generate enough transaction volume or licenses to deliver meaningful revenue back to you. Your success very much rides on their success.
Take, for example, the pay-per-transaction, self service model popular with many B2D companies, especially API providers. Your own sustainable business can’t be built on the back of a string of “flash-in-the-pan” use cases. Nor can you afford to introduce friction into your developer journey which will lead to you losing Developers that may have been interested in your technology.
An important distinction when you operate a self service model vs. a traditional sales model is there is no qualification of a lead before they become a customer.
Due to this, it is likely you will not be able to accurately predict the volume that an individual account will create, as you have no idea of who they are, and what their use case will be. We advocate adopting a Customer Success mindset for your Developer accounts, to build that insight and find new revenue streams with your customers. That is why we include Developer Success in our Developer Relations Framework.
Due to this complexity, we love to see any effort connecting the work of Developer Relations to the bottom line of the company. This post is to recognize one such endeavor from SlashData.
Recently Slashdata published an article called How to calculate the dollar value and ROI of an onboarded developer. Understanding, and putting a value to this is vital, as onboarding developers is one of the bedrock activities of a Developer Relations program.
Their 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). They call this the Developer Engagement Value (DEV), and it is a forward-looking metric that takes into account the variable nature of developer behavior.
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)
SlashData has developed a number of formulas for estimating probability for all seven of these categories. They combine all seven probabilities in what they call their Developer Engagement Value Index (DEVI). DEVI can be positive, indicating a developer adds value, or negative, in the case that an influencing developer with a negative view of a product can dissuade others from using it.
Next, you:
Select your customer segments to analyze
Set the time horizon for your value predictions (e.g. three years into the future)
How often you will take ‘snapshots’ in that period (e.g. every six months)
There is a lot of information to take in to fully understand this model, and there is no need for us to repeat it verbatim in this blog post. Our aim is simply to sign post an interesting initiative.
We spoke to Christina Voskoglou, VP of Research & Product Innovation at Slashdata who told us:
"We built the DEV methodology and gave it the attention to detail a game-changing framework deserves, with input from key industry leaders. Many tried in the past but failed because the problem lies in a) indirect value, which takes several forms, and b) in the many ways in which a developer can engage with a business and evolve in the industry. Covering both increases the level of complexity.
However, you don’t need to worry about complexity at all. The machine you are reading this on is an immensely complicated combination of 1s and 0s. But you’re still reading this. In a similar way, SlashData can take care of the technical details. Through a tailored research solution, we can confidently offer developer value estimations that fit the specific business needs of each of our clients. What you get is an easy-to use tool that allows working on different scenarios and seeing how developer value changes in each case. We take care of the rest."
You can make your own judgment by downloading the report here.
We will watch with interest to see if the model gains traction in the Developer Relations Community. Christina points to the need to hire Slashdata to implement this in your organisation, which is unsurprising considering the model uses proprietary SlashData research data & methodologies.
We hope the practice of DevRel will continue to work the problem of demonstrating value, and we will continue to be supportive of any new thinking that tries to push our practice forward.