Go-to-Market teams are one of the highest consumers of data. But developer-focused GTM teams particularly are faced with a problem of plenty. Every online interaction, from code installs to community discussions, holds potential clues. It’s easy to fall into the trap of assuming each review on GitHub, each product signup, website visitor, could signify intent. Uncovering revenue opportunities from such developer activities —identifying accounts that will actually convert—feels akin to searching for a needle in a haystack.

What is the ‘needle in a haystack’ problem?

In the era of inbound marketing, a bottom’s up GTM was linear. The roots of inbound marketing were found in permission marketing and 1st party content. The main idea was businesses created and disturbed a lot of useful content, brought more users to the website and then nudged them to fill up forms. The leads were scored based on the interaction on specific webpages and the content they interacted with. These scoring mechanisms were done via first party IP reveal tools. More visitors meant more intent.

Marketers soon realised that content engagement indicative of intent wasn't confined to just 1st party; but more often 3rd party too. People were actively consuming content relevant to their interests outside the marketer's owned websites - 3rd party websites, reports, blogs, Google publications, review sites (G2, Capterra). So marketers expanded their tools to capture intent from 3rd party intent to score lead maturity.
‍

‍
Rise of code-based intent

But for developer-focused GTM leaders targeting developers, content is just one dimension to the intent data. They have a second dimension of intent, and that is - code based intent.

Today developers hold a significant influence on a dev tool purchase decision. Essentially because dev tool purchase is a nuanced process. The CTOs delegate the task of evaluating the tool to the developers first primarily because they are the ones who will build on it. But developers are an independent group of builders. They like to evaluate the product themselves without any interventions from sales and marketing teams. This necessitated developer focused companies to come up with their sandboxes, free trial versions, tech documentation for developers to try them out. Many open sourced their codes, other’s released specific open source projects to attract this persona. Thus Developer focused companies became the OGs of PLG much before PLG became a ‘thing’. They became the frontrunners of content marketing creating detailed developer documents. They set the stage for community growth, building massive developer cohorts. In fact, they have led every big marketing wave.

Having said that, sales teams selling dev tools still find it tough to learn which doors to knock on (where is the sales opportunity). The underlying problem to this was most of the code based intent was anonymous. Developers hate being tracked and hence most assets for developer evaluation were outside a signup form.

Why context matters while selling to developers?

This gave rise to the need of a third dimension of intent - which is the context. Developers within your ICP organisation, interacting with your code and content might be doing it for exploration (will be an opportunity some day, but is in an experimentation phase today) or evaluation (it is a problem that needs to be solved now). The strategies for both stages are different. For accounts in ‘exploration’, the prospect account does not have a sales opportunity yet, but you still need to nurture and educate the developers. For accounts in ‘evaluation’, you want your sales teams to knock doors and work with buyers.

And hence developer focused GTM leaders saw a different tooling that emerged for solving this challenge. We launched Reo.Dev specifically for this and got a lot of customer love (Within 6 months of our MVP launch, 20+ leading developer focused companies are using Reo.Dev as their go-to revenue intelligence platform). We built the tool to understand code level intent across OSS, docs, package managers and more sources, and triangulate all data to show your accounts pipeline.

Hence, I would like to come back to my original statement that DevGTM leaders have a problem of plenty and their current intent tooling is not working for them:

• Marketing teams are setting up multiple tooling to get intent, be it for their website data, product signups, third party topics, community data, open source activities.
• Yet their sales teams are finding it tougher to know which doors they should knock to close deals.

Need for DevGTM leaders to rethink ‘intent’

Conventional intent wisdom does not work because there are in general ‘too many’ intent signals. Here is how developer focussed GTM teams can find the needle in the haystack.

‍

1) Triangulate account based activities across Content and Code

Understanding how developers interact with your documentation can provide valuable insights into their intent. For instance, consider this scenario: a developer who frequently visits your installation documentation may be in advance stage of evaluation compared to someone who is just reading a getting started guide. Similarly, the actions developers take on your open-source assets can indicate their level of intent—someone who opens an issue on GitHub demonstrates more intent than someone who simply stars a repository. Reo.Dev analyzes millions of these interactions, it intelligently identifies and triangulates sales opportunities.

2) Decoding maturity of the accounts

By analyzing patterns such as frequency and type of developer activity, number of active developers, and the seniority of developers within an account, it becomes easier to discern which stage of the journey the account is in. For instance, during the Discovery phase, account activity might consist of low-intent actions like starring a GitHub repository, minimal time spent on documentation, and possibly only one or two active developers. Conversely, accounts in the advanced stage of the journey may exhibit multiple active developers, including senior personnel, engaging in high-frequency and high-intent activities such as downloading package managers, copying CLI command, etc. This approach allows for the segregation of accounts based on their level of product exploration and evaluation seriousness.
‍

3) Tailored playbooks for different accounts

• Exploring accounts: For such accounts, the buyer is still minimally involved. The champion developer has recently discovered the product and has begun experimenting with it. At this stage, the DevRel and Developer Marketing teams should be activated. Their responsibility lies in providing developer education, fostering a positive user experience, and delivering top-notch support. As more developers engage in the exploration stage, with a rise in developer activities, the Demand Gen and SDR teams can then step in to execute campaigns and nurture potential revenue opportunities.
• Evaluation accounts: In these accounts, developers have thoroughly engaged in the evaluation process, possibly progressing to building POCs or deploying the product on local servers. By this stage, it's highly likely that potential buyers are already familiar with the product. This is an opportune moment for Account Executives to monitor these accounts closely, observing developer activity levels. They can identify where to introduce sales engineering support to bolster the developers' efforts, enabling them to present a compelling economic case to the purchasers. Additionally, leveraging developer relations can facilitate warm introductions to the technical buyers, enhancing the sales strategy.