My past life with AI
In my past life, aka when I worked in the financial sector more than a decade ago, we built something similar to a recommendation system, when that was not a popular term yet, using neural networks, when that was more of a swear word rather than a cool AI thing. I was that weird geek that everyone tilted their heads at trying to understand what the heck I was talking about. But with the support of inspiring leadership, my team and I persevered and built a smart analytical CRM system, based on predicted customer lifetime values and Next Best Action recommendations per customer segment. Targeted campaigns based on this approach proved far more efficient than above-the-line marketing - in some cases 70% more efficient.
Shortly after that, when I moved to the tech sector, my colleagues continued to tilt their heads there too. The new job at hand was to support tech leaders to increase their market reach and revenue by explaining and predicting behaviours in the developer ecosystem. I was excitedly trying to explain the merits of segmentation - or ‘personas’ - and developer lifetime value estimations only to get very puzzled looks and a “huh?” as a response. That was back in 2012. Thankfully things have changed, and I am proud to have contributed to this change.
When DevRel was born
As DevRel became popular, building developer personas did too. The first segmentation report I authored back in 2013 was very well received - it painted the profile of mobile developer personas, and provided actionable insights on how to reach them.
Keeping ears to the ground, it became clear to me that developer-facing teams needed help building their own personas for their total addressable market (TAM) rather than using mine. Driven not just by the business opportunity but also by a desire to contribute to the community, I suggested a methodology to segment developers into personas in ‘how-to’ reports and webinars. Market response was fabulous, leading to lots of successful projects where we supported DevRel and developer product teams build personas for their audience.
At that stage I pointed again to the benefits of estimating lifetime values for those segments. However market maturity was still building and there seemed to be no immediate customer need for that. And so I bided my time.
Finally, the time was ripe
One day DevRel team leaders came knocking, asking if we had any way of estimating the value that a developer brings when onboarded to their community. Something that would help them articulate the value of their teams and their budgets. Aha! Had the time come?
Then the economic environment tightened in the tech industry, and a bloodbath of budget cuts ensued. Developer marketing and DevRel budgets were among the first to suffer. With all spending scrutinised, being able to prove the effect of your efforts on the organisation’s bottomline was certainly crucial. Yes. The time was ripe.
Excuse me, does this make sense to you?
I had to check with DevRel and developer product leads that I was on the right track, that my idea made sense. Just in case I could avoid that tilted-head look this time.
I am very thankful to the DevRelX community members who answered our poll on the topic, and especially to those who took the time to speak with me and share their thoughts. Yes, a dollar value estimate per developer onboarded was definitely something they would use. Some of them had even attempted calculating it themselves, but failed as their transactional data could not yield a believable number. I was definitely onto something, and survey data held the answer.
The demon of indirect value
But why were folks failing to estimate developer value? After all, customer lifetime value has been around for a few decades already, and several approaches to its calculation have been suggested and tested across various business settings.
The developer ecosystem is unique in nature, with intrinsic characteristics that set it apart from the consumer and banking world. For one, technologies and therefore developer choices change rapidly. As a vendor’s clients, developers may come and go multiple times, using, abandoning and then re-adopting technologies in the context of different projects. ‘Lifetime’ is next to meaningless in this space. Solutions have been suggested to this problem of consumer behaviour, but they needed to be further engineered to deal with the high frequency with which developers change tooling, and the low observability of their behaviour across stacks of technologies.
The really scary “you-will-not-pass” demon, however, lay elsewhere. Indirect value. This demon resides in the retail world as well (word of mouth, referrals, ratings, reviews, etc.), but the developer ecosystem is ‘one level up’ in three key ways:
Developers are co-creators of the technology itself. They are partners, not just clients, contributing code or building add-ons to platforms and thus enhancing and evolving vendor technologies.
They are also skill-builders and advocates, supporting their peers to learn how to use vendor technologies through Q&A sites and communities of all shapes and sizes.
Last but not least (and one of the key reasons why DevRel boomed) developers are tooling decision makers within their organisations, from making recommendations and influencing decision makers all the way to approving the total tooling budget.
For example, what if a developer is not using a technology anymore or they only use a free tool, but they do answer questions about tools and platforms in developer forums, provide training videos, or contribute code? Don’t they add value?
Of course they do. In fact, testing my model with the SlashData survey data, we found that in most cases this kind of indirect value is far greater than the transactional direct value.
That was the gist of the problem. How do you measure all these indirect contributions when you can not directly observe them in your data? That’s where those who tried to estimate developer value got stuck. And that’s where my idea came in.
The Developer Engagement Value framework
The Developer Engagement Value (DEV) framework was born, and it identifies seven different types of value - direct plus six different kinds of indirect. These can all be captured through a purpose-built survey and they can be used to arrive at a total dollar value estimate per developer persona.
It’s not an off-the-shelf plug-and-play solution, but rather a tailored research service that fits the specific needs of a developer-facing business that wishes to estimate the value of its audience. It is a customisable framework. It is also applicable well beyond the realms of DevRel. It can be used in the context of product feature design, product marketing, cross-selling campaigns, retention efforts and pricing strategies. In the white paper I provided an example of a use case, based on real survey data, to demonstrate the merits of the approach. That was just one generic use case, though. There are far more - and I will discuss these in another post.
A sophisticated machine with an easy-to-use product
I gave DEV the attention a game-changing framework deserves, and - more practically - strived to ensure it captures value accurately in the complex multi-dimensional space of software development. Everyone we speak to is immediately sold to the idea, although the process of implementing the framework is perceived by some as daunting (ok, I didn’t totally avoid the tilted-head look this time either!). However, the framework’s end users don’t need to worry about complexity at all. All they get is an easy-to-use tool that allows working on different scenarios and seeing how developer value changes in each case. Based on these scenarios they can then select the right levers to pull to maximise the ROI of their developer-facing activities. We take care of the rest.
You can dive into the intimate depths of the DEV framework here. If you want a friendly chat on this area or its application outside the DevRel environment please feel free to get in touch.
Kommentare