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.

Learn about Reo.Dev

First, the shift from outbound to inbound marketing marked a pivotal change in how we approach our marketing strategies. This transition was largely spearheaded by the likes of HubSpot, who championed the cause of attracting customers through valuable content rather than seeking them out. This change underscored the importance of understanding and adapting to buyer behavior.

The marketing world witnessed a second pivot from traditional inbound tactics to intent-based strategies. This shift, propelled into the mainstream by 6Sense, was underpinned by a significant change in buyer content consumption habits. Marketers began to focus not just on attracting buyers, but on understanding and responding to their intentions at every stage of the buying journey.

Today, we stand on the cusp of another pivotal change: the rise of the developer as the key decision-maker in technology purchasing. This shift is driven by several key trends:

1. More companies behaving like dev-focused companies: The digital transformation and the rise of e-commerce are reshaping today’s multinationals into tech-centric entities. Organizations across the spectrum, from financial giants like JP Morgan to retail behemoths such as Walmart, and innovative tech firms like Swiggy, are increasingly developing tech products. They're engaging with hundreds, if not thousands, of developers to create the technological backbone of the modern internet. This universal shift towards becoming tech-oriented underscores the critical role of developers.
   

2. More buyers behaving like developers: The developer-led purchase journeys of devtools are expanding to tools for DevOps engineers, security teams, data analysts, and data scientists. These users prioritize hands-on experience, personal research, and community feedback over traditional sales pitches and marketing. This new buyer persona demands a fresh approach, marking a significant departure from established sales and marketing techniques.
   

3. More companies empowering tech users to influence purchase: With technologies emerging faster than ever, more CTOs are empowering their teams to influence purchasing decisions. Large enterprises today often delegate a significant portion of tech decision-making to developers, as pointed out in the BCG report on the influence of developers in enterprise tech sales.

Why developer-focused buying journeys are fundamentally different

I wrote a detailed blog on the Modern GTM Process for Developer Led Sales, highlighting how B2D GTM processes needs to align with and augment the unique buying behavior of developers. Some key takeaways included:

1) Acknowledging different personas: The Modern DevTool GTM acknowledges two very different personas involved in the purchase process: a Developer and a Buyer.

2) Hybrid motion: The purchase motion is neither strictly bottom-up nor top-down, but a hybrid of both.

3) Anonymous buying journeys: Buying intent does not lie in topics but in the use of tooling. Selling to developers requires a focus on their activities on developer-specific platforms, such as GitHub, technical documentation, and package managers.

4) Leads vs. purchase intent: A lead does not necessarily indicate an immediate purchase interest. Timing is might importance when selling to technical audience. A need to solve a problem matures into a sales opportunity at the right time.

Today, we're observing a growing interest among leaders in the DevTool GTM community to enhance the knowledge base of dev marketers. Despite our efforts to compile the best resources on dev marketing, it's evident that the available information barely scratches the surface. The evolving landscape of DevTool GTM calls for a more sophisticated approach from dev marketers, emphasizing the need for deeper insights and strategies.

By recognizing the importance of developers in the purchasing process and tailoring strategies to meet their unique needs and preferences, dev marketers can effectively engage with this critical audience and drive meaningful results. This requires a willingness to learn, adapt, and innovate in response to the changing dynamics of the tech purchasing ecosystem.


As a Marketing or a Sales Leader of a Developer Focussed Business, if you feel you need a tool to adopt the Modern GTM motion in your organization; Reo.Dev might be the right tool for you. Reach out to us for a chat.

Know about Reo.Dev

I wanted to take a few minutes to talk about why we're building at Reo.Dev and how we are defining the revenue intelligence category for developer-focussed companies.

Why are we building Reo.Dev?

Prior to Reo.Dev, I worked at a Developer focussed company (an API company) heading the business function, responsible for generating revenue. I observed potential developers from our potential customers engaging with our resources—asking questions in our Discord community, installing our GitHub SDK, using our sandbox, reading our technical docs, and experimenting with our APIs. The C-level executives we demoed for often tasked one or two developers on their team with assessing our products, making these developers as vital to us as the executives themselves.

This brought me to the realisation that sales processes at modern tech companies are evolving. Traditionally, business buyers were the primary decision-makers. However, an increasingly influential figure has emerged: the developer or technical user. We feel this shift necessitates a fundamental change in sales tools and strategies for a new go-to-market (GTM) approach, which we are actively developing.

This paradigm shift in purchasing behavior presents unique challenges and opportunities. Developers place greater trust in their own research and evaluations over interactions with sales teams, and hence want to talk less to them. However, their research and evaluations leave more fingerprints across the web than will ever be captured in a sales call. We wanted to build an engine that can look at millions of these fingerprints and intelligently decode such sales opportunities from them.

Reflecting on the past six months

We picked Commercial Open Source companies as our wedge market as we saw this was a very fast growing vertical with newer challenges that could be solved with a product like ours. We started with validating our idea with revenue leaders in some of the top open source Devtool companies across the globe, by deeply listening to them and built the product which today services customers across US, Canada, UK, Germany, Israel and more countries.

We built a product which is unique in many ways. Today the product tracks 1.5 million+ developer intent signals every month and discovers 45,000 accounts with sales opportunities. Few things stand out for Reo.Dev from other revenue intelligence tools:

1. Competitive Intel: Whenever developers have a tooling problem, the first thing they do is look for open source solutions. Hence most of our customers find intent signals in developer activities across open source projects they often compete or complement. We help them with identifying accounts that are actively exploring competing open-source options, revealing previously unseen opportunities. We are the only tool in the market today that does this!

2. Intel from Developer Docs: Developers evaluating a product go through technical docs. Hence, a lot of intent lies in the kind of documents being read by developers. Reo.Dev tracks the documentation pages visited and content consumption patterns helping our customers understand the intent of the prospect and evaluation stage (e.g. are they spending more time on Quickstart, or Guides or on API reference).

3. Package Manager Installations: Developers who are high intent usually install package managers or execute docker commands and code examples. Reo.Dev (and again we are the only tool in the market doing this!) identifies and tracks code executions with a single line of our Javascript that can be done by GTM teams themselves.

4. Cloud Product Usage: For developer-focused companies, product usage data can provide vital insights into the buying intent of the users. The unique challenge for these companies is that product usage data can sometimes be anonymous, or hard to combine with all other intent signals. Reo.Dev tracks essential product usage metrics—active users, usage time, engagement levels—to enhance sales and marketing's account-based outreach strategies.

5. Developer Funnels: Upon integrating data sources, we clearly started seeing trends and patterns that could help our customers learn which account is ready to buy from them right now. We built algorithms to identify the evaluation stages of developers within an organization. So we could identify whether the developers are at a discovery stage for a tool, in evaluation, building POCs or deploying code.

Top developer tool companies trust us

We’ve had phenomenal support from our customers who’ve trusted us and backed our vision from the early days. We onboarded leading DevTool companies, such as Lightbend, the creators of AKKA, backed by prominent investors like Dell Technologies Capital and Intel Capital.

We serve Unleash, the largest open-source feature flag platform; Ververica, the minds behind Apache Flink and now part of Alibaba Group; Outerbounds, which brought Metaflow to life at Netflix; and Aporia, a frontrunner in the ML observability space, among many others.

The patience, honesty, and valuable feedback from our customers have been instrumental in our growth. Thank you to each one of our customers. You are as much a part of Reo.Dev's journey as every member of our team.

We’re just getting started

Our mission remains simple. Help GTM teams accelerate sales using AI that identifies developer intent from vast data sources. We are proud of what we’ve built so far but we feel we’ve barely scratched the surface here. Here's what you can expect us to double down this year:

1. More value: Being an Intent tool places us right at the start of the value chain, which is a fantastic spot to be in. Why? Because it allows us to deliver unparalleled value right from the get-go. We're talking about giving you access to the most valuable accounts, direct contact details of active developers, and deep insights into the context and maturity of their activities. But here's where it gets even better: this position opens up incredible opportunities for us to enhance downstream value. This means we can significantly boost the efficiency of your outreach efforts, refine the messaging and content you send out, and help you create collaterals that are spot-on in terms of context.

2. More markets: We’re taking our learning from working with Open Source companies and now planning to enter other sectors such as Developer SaaS, Dev API and other Dev Infra companies which have the same buyers and hence similar challenges.

3. More Intel: Over the last six months, we've delved deep into our customers' data sources, uncovering patterns to understand developer activities. Our priorities for the next few quarters will be to enhance how our tool makes suggestions that guide users in interpreting developer behaviours for more effective sales outreach, and integrates more automated workflows.

I want to conclude with a note of thanks. A huge shoutout to our investors, customers, team members, and everyone who backed us since day one. Time to get back to the building board!

Explore Reo.Dev

Converting cold developer prospects to warm leads

There's a silver lining. Developers tend to leave clues or "breadcrumbs" through their interactions with your product, whether it be through opening a GitHub issue, downloading a package manager, or perusing technical documentation. These actions suggest they're already to an extent acquainted with what you offer, transforming them from the so-called cold prospects into warmer leads.

As a Sales Development Representative (SDR), your strategy should then involve deciphering these patterns of product interaction and understanding where developers stand in their purchasing journey. This way you can tailor contextual messaging to address the specific challenges they face, thereby positioning your solution as the answer to their needs.

Understanding intent while messaging to technical audience

The first step to crafting contextual messaging to developers is recognizing their intent while they engage with your product assets. Every activity done by the developer will reveal unique intent. Understanding this will enable you to provide relevant solutions, alternatives, or enhancements to their current tools and workflows. Revenue intelligence tools like Reo.Dev are built specifically to capture millions of the breadcrumbs that developers leave and intelligently decode such intent and thus sales opportunities from them.

Cold messaging templates based on developer activity

As highlighted earlier, each developer activity unveils a distinct intent, crucial for tailoring your messaging. We've compiled a list of common developer activities, deciphered the intent behind each, and provided examples of targeted outreach messages accordingly.

Segment 1: Developers exploring competitor technology

If a developer is toggling between your product and a competitor’s, it’s a signal they are weighing options. Here, emphasizing the unique benefits and differentiators of your product becomes crucial. Share case studies or testimonials that showcase your product's superiority in areas they care about.

Sample outreach message:
—---------------------------------------------------------------------------------------------------
Hi <__________>,

If you are looking for a Kubernetes security solution, do check out <Our Product>

Here is how <Our product> compares with <Competitor product> and <Other popular products> in the category. Where <Our product> really shines is <XYZ>

If you have any questions do let us know. We can get K8 Security Experts on the call to help you out!
—---------------------------------------------------------------------------------------------------

Segment 2: Developers exploring complementary technology

This segment of developers is actively using tools that align with or enhance the functionality of your product. The outreach should emphasize your product's ability to seamlessly integrate with the developer's existing tech stack, enhancing efficiency and functionality.

Sample outreach message:
-------------------------------------------------------------------------------------------------------------
Hi <__________>,

Kubernetes is very powerful but can be quite challenging to setup.

<Our product> can help you get started with Kubernetes within minutes and you evaluate whether Kubernetes is the right solution for you without wasting a lot of time on deployment.

If you would like to know more, happy to share some material or get a Kubernetes expert on a call.
—---------------------------------------------------------------------------------------------------

Segment 3: Developers active on multiple platforms

Let’s take an example, developers visiting your GitHub repositories and then reading your API documentation pages. This behaviour suggests a keen interest in understanding how your product works. A targeted message to the buyer should emphasize the pain points that your product solves, highlight the value proposition of your offerings, offer incentives, and include a compelling hook to initiate a conversation.

Sample outreach message:
—----------------------------------------------------------------------------------------------------------

Hi <__________>,

Curious if you are facing <problem that your product solves>

<pointed value proposition>

<Why they should try your premium offering> Or, <Hook to get on a call>
—----------------------------------------------------------------------------------------------------------

Segment 4: Developers building POC

Developers actively engage with your product, such as executing commands in the Command Line Interface (CLI), initiating a PIP install, or thoroughly perusing your documentation, it's a clear indication they're moving beyond mere exploration to actual experimentation. The objective here is to understand their needs deeply and identify what additional value your cloud or enterprise product can offer over the community/open source version. This understanding can then be leveraged to create a compelling reason for the developers to engage in a more in-depth conversation about the advantages of upgrading to a more sophisticated solution.

Sample outreach message:
—---------------------------------------------------------------------------------------------------
Hi <__________>,

Our [cloud/enterprise product] not only offers [list of premium features] but also provides [specific advantages over the community/open source version].

I’d love to discuss how these can align with your current experiments and elevate your work to the next level.

I'm here to answer any questions and can also arrange a tailored demo with our Sales Engineer.
—------------------------------------------------------------------------------------------------------

Segment 5: Developers asking for help

Imagine a developer who frequently opened issues or commented on GitHub or posed queries on community channels about your product features. This behaviour suggests a keen interest in understanding how your product works. Tailor your message to offer deeper insights or extended trial periods, demonstrating that you recognize and value their curiosity.

Sample outreach message:
—---------------------------------------------------------------------------------------------------
Hi <__________>,

I'd love to offer you an extended trial period of [Product Name]. This would give you ample time to experiment with its full range of features and capabilities.

Additionally, I'd be happy to provide you with more detailed insights and resources to enhance your understanding of how [Product Name] can best serve your needs.
—----------------------------------------------------------------------------------------------------------

P.S: Feel free to take these messaging ideas and tweak them to suit your own situation. Ideas provided here are suggestions and should be adapted and tailored to fit your specific context and audience.

Learn about Reo.Dev

The Complexities of Prospecting a Technical Audience

The 'Build vs. Buy' Mindset: Developers often believe in creating solutions themselves rather than purchasing off-the-shelf products. This mindset stems from a combination of their technical expertise, a desire for customization, and a deep understanding of their specific needs.

Inherent Preference for Self-Evaluation: Developers prefer to explore, test, and judge tools on their own terms, often through hands-on experimentation. This tendency makes them less receptive to traditional sales tactics, which are often perceived as intrusive or superficial.

Resistance to Conventional Sales Approaches: Developers are averse to aggressive sales pitches and cold calls, which are often seen as interruptions to their workflow. This skepticism towards sales outreach necessitates a more nuanced approach.

Convincing of Undeniable Value: The key to breaking through these barriers is to convincingly demonstrate the undeniable value of the product. It’s about showing how the tool can save time, enhance productivity, or provide a unique solution that cannot be easily replicated in-house. 

Cracking the Prospecting Code: Developer Intent is King

Despite these challenges, you gotta sell to developers. The key lies in understanding and leveraging developer intent signals. Why? Because developer tool purchases are not impulsive. The decision to invest in a particular tool is often a calculated, need-based choice. Understanding and identifying this intent becomes crucial for SDRs.

To decipher developer intent, SDRs need to ask three important questions.

Who needs my product? : 90% of developer activities happen in incognito. A significant part of the sales funnel remains anonymous. However, developers leave digital breadcrumbs across various platforms, which, if tracked and analyzed correctly, can be a goldmine for prospecting strategies.

When are they ready to adopt or buy?: Timing is paramount while prospecting technical audience because the necessity for specific DevTools varies greatly. Some tools are integral from day one of deployment, while others gain relevance as a project scales. Misjudging this timing can render even the best prospecting strategies ineffective.

How can I help?: The approach varies depending on the developer's expertise. A more advanced developer might appreciate a direct, technical approach, while others may require a more guided, consultative journey.

Decipher intent through developer activity

Luckily, you can find their answers to the ‘Who’, ‘When’, and ‘How’ by carefully looking for specific intent signals hidden in developer activity. Let’s explore what these activities are.

Cross-platform activity:  Consider this scenario: Developers from a particular company visit your GitHub repositories and subsequently read your documentation. This sequence of activities suggests more than casual browsing; it implies a purposeful search. Their journey from GitHub to your documentation pages is indicative of a deeper interest. This pattern of engagement offers valuable insights, hinting at a strong intent to explore solutions that address their specific needs and challenges. It's a signal that these developers are actively seeking tools or answers, potentially making them prime candidates for targeted outreach.

Building a Proof of Concept (POC): It's common practice to allow developers the freedom to start building with a product before they make a commitment to sign up or purchase. SDRs can leverage this to find intent and effectively engage with the developers. For instance, a developer might fork a GitHub repository, execute a 'git clone', or perform a 'Docker pull' to create a proof of concept (POC) using your product. Observing such actions is a strong indication of genuine interest and engagement from a potential customer. It signals that the company is not just exploring, but actively experimenting with your product. While this doesn't necessarily mean they are ready to make a purchase immediately, it does show a significant level of intent.

Evaluating competitor products: Enhancing technical prospecting strategy can be significantly bolstered by focusing on competitor funnel, specifically through monitoring activities on competitors' GitHub repositories. This method offers a strategic advantage, enabling SDRs to pinpoint potential accounts that are actively engaging with competitor products.

When SDRs identify developers exploring or contributing to these repositories, it opens a window of opportunity to differentiate your tool. This insight is not just about recognizing potential leads; it’s about understanding the needs and preferences of developers who are already in the market for similar tools. By analyzing the type of issues raised, the features requested, and the general discussion around these repositories, SDRs can gain a deeper understanding of what developers are looking for, and perhaps, what they find lacking in your competitors’ offerings. 

Armed with this knowledge, you can tailor your outreach to highlight how your tool addresses these specific needs or gaps.

Using Complementary Technologies:  Targeting developers who are already engaged with complimentary technologies, again through tracking activities on complementary GitHub repositories represents a strategic approach in your outreach efforts. This segment of the developers, actively using tools that align with or enhance the functionality of your product, is particularly ripe for prospecting. The rationale behind this is twofold: familiarity and synergy.

Firstly, these developers are already accustomed to an ecosystem that your tool is designed to integrate with or augment. This existing familiarity lowers the barrier to adoption, as the learning curve is significantly reduced. They are more likely to see the value in a tool that seamlessly fits into their current workflow or enhances their existing toolkit.

Secondly, the concept of synergy comes into play. Your tool, when used in conjunction with these complementary technologies, can unlock additional functionality or efficiency that might not be achievable with their current setup alone. This can be a powerful selling point. By demonstrating how your tool not only integrates but also elevates their existing technology stack, you can appeal to the developer’s constant pursuit of optimization and improvement.

At Reo.Dev, we recognize the challenges SDRs face in this while prospecting technical audience. We work closely with each company who signs up with us,  to unearth the intent signals most relevant to them and also assist in formulating an effective outreach strategy that resonates with the developer mindset.

Know more about Reo.Dev

These silos are expensive. They hide the true sales pipeline, reduce team efficiencies and channel investments in wrong directions.

So what should be the unifying factor that could bring all the teams together.

At Reo.Dev we believe it is the 'knowledge of the account / organisation of the developers.'

All the activities of developers, once translated into their employing organisations can help the entire GTM function have a single view, that is, which are the organisations where their organic developer motion is resulting in revenue opportunities.

DevRel teams can find revenue signals amongst a lot of chatter and prioritise activities. They can measure account movements in their activities.

Demand Gen and SDR teams can see accounts where developer evaluations are surging or maturing and gauge the right time to outreach.

The AEs can track their target accounts and see their developer activity levels. Understand where they need to push sales engineering support.

The illustration below helps describe the case in point:

Link to the original post I wrote on LinkedIn.

Overview

Developers are driving tech sales, with a staggering 66% of them influencing purchase decisions according to the 2023 StackOverflow Survey, echoing insights from the BCG report, that underscores the growing role of developers in shaping technology acquisition within companies.

But then does that mean that if you are seeing high developer activity from an organisation around your product, there is also a higher purchase intent within that organisation for your product.

There are two reasons why this question is important. First, because sales leaders often ignore developer activity signals for building sales pipeline. They suspect such developers are interested in only the free or open source offering and find it tough to build conviction to target such accounts. Second, if this thesis is true, the developer focused companies will realise that they are already sitting on tonnes of intent signals that could be monetised.

Our analysis on Reo.Dev data shows developer activity around your product ecosystem significantly represents sales intent. Few highlights:

• There is a 3X chance of an account with developer activity being at the bottom of the sales funnel than at the top of the funnel

• The more we move towards the bottom of purchase funnel, the more we see accounts with higher intensity of developer activity.

• 7 out of 10 accounts with developer activity at the bottom of funnel were ‘High’ dev activity accounts.

Analysis

For this report we analysed developer activity from multiple public and 1st party sources for 50+ organisations using the Reo.Dev engine that had a considerable bottom’s up developer motion. These developer activity sources included:

• Organisation’s owned Github projects,

• Organisations competing Github projects

• Installations of package managers (such as NPM, Helm) and docker pulls

• Developer activities on org’s technical docs

• Dev activities on organisation’s cloud products

This developer activity was then triangulated into accounts and analysed along with their CRM’s sales funnel stages in Reo.Dev. We attributed developer activity levels of an account into three categories of Developer Activity Score -High, Medium or Low - based on our proprietary algorithm that translates various developer activities into a top 10 percentile (High), next 30 percentile (Medium) or bottom 60 percentile (Low) band respectively. From the CRM, we looked into accounts that were marked either as Sales Qualified Accounts (defined as ‘Opportunity’ in this report) or Customers.

The initial hypothesis was to understand the correlation of Developer Activity score of an account with the overall accounts that are present in the ‘lead’ stage of CRM. The validation of this hypothesis lays the foundation for having Developer Activity Score as a proxy for accounts that are “hot” as well as propensity of them being lower down the funnel typically due to their engagement with the dev tool.

At an overall level, we observed that 1 in 6 accounts that are typically in the Lead stage of CRM are captured in Reo.Dev’s product with their Development Activity captured and engaging with the dev tool’s collaterals across docs/open source repos/product/website/community engagement. We have considered this statistic as the baseline for all our analysis in this report.

When we looked at the accounts deeper in the sales funnel, we observed that the ratio of accounts in Opportunity/ Deal stage in CRM was 2.06X of the baseline, i.e. about 1 in 3 accounts in Opportunity/ Deal stage was captured by Reo.Dev of having some level of developer activity.

Expanding this analogy to Customer accounts we observed an even higher correlation. The ratio of accounts in Customer stage in CRM was 3.18X to the baseline. Thus, nearly 1 in 2 customers were captured by Reo.Dev with their Development Activity observed and captured by the product.

The above analysis was a big eye opener to us as it clearly showed that the chances of finding an account with developer activity are more as the bottom of the funnel than the top of the funnel, clearly showing the correlation of developer activity with sales opportunity.

Next we wanted to check that does the intensity of developer activity increase along the sales funnel too? So we analysed the Developer Activity Score* of accounts across the CRM life cycle stages, and saw an even stronger correlation.

Taking the slice of accounts that are in CRM which also had developer activity identified by Reo.Dev, we observe these key aspects:

• ~45% of the accounts in CRM are contributed by ‘Medium and High’ activity band accounts - These accounts have a deeper level of engagement with the dev tool rather than lone wolf developers of an account engaging with the resources

• ~65% of the accounts in Opportunity stage are contributions from the ‘Medium and High’ activity accounts

• Nearly 4 out of 5 (78%) in Customer stage have ‘Medium and High’ activity associated with them

Extending the above trend exclusively to ‘High’ Activity accounts only further illustrates the correlation that exists between an account’s presence in CRM vis-a-vis their stage in the sales funnel. 70% of the accounts captured with Developer Activity present in bottom of the funnel stages are the ones with ‘High’ Developer Activity. This aligns with the hypothesis that Developer Activity is going to be a critical indicator of the purchase intent as involvement with the dev tool at an advanced level typically would tend to convert into a paying customer.

All of the aforementioned characteristics provide evidence that Developer Activity is correlated to sales opportunity and Developer activity signals capture purchase intent of an account in a significant manner.

The entire analysis done by us was on accounts available in user’s CRM. Once the above correlation is established, this also meant that accounts which were not in the CRM, but had high or medium developer activity, also had significant sales potential.

And when we looked into this data, we saw that on average a significant 83.4% of accounts with any kind of developer activity around the analysed tenant’s product and associated ecosystem were not in their CRM. This statistic made logical sense due to the anonymous nature of developer activity that got captured by Reo.Dev engine. Developers are active mostly outside a signup, such as on your open source projects, documentation, support communities and other assets. Hence there is a good chance that a typical CRM would have no record of such activity, however significant.

Thus the numbers show that developer marketers have a big problem of an invisible funnel since roughly 5X of accounts with developer activity and the correlated sales opportunities are unknown to them.

What does this data mean for Developer GTM leaders?

The report aligns with the core thesis to developer marketing and a bottom’s up developer motion; that developers can strongly champion and influence purchase within their organisation.

Here is what we think GTM Leaders in Developer Focused Companies can learn from this:

Your Developer activity should be a feeder into sales funnel

Every matured GTM starts with a qualified account. Today developer focused companies rely on multiple ways to reach the qualified accounts. Many start with a cold outreach on their ICP segment, while others look at signal such as website visits or product signups.

Looking at the data, we recommend that accounts with developers active around your product or community should be the first qualifier. This data should then be overlapped with your ICP criteria to build your target account list. Finally based on the maturity of developer activity with the account, you can define your account GTM strategy. If you are seeing one or two developers just starting the exploration you will need a more nurturing and education GTM strategy, while if you see that the account is ripe with few more developers and activities, that means the account must have matured for outreach.

Developer activity can help you prioritise your mid of funnel accounts

As the data shows a positive correlation between developer activity and sales probability, developer activity can be a great signal for sales executives to prioritise mid of funnel accounts. Sales executive have a long list of accounts to close. Many of them focus on a region and vertical, have discovery calls with multiple prospects, but there is always that challenge of which accounts should they prioritise.

They use intent tooling for tracking email opens, sales proposals reviewed which work for business buyers but developer are active on different assets such as your docs, code commands, product trials and more. Exposing sales executives to developer activity trends within their list of accounts can help them prioritise and strategise their pitch better.

GTM leaders need to build sales tooling for Developer data mining

While many of the things said above might appear logical, analysing developer activity is tough and the reason for that is most of the developer activities are anonymous in nature. You will find them signing up with burner email IDs or active from their Github or Stackoverflow IDs or even evaluating things anonymously on your docs without signing up. In fact a lot of developer experience (DX) stack has been created so that developers can evaluate the product without having to signup or pay.

Hence you will need tooling to understand and triangulate developer intent, the detailed stack requirements are been given below.

Converting Developer Activity into purchase intent: Emerging Playbooks

As we can see from the data that developer activity is correlated to sales opportunity. It is also equally important to understand that while analysing developer motion will give you both accounts and developer leads who are interacting with your product, meaningless outreach to both might not help. Unlike in other marketing motion, qualification is much more important in Developer focused GTM.

Hence we wanted to conclude this report with few emerging developer led GTM trends:

Think accounts, not leads

When it comes to Developer Led GTM, champions are employing account based strategies. Instead of looking at opportunity from individual developer’s activities they are trying to create one complete account picture and then prioritising accounts based on activity trends. When they move the analyses from a developer to an account level, you start looking at a broader opportunity and start getting better signals.

Find the ‘right time to get in’ an account

It is important to know that any developer activity does not mean sales opportunity, but the sales opportunity matures with developer activity. The Developer activity lifecycle in a product purchase can be broken into 4 stages:

• Pioneering: Pioneer or champion developer discovers the product and start playing around with it

• Surge: More developers join the product evaluation and the developer activity surges. These teams will tinker with the product and start exploring it more. This stage will be represented by a ‘surge’ in cumulative developer activity

• Evaluation: The buyer in the organisation is made aware of the problem. The users go deeper into the product and start building POCs. The developer activity soars even more as multiple developers or teams tinker with the product.

• Decisioning: The buyer builds a business case for the product. The Developer teams qualify solutions and make their recommendations

Hence when it comes to Developer led GTM, it is very important to find the right time to get into an account. If you rush in too early, the buyer would not have been involved in the purchase. If you go too late, the buyer would have already moved to competition or the organisation would have adopted an open source product.

From the chart above you will see that the right time to outreach the account when stage 2 is maturing. It might vary org to org, but typically we see this is represented by 2 or more developers getting active on the product around the same time and surges in developer activity.

Build a winning DevX to win the GTM game

For an evaluation to mature it will have to pass through the early stages of developer discovery and pioneering. These developers are finding solutions to their organisation’s tech problems. There is no business case for GTM teams yet. Hence the most prominent engagement strategy here is to build the right developer experience to help the developers discover the product and learn about it as quickly and easily as possible. Thus the best Dev GTM teams lead through education and developer relations and ensure the developer teams get the best experience in understanding and tinkering with the product. Here is a great post that talks about Developer Experience (DX) and the tools you can use to design it.

Build and run separate user and buyer databases and nurtures

As you can see above, the Developer led GTM has a hybrid motion with two different personas. The two personas - the Buyer and the User (Developer) have very different needs and motives around your product. Also they are so different that the same communication and massaging will not work for both the personas. Yet, we see majority of marketers do not differentiate between the two. Hence a developer is outreached with a sales messaging while a buyer gets technical nurtures.

Hence champion GTM leaders are clearly differentiating between a buyer and a user, and designing very different messaging strategies for them that are aligned with their motivations and incentives.

About Reo.Dev

Reo.Dev is a GTM OS for developer focused companies. Reo.Dev helps GTM teams accelerate their sales by using AI to gauge developer intent signals across millions of open source, public and first party data. Reo.Dev’s revenue AI engine converts these intent signals into organisations and developers who are already interested in their product and provides GTM teams a comprehensive platform to take these intent signals to the last mile.

We power the growth engine for popular developer tools such as Ververica (part of Alibaba Group and owner of Apache Flink), Lightbend (owner of Akka) and Unleash (top alternative to Launch Darkly). For more information visit www.reo.dev

*Developer Activity Score is Reo.Dev’s proprietary algorithm that measures and labels overall developer activity levels within an account. It looks at developer activities across channels, number of developers, their recency of activity and multiple other parameters to translate developer activity into a top 5 percentile (High), next 15 percentile (Medium) or bottom 80 percentile (Low) band respectively.

🚞 December 14th: Many of our customers want to differentiate accounts active on the docs of their free product / MIT license and paid product/ BSL license. They also want to track key sections of their docs . So we launched ‘source tracking’ - a feature for customers to track accounts active on different documentation versions and pages 

🚄 Jan 5th: Our team again worked through the Christmas and New Year to launch some amazing features 🙌 : 
- We launched Telemetry APIs! - first time ever any OSS company can push their telemetry data and see accounts (enriched by IPs) that are using the OSS version 
- Product Usage Data Integration - Customers can send their product trials and cloud usage data to see one single account picture across product, telemetry, docs, package manager and Github now! 

And this is just 3 months of product launch! We hope to ship even faster now.

But nothing like this would have been possible without the amazingly hard working team at Reo.Dev.
I wanted to end it with this video that probably summarises every thing I said 🙂

Source: Gartner

The majority of these intent signals is around content and topics, where marketers track accounts from where they are getting website traffic (using IP reveal mechanisms) or accounts where employees are reading about topics core to the marketer on third party sites (using third party intent data)

But for Developer focused companies, the most important intent signals are in developer activities around their product. These signals are completely different from the intent signals marketers have been tracking in the past. These signals include activities where developers trying out the product, reading developer docs, trying example code, installing package managers, doing activities in sandboxes, participating in communities and more.

Deriving intent from Developer Docs

In this post want to focus on a very obvious but perhaps the most ignored intent signal of developer interest, and that is the traffic and activities on the developer documentation (docs) of a developer focused company.

At Reo.Dev we mine developer intent for many developer focused company and have been amazed by the intent signals on the documentation. Our analysis across all our users show that amongst all channels developers engage with a product, docs get highest amount of traffic.

We also see that docs traffic is much more relevant for developer focused companies than website traffic. Our analysis on the traffic on docs vs website data shows that the accounts / organizations who visited the docs had more developers and hence were a better fit for the developer focused companies than accounts who visited the websites, where the traffic was more generic.

In retrospect this sounds very logical too as docs are very specific to the problem the product solves. They are not created to attract traffic, generally not built after analysing keyword search trends; but with the idea of helping someone get educated about the product or the problem it solves.

How to analyse docs data

Analysing website traffic is nothing new. There are bunch of tools such as clearbit, leadfeeder, that help you in IP revealing (so you understand people in a certain organization are visiting you webpage) and more such as Google Analytics, Mixpanel that give you webpage analytics.

However analysis of docs data is different from the website data because the way content is consumed by a business user is very different from a technical user who will go very deep into the content if interested.

Hence once you have planted an IP reveal tool in your docs, here are a few ways to get the most intelligent intent signals from your docs.

• Understand the usage patterns from an account over a period of time

  Developer marketers want to know what is the right time to get in an account. They provide a free tool (via developer/ trial version, sandbox or open source) to the developers and want to use it to get into an account with a sales opportunity, the challenge being it is very difficult to know the right time to get into an account where the developer activity is maturing.

  Analysing your technical docs traffic is a great proxy for understanding the maturity of developer intent. Generally the dev adoption journey start with a single developer playing around with your product and in that journey the developer spends time on the docs to understand the product better; and then if the tool gets internal adoption, more developers start spending time on your docs.

  Thus tracking this spike in your docs usage will help ensure you hit the right time to outreach the buyers when the developer evaluation has matured.

• Understand developers interactions with your docs

  Developers who are serious about a product won’t just read the documentation but interact with it on a code level. They will install package managers or execute docker commands and code examples. They will search for stuff, copy code block and text / content to share with other developers.

  Such interactions are unique to developers and tracking them can help you find the account where developers are really active on your code, thus helping you get stronger intent signals

• Prioritise accounts based on key sections/ pages of the docs.

  Since developers are going through your docs to educate themselves about your product and guide their usage, the sections of the docs they are spending more time is a great signal to know where the developers in that account are in their trial journeys. By analysing whether they are spending time on references, guide and tutorials, getting started or any other similar sections of your docs can be a great intel for interpreting intent.

• Triangulate developer intent from docs with your product signups

  For Developer tools with a PLG strategy finding the right lead from product signups, with desired intent from a company that is worth going after can be like finding a needle in the haystack. Marketers look as a signup as a purchase intent and bombard developers with marketing mailers and sales messaging.

  But product usage data married with the docs usage data can help you create a more relevant playbook where you can form a comprehensive picture of an account and purchase stage. Thus it become much easier to understand if the developer leads from product signups are in their research stage, POC stage or at a stage where they have qualified the product internally and could become great champions to getting warm account intros.

If you are looking for a tool to do all of the above, try Reo.Dev. We believe there is tremendous wealth in developer activities data around your product and are building a GTM OS for mining such data for Developer Led GTM.

Check Out Reo.Dev

A sure shot way to perplex GTM teams is the task of targeting developers. Developers aren't just a homogeneous group of code enthusiasts. To an outsider, they might appear simply as tech-savvy individuals, but beneath the surface lies a complex spectrum. They span various skill levels, employ diverse tech stacks, and align with entities from nimble start-ups to behemoth tech firms. Their projects can range from crafting simple apps to trailblazing in AI and quantum computing realms.

This multifaceted landscape is both fascinating and daunting for GTM teams. Crafting sharp, effective strategies to engage them requires more than generic outreach—enter the nuanced art of segmentation.

Why traditional segmentation doesn't work for developers

Simply leveraging traditional metrics—like demographics, or behaviour—can lead to a misguided approach, and here's why:

Demographics: Developers, by and large, prioritize the merit of a tool, its functionality, and how seamlessly it can be integrated into their current project. A young self-taught programmer might prefer the same tool as a senior developer based on the tool's technical prowess

Traditional behavior metrics like web page visits or clicks might not give a full picture. Developers often lurk in forums, gather insights from peers, and spend time in documentation before making decisions.

The power of action-based segmentation

To truly understand and appeal to developers, you must look at the actions they take. These actions provide deeper insights into their interests, the challenges they face, and the solutions they are likely to adopt.

GitHub Activity: GitHub, and similar platforms, are hubs of developer activity. By monitoring repositories, stars, forks, and contributions, you can gauge the popularity of tools, libraries, or frameworks. High activity often signifies a strong community and robust support, two factors that are crucial for developers.

Documentation Interaction: Developers dive deep into documentation. Monitoring which parts of your documentation are most accessed, or where users spend the most time, can offer insights into which features are most valued or where there might be confusion. Keeping a keen eye on this can also help improve the product itself.

Package Manager Downloads: Package managers are essential in the developer ecosystem. Tools or libraries with high download rates from package managers like npm, PIP, can be indicators of widespread use or growing trends in the developer community.

Decoding developer intent through their actions

GitHub Activity: Beyond just the quantitative metrics like stars or forks, understanding the type of comments or issues a developer raises can be revealing.

Documentation Interaction: Delving into documentation is rarely casual browsing. If a developer spends a lot of time in a specific section of documentation, it might indicate they're trying to integrate that feature into their work, or perhaps they're facing challenges in implementation.

Package Manager Downloads: While high downloads indicate popularity, a sudden spike in downloads for a specific tool or library might indicate a growing trend or a recent industry need.

Forum Discussions: Developers frequently turn to forums for advice, best practices, or troubleshooting. The questions they ask or the topics they engage in can shed light on their current projects, challenges, and future plans.

Developer Segmentation Framework (DSF)

As we delve into the complex landscape of understanding developers, it's beneficial to have a structured approach. Enter the Developer Segmentation Framework, a guide to effectively segmenting the developer audience:

1. Basic Metrics (Surface-level Understanding)

• Demographics: Age, designation

• Geography: Regions

• Traditional Behavior: Web page visits, clicks, event attendance.

2. Action-based Segmentation (Deeper Dive)

• Platform Engagement:

  • GitHub: Repositories starred, contributed to, forked.

  • Stack Overflow: Questions asked, answers given, tags followed.

• Content Interaction:

  • Documentation: Sections visited, time spent, recurrent visits.

  • Blogs/Tutorials: Posts read, comments left, shares.

• Tool Utilization:

  • Package Manager Downloads: Tools/libraries frequently downloaded.

  • SDKs/APIs: Integration and usage frequency.

3. Intent Interpretation (Heart of the Developer Segmentation)

• Inferred Specializations:

  • Deduced from consistent contributions to specific topics, e.g., machine learning, web development, or cloud computing.

• Projected Needs:

  • Based on documentation areas frequently visited, or forum discussions. What are they trying to achieve?

• Trend Alignment:

  • Intent signaled by rapid shifts or increased activity in specific tools, languages, or platforms.

4. Engagement & Validation (Closing the Loop)

• Personalized Outreach:

  • Tailored content, resources, and solutions based on deduced intent and actions.

• Feedback Channels:

  • Forums, GitHub discussions, or direct surveys to validate segmentation insights.

• Community Involvement:

  • Sponsorships, hackathons, webinars, or workshops focusing on popular trends or areas of interest.

5. Iterative Refinement (Continuous Improvement)

• Regularly revisit and refine segmentation based on changing developer behavior and feedback.

• Stay updated with evolving tools, platforms, and developer preferences.

• Constantly innovate and adapt to provide value in alignment with developer needs.

While the world of selling can often be complex and multifaceted, selling to developers necessitates a shift in perspective. By emphasizing action-based segmentation, coupled with an intent-focused approach, and aided by the DSF, sales and marketing professionals can truly resonate with developers. The aim is not just about selling a tool; it's about integrating into a developer's workflow and becoming an essential part of their toolkit.

Check out Reo.Dev

Developers are the most evolved buying personas. While the rest of the B2B world has only recently adopted the more product led measures of purchase - where they want to rely on their own research, their experience with the product and their own understanding of product features; developers have almost always shown such product focused purchase behaviour where they do not want to be sold to and try (in fact build) things before they buy.

But if someone does not want to be sold to, does not mean there is nothing for the sales and marketing team to do about it. In fact, the Modern GTM process by Unusual Ventures and a number of thought leaders in the space have been prescribing a redesign of the GTM process for modern software buying behaviour.

Hence, it would be useful to discuss how should the Modern GTM Process look for a Developer Led Sales Organization. So before you proceed we highly recommend you to read Understanding Modern GTM and The Modern GTM User / Buyer Journey by Unusual VC; although to put it very briefly:

• Modern GTM is needed since buyers today don’t want to be sold to; at least till they have experienced the product themselves

• It prescribes creating steps and action items specifically for 2 personas - the User (someone who will try your product but will not have the budgets and authority to purchase it) and the Buyer (someone who will listen to and be heavily influenced by the User, might only partially try the product themselves, but will have the budgets and authority to purchase the product)

• Also, organizations need to have Hybrid GTM processes, a mix of Bottom’s up and Top Down; where the User will need content, education and a strong self serve motion driven by marketing and product teams (Bottom’s Up); while the Top Down sales team driven processes get activated once the prospect has experienced product on their own.

Old GTM Processes and why they don’t work for Developer Focused Businesses

Although developers are the most evolved buyers, organizations selling to them have not evolved their GTM processes. Sales by majority of the B2D or Developer Focused Businesses today look fairly similar to a product led B2B businesses barring the existence of a Developer Relations team that is focusing on the Developer Community or in many cases an open source product strategy. However all of channels operate in silos and focus on ‘Qualifying’ a Lead or Account which are then qualified and picked by sales.

Although this processes has worked great for many years for traditional top down sales businesses, this process falls short in modern times, especially as competition and revenue pressure increases and the key audience that needs conviction is a Developer.

The first reason is that this process is highly inefficient. It has all the teams operating in silos while the prospect is acting in a synchronous way (the user is evaluating product and giving highly trusted recommendations to the buyer). So, for example, the developer champions (devrel teams) have no formal way of helping in sales, although they hold the most important node in the transaction - the developer. Marketing teams are nurturing the user and the buyer alike while they are very different personas; and complaining that they are selling to developers who don’t want to buy. BDRs are frustrated and struggling, feeling they are just spraying and praying to an audience who don’t want to respond to them.

Secondly, it is designed for the Sales teams and Account Executives to act as hired guns with no help or context on how to make inroads into the prospect organization. Whether the prospect will spend time with the Sales team is a hugely dependent on whether the prospect has reached the stage that they are ready to buy. In most cases this means, developers have evaluated the product and recommended it to the buyers. AEs going with the old BANT (budget, authority, need and time) framework will either focus on the wrong deals or miss a lot of right deals if they do not take care of this fundamental step in the purchase process where the management will rarely go against developer recommendations.

What does the Modern GTM process look like for Developer Led Sales?

The Modern GTM process for B2D companies differs from the traditional approach in many ways including:

• It acknowledges 2 very different personas involved in the purchase process, a Developer and a Buyer. Developers do not want to be sold to; they want to discover their own solutions but want to get prompt support and in fact appreciate help from engineers whenever asked. They might have limited or no budgets but have a very strong influence on the purchase process. The Buyer, typically a CTO, CXO, VP Engineering or VP Product will have budgets, will be more open to a discovery call or a sales / marketing conversation but will not purchase against their team’s recommendation. In fact any sales effort targeted at buyers will end up being delegated to the developers for their trials and POCs for qualification.

• It is neither bottoms up nor top down, but hybrid. The Developer needs a bottom’s up activation which is educational, product led and community led. While the Buyer will need a more top-down support of a commercial function such as sales especially for larger ticket sizes.

• It is collaborative and assumes coordination between teams. Each step will have multiple teams collaborating for success. This is very different from the Old GTM process where each teams had to operate in silos. For example, the product teams will need constant feedback to improve the developer experience at time of trials or POCs but such intel will reside with the DevRel team managing communities. The product team will need to put in growth triggers within the product to push the developer to either talk to support or take up a paid version. The growth teams will need to tell the sales which accounts amongst the hundreds of leads, signups have the true intent to go after.

Understanding stages of Modern GTM for Developer Led Sales

Stage 0: Organization has a technical need

Every Developer Tool or Infrastructure product is a solution to a technical need in an organisation. More often than not such needs either emerge out of a complex problem the organisation is trying to solve, a complex engine it is creating that needs the right building blocks or that it needs its engineering talent to focus on the right problems and wants to delegate the routine ones.

Stage 1: Developers search solutions for the technical need of the organisation

This is the stage where developers will start with the problem and try to find solutions. They will ask around for solutions in their cohorts, search the internet, read technical content about it or ask within developer communities or forums.

This is also the stage where they might discover about your tool from fellow developers, from someone they trust or just stumble across content that points them to you.

Stage 2: Developers start trying out solutions

This is when they start actively getting into code. Developers will be forking your github repos, trying out open source code or free trials. This is the stage where they are evaluating and learning about your product. They will try many solutions and your tool might be one of them.

The success of this stage depends of course on the fitment between the product and developer need but most of the times it also comes to how optimised the product trial is in helping the developer get to ‘hello world’ or early success. The developers will go through your docs and try to understand the product and a great DevX here will go a long way in escalating your tool up the evaluation ladder.

Stage 3a: Developers start building stuff with your product | Stage 3b: Early signals of Buyers getting involved

This is when your tool reaches higher interest levels in the internal developer community of your potential customer. That means, you will see more than 1 developer actively interacting with your product ecosystem - studying your docs, downloading / executing your code, signing up and trying your product. You will see more pointed queries on your developer support channels.

This is also the stage when buyers might get aware of the problem or at least start considering it seriously. They might respond to sales discovery calls and take demos. But in many cases your tool would go back to the developers as a recommended addition in their evaluation pool.

This is where Developer led businesses see the ‘right time to get in’ for sales teams. By looking at developer intent signals they can understand the opportunities, context and personas to get ahead in the consideration set.

Stage 4a: Developer qualifies the solution | Stage 4b: Buyer builds a business case around the product

Developers typically will not just try before they buy but build before they buy. This is a stage where either your free product, open source product or freemium product version gets a ‘good to go from developers’. You might see increased developer adoption and the cumulative time spent by them around your product ecosystem might spike.

From here you might want to leave it for the developers to organically move up your PLG funnel or you might reach out to the Buyer and build a business case with them. The buyer interest will be at its maxima at this time; which also makes this stage a great time for your sales teams to get in and start helping Buyers build the business cases.

Stage 5: Buyer engaged in advanced sales and commercial conversation

This stage looks so much like a typical advanced enterprise sales stage, that many developer focused companies confuse enterprise sales ‘efforts’ to be the only money maker within the organisation. However it is very necessary to understand the build up to this sales motion and when you do that, as in this article, you see the importance of all your efforts coming together to make this happen.

Stage 6: Developers and Buyers experience success and evangelise the product within their networks

This is when the purchase and implementation happen and the customer organisation experiences success with your product.

How to crack the Modern GTM for Developer Led Sales

Think Account First; Lead Second

Traditional marketing prescribes to setup nurtures when you get a lead, setup discovery calls when you get a sign up. However, as a Developer Marketer it is important to understand that all these are signals of developers who want to be left on their own until they need help. The right way to crack this is to triangulate these developer intent signals and identify the accounts with opportunities.

Employing Account Based GTM efforts can kick in from here and GTM teams can use the context from developer activities to make the right approach to the right persona within the Account

Understand who is a buyer and who is a user from your lead database

The two personas - the Buyer and the User (Developer) have very different needs and motives around your product. Also they are so different that the same communication and massaging will not work for both the personas.

Hence the first step here is to clearly differentiate a Buyer from a User / Developer in your Marketing and Sales platforms. Few signals you can use:

• Designations

• Delegations - do your discovery calls result in new developers signing up on your portals

• Time spent with the product and on the docs - those leads going deep on technical assets are developers

• Depth and intensity of product usage

Once you identify them, you can design very different messaging strategies where developers can be nurtured.

Setup a Developer Database to Nurture Developers from aspirational accounts

Once you have a different Developer DB you can plan your segments and nurtures differently than the Buyers. While the traditional GTM methods of retargeting, email follow-ups or request for discovery calls might works for Buyers; your nurtures for Developers have to be about their education, helping them reach the solution quickly and get them any support they need. This completely changes the messaging they receive, the content on which they are nurtured and who interacts with them when they request for support.

Setting this up will also help the DevRel and Support Engineers prioritise developers from important accounts and provide better SLAs. Insights / Triggers of Developer Activity in the CRM would not mean you reach out to the developer to sell, but prioritise the accounts and buyers in the account in the right manner; now that their Developers are active on your product.

Analyse and Strategise Account Entry based on Accounts with Relevant Developer Activity

Till now your tools and community have done their bit to get the developer’s interested. Your Developer DB has helped you treat the Developers correctly and educate them rather than annoy them with marketing materials. You are not just tracking Leads but also Accounts where Developers are active. Hence, you know which accounts really have the opportunity to close a deal

This is when you reach the stage where all this momentum can pave a seamless way for you to enter into these accounts. In fact we have written more about how you can use your Developer motion to get warm account entries to Buyers here.

Represented by Stage 3 and 4 in the above diagram; you can pass on the baton to your sales and account marketing teams with the right context and maturity to invest in the right accounts. Few signals that help you understand you have reached ‘the right time to get in an account’ are:

• Developers of that account are studying the advanced features or going into depth of the product

• Multiple developers from the account have started working or evaluating your product

• You are seeing repetitive Developer activities from the same account in shorter time periods.

• Developers from the account are spending time on your docs or asking questions in your communities.

Collaborate and Close

A very observable thing about Modern GTM process is that multiple teams need to collaborate to make the magic happen. Without a product led bottom’s up motion a Developer will not be convinced to recommend a product, without a DevRel function they will not get the support needed to see quick wins with the product. Similarly it is the marketing function that is bringing more of Developers and Buyers into the funnel and it is the Sales function that is taking it to the last mile to closure.

Hence Modern GTM needs to be run like a cross functional program with a program owner and program’s data visibility across participating team so everyone has their eyes set towards the North Star.

As a GTM leader it is very important to know the evolving GTM processes. By breaking them in context of Developer led sales we hope to make it easier for them to navigate and win.

As a Marketing or a Sales Leader of a Developer Focussed Business, if you feel you need a tool to adopt the Modern GTM motion in your organization; Reo.Dev might be the right tool for you. Reach out to us for a chat.

Visit Reo.Dev

Secondly, analyzing Github data beyond a certain point is expensive. For example, if you want to learn the Github user’s organization, email ID, social profiles, or any other contact handle, you might have to use multiple and expensive enrichment tools or even manual methods to derive that. This can only be done once you know a Github signal is truly worth going after.

Also, any medium to highly popular Github repo will have thousands of such stars or watchers and for marketers it becomes a problem of many. How do they know which signup is worth pursuing more? Where is a real opportunity?

Not all Github Stars are created equal

The value of the Github Star essentially depends on who is the developer (organization, designation, influence) who is Starring the repository and in what context (lurking → experimenting → actively seeking solution → actively evaluating a product) is the developer Starring it. Hence we have listed methods here to discover which Github Stars are more valuable than others:

Tracking User Actions in Competitive and Complimentary Open Source Repos

One great way to know the value of a Github activity such as Star, Watch, Fork and more in your Open Source repo is to track if similar activities were done by the same Github ID in competitive or complimentary Github repos around the same time period.

That is great signal to learn whether the developer is evaluating a tool or finding solutions to certain problem their organization or project is facing. If the developer has actively done certain actions in competing or complimentary repositories, there could be an active sales opportunity within the organization.

Tracking User Actions within your repo/ community

Another way to obtain value of a Github Star is to discover how engaged that developer is around your product ecosystem.

• Is the same developer doing other actions on your repo? You can know this by tracking the actions of the developer’s Github ID in and around your repo.

• Has this developer done activities in your website such as signing up for your product trial (if you have a cloud version) or any of the marketing activities and events. Knowing this is easier if you have the developer email ID or use their First Name and Last Name from Github and run a fuzzy match with your CRM data.

  PS: Using a “Github signup” button in your forms for product trials or any marketing activity can be another smart way of mapping a user’s Github ID to your CRM data. You will have to build a Github App for it, but if you have a strong open source strategy, this might be very useful. Here is an article that goes into depth of building such apps.

• Is the developer active in any of the developer communities relevant to you?

Uncovering Developer’s Organization Fitment

Uncovering the Developer’s organization can be challenging, and we have written more about ways to get this data in this article. But once you get there; your Github Star signals can be analyzed in two ways:

• Finding the organization fitment: Is the organization the right fit for your company? Because if it is, this can be a great data point for a potential lead, since you can clearly track that a developer from a relevant organization is interacting with your open source repository.

• Triangulate activity from other developers within the same organization: Have more developers from the same organization stargazed/ watched/ forked your repo, or have they been also doing certain actions in your competitive or complimentary repos?

Once you have this data, you will be in a much better position to learn how many of your Github Stars actually have a business value and hence are worth focusing. You can even build your simple scoring models based on the above parameters to understand which Github stars have more value compared to others.

What happens once you know which Github Stars are more valuable

This is where we make the whole thing a lot more fun (and slightly complex)! The value of intent data to a marketer is not just to know ‘who’ are the potential customers but also ‘how’ to get more of such potential customers and which developer marketing campaigns or activities brought the more valuable ones.

What if we analyzed the Github Stars as a function of time and mapped them to the developer marketing / devrel campaigns or activities conducted? Since now we know the value of a Star, we can interpret which campaign correlates to higher value Github Stars.

Understanding the business value of Github Stars is an ongoing challenge for marketers, but there are ways to navigate the sea of data and find relevant signals. As mentioned above, not all Github stars are equal. The key is to not just look at the Github Star as a metric but as a signal of intent and dive deep into the developer's identity and context in which your repository was stargazed.

At Reo.Dev, we meet GTM leaders of developer tool companies every day and learn from the best in how they solve this problem. We have seen a few themes and tactics emerging:

Analyze the data patterns of the bottom-up developer motion to learn teams, hierarchies, and decision makers

Many sales and marketing teams make the mistake of reaching out to developers using or evaluating their product directly. Since this persona is generally not sales and marketing friendly (or at least not friendly to ‘bad’ sales and marketing), a direct outreach to developers rarely works.

A more effective technique is to analyze data from the bottom-up dev GTM motion to understand the patterns to fine-tune the outreach efforts to the buyers/decision makers:

• Learning the ‘right time to make a sale’: In Developer tools leveraging bottom-up dev GTM, a very important metric to measure is whether it is the right time to make a sale. Because if you go in too early, the developers in your prospective organization might have just started evaluating or understanding your product, and the buyers might not be ready (or even know yet) about your product. And if you go in too late, the prospect might have moved on to competitive products or might not need your help anymore. However, studying the data can be a great way to understand the ‘right time to make a sale.’ A few indicators include:

  • Developers are studying the advanced features or going into depth of the product

  • Multiple developers from an organization have started working or evaluating your product

  • You are seeing repetitive activities from the same organization in shorter time periods.

  • Developers from the organization are spending time on your docs or asking questions in your communities.

• Studying organization, designations, and location of the developers interacting with your product: A few patterns that could be recognized from here include whether the buyer or a senior decision maker is already interacting with your product. Or in cases where your developer users might be from large organizations in multiple locations, by studying the location of the users, one can understand which office or team might be evaluating your product. This can help you narrow down the prospects who might actually know about your product and might know about an ongoing product evaluation.

Use your developer community to build bridges to the decision makers

Another great tactic we have seen amongst Developer Tool leaders is that they leverage the pool of their developer champions built through their PLG and community motion to get warm entries to the decision-makers.

We have seen such DevTool leaders front-end their DevRel teams to help bridge the trust gap between the sales teams and developers. The DevRel teams are already connected to the developers and are a known face to them. Where sales teams’ communication might be ignored by a champion developer, a DevRel team's communication, that is often more supportive and built around helping developers see their efforts come to light, can be more useful.

Here, what works best is giving your DevRel teams the same visibility into the sales and GTM funnels, as the rest of the sales teams. This helps them identify accounts that are important and get the desired context to orchestrate communication.

Leverage the Developer GTM momentum to customize your pitch stories to the buyers

Creating account-based views of your bottom-up developer activity can help you get context that can really differentiate you from the competition. You can use this information to build trust and familiarity in your sales pitches and also bring forward the knowledge of the challenges the organization might be facing that your product can solve better than the competition.

An early customer of ours commercializes a popular open-source project through their cloud offering. When they analyzed the open-source project using Reo, they learned that a certain group of developers in a large enterprise account had been tracking the open-source project they were commercializing for the last 6 months, and recently one of the developers had forked the Github repo and created multiple issues. Realizing that this organization might be actively needing their product, their sales team went to the CTO with a strong story around the advantages their product offered on top of the open-source offering.

In another case, the DevTool company provided an open-source collaboration platform and realized through the in-built opt-in telemetry function in the platform that certain organizations had 200+ active users already using their product. He used this data point to reach out to the CISO with a story on how the paid version of the product can seamlessly transition the existing user base to an environment more suitable to the security needs of the company.

Postman uses this approach a lot too. Here is an excerpt from an interview with their CEO where he discussed using data of developer bottoms up for enterprise sale.

“So it (analyzing data for sales) allows us to be intentional with every aspect of the business. And sometimes even talking to customers, right? So when we go to customers, and they're curious about the scale of adoption, that Postman has in their accounts, we actually use this data to tell them. And it really helps us.

Typically when you're going into enterprise, you have a lot of these unknowns, and we do a very hypothesis-based planning exercise, we look at, "Okay, this is our hypothesis and this is the data supporting it. And what is the data that is not supporting it?" And then we are able to just have much more conviction. So it touches every aspect of the business.

Empower Developers to evangelise the tool internally.

Developers are good at evaluating the tool and using it themselves, but not at selling it internally. The purchase decision maker will want a business case for paying for the tool - so what can you do to empower developers to make your case?

Make it easier for developers by providing them data/intel on:

• Number of developers hours saved by your tool and hence cost impact

• Dollar value added by your tool

• Easy comparisons between your tool and other options.

• Collaterals, video guides and product demos to champion your product internally

Developer tools is one fascinating industry, where, due to the product and community driven behaviour of developers, who play a very influential role in the decisioning; the analysis of bottoms up data, utilizing developer communities, and customizing pitch stories to buyers can create strong impact right upto the bottom of the purchase funnel. Hope the above tactics and best practices help you in leveraging your developer momentum to build a path to the actual buyers and decision makers.

If you are a data driven sales and marketing person trying to convert your developer motion to revenue - Reo is the right tool for you. Reach out to us to learn how our revenue intel platform can solve your challenges.

Try Reo.Dev

Open source is not a business model, it is a distribution advantage. Communities of millions of developers trying out your product, giving feedback and building along with you. But then converting this motion to a revenue needs significant efforts, which often starts with understanding which developers in which organizations are using or contributing or simply playing around with your open source product with business related needs or evaluations in mind.

Getting this intel can uncover a lot of value for a Commercial Open Source Business, especially for their enterprise sales teams that can use this mined data to understand which accounts to target and how to target them since a lot of this can be gained from analyzing the usage data. It comes as no surprise that companies such as Hashicorp and Imply, along with many others, have mined their open source usage data to build intelligent pipelines for their enterprise sales teams (source).

Imply’s enterprise sales team closely monitors the company’s open source Druid base to inform them on which organizations might be ready for an enterprise proof of concept. PQLs that have previously used Imply’s open source offering (either in testing, development, or production) are coded as “pre-buyers,” while leads with no prior exposure to Druid are coded as “pre-believers.”

Source: BVP Atlas

The trickiest part of mining data for enterprise sales is that you first need to understand which of the accounts playing with your open source products really fit your customer profile, and are really worth going after based on their purchasing powers and fitment to your growth strategy. Secondly, you want to track their activity across time to understand the usage patterns to know what is the right time to get into the account and make a hard push. If you go in too early, the buyers might not have completely discovered the problem and will not be ready to talk to business teams; and if you go in too late, they might have already customized the open source product in a way that fits them best. The third part is that once you identify an account that fits the enterprise sales criteria, you want to know every developer activity happening in the account because even small signals (such as a developer asking a query in an open forum or your support community) can mean a lot commercially.

Understanding Developer Intent Sources

The key in any enterprise sales activity is to filter out revenue signals from a lot of data. Probably, one important thing here is to know the sources where you can find developer intent and how you can decode it to know which organization/team is evaluating your product. Once you have that, you can triangulate the data to create an account-based view of developer activity.

This has two parts, a) understanding what all intent sources are important for you and b) then who are the developers who are showing signs of activity in such intent sources and which organizations they belong to.

Intent Sources

There is a whole host of places where you find developer intent. Since we are discussing mining OSS data, we are limiting to selected sources which might be more important for an OSS-focused company:

• Github engagement data: This will include any usage or engagement data you can get from Github such as Stargazers, Watchers, Forks, Issue Creators, PRs, and more.

• Package Manager Downloads: Here too, you can measure intent across multiple dimensions such as frequency of download - that is how often developers from an organization are downloading the package (someone who did a download 6 months back and never came back for a version update has lower intent than someone who repeatedly downloads the code); number of unique developers from an organization downloading the package and how actively is the open source code being used within the organization (for this, you will need some light telemetry or call home function)

• Docs, Guides and Technical Content: Docs, Usages guide are a very strong signal of developer intent. In fact, studying docs usage can be such a strong signal that we will dedicate a separate article to this. But for the scope of this article, you can measure strength of intent depending upon the type of the page (for example if the developer is reading API references, the intent is higher than reading Welcome page) and time spent on pages.

• Product Trials: Intent can be measured based on product usage metrics from a single developer (whatever you track - example # of API calls, data usage, etc.) or number of developers from the same organization trying out the product.

Since not all intent signals are equal, you might like to create a weightage chart that you can use for creating scores that will help you triangulate intent and discover which accounts are important to you

Image 1. Determining intent signals and weightage. Please see that the intent signals and weightage given above are representative and will vary from org to org

Decoding Developer and Account Identity from Intent Sources

This, in fact, is the tricky bit and is the one that takes maximum manual effort to decode data. Nevertheless, here are a few things that work:

Github:

• Developer’s Public profile data: Many developers disclose their identity in public with a link to their public profiles, their organization, and email IDs. There are in fact advanced methods of finding an email ID of a developer from Github.

• Public Data Sources: Github engagement activities at least give you a Github ID, Name, and Display pic. This tactic involves some smarter manipulation of this data along with search skills to reach a destination where you can understand the developer’s organization - such as their LinkedIn profile or company ID.

• Data Enrichment tools: There are multiple data enrichment tools (e.g. Clearbit) in the market where you can enrich user data. You generally need a starting handle for this (like an email ID, Twitter handle, LinkedIn handle, or Github ID) to get other information, but once you have it, you will get the other handles.

• Your CRM: If you ask developers to enter their Github ID and company ID as part of the sign-up process, then there is a good chance a developer actively engaging with your open source product would have signed up for your trial, webinar, community, or any other forms of developer engagement.

• A bit of everything: But with strong computing, search models, and data access. That is what we do at Reo, check us out here.

Package Manager Installs

• Creating Gateways: If you want to track which organization has the developers who are downloading your package manager, one way is to create a custom command that provides the code to the developer via a gateway that tracks the IP of the downloader. Then you can use reverse IP lookup tools such as Leadfeeder or MaxMind to learn which organization the developer works for.

• Call Home Function / Telemetry: Many OSS projects today are embedding Opt-in telemetry to understand developer usage and gather product feedback. Common data gathered by OSS projects include the IP addresses, whether the instance is active, version of the software being used, timestamps, and more. If you already have a hook on the developer (from the methods above), linking that to the telemetry data can help business teams learn which accounts are using the instance actively.

Docs

• This is relatively simple if you are already tracking first-party data on your page views. You will be able to know which user has gone through which pages on your documentation. Tools like Hubspot and many other marketing CRMs make it easier as they track a user’s first-party cookies across their website activities and link it to the identity and organization if that user has submitted such information on the form. The challenge here is to filter out which developers are actively spending time on “high purchase intent” pages or sections of the docs and technical content as compared to “low purchase intent” pages such as blogs, articles, and exploratory website visits.

Product Trials

• As above, this information can be derived from multiple product analytics tools such as Amplitude or Mixpanel that link a user’s first-party data with their product usage patterns.

Deriving Account Intelligence from OSS Data

Till now, you should get a good idea about which developers from relevant accounts are showing the medium-to-strong intent signals of OSS usage. The path ahead from here is about knowing whether an account is at the ‘nurturing stage’ where you might need to be educational and evangelism centric to guide the developers learn about the product or help them evaluate it better; or whether you have reached the ‘right time’ to get the GTM motion activated to reach out to decision-makers, get more aggressive, and use your developer champions to make the sale.

Once you have the data, you can use it to build various business strategies to reach such decisions:

Building Account Scores Based on Developer Activities: Account scoring can help you understand which accounts are cold, warm, or hot basis the developer activity. While a lot has been written on lead or account scoring (two interesting posts I recommend from Hubspot and Techtarget), you basically are associating a numerical value to intent activities and weightage to intent signals to understand which account is showing a surge (or slowdown in activities).

Mapping Account Scores with Sales Funnel Data: The GTM motion in developer tool companies is often a hybrid of bottom’s up and top-down GTM (we wrote a detailed article on this some time back on building developer-focused sales funnels). One way we recommend analyzing such data is to plot it as a matrix with top-down funnel (Prospect → Lead → Opportunity → Customer) and bottom’s up funnel (Low Account Score → High Account Score) in adjacent dimensions and plot various accounts in the quadrants. This will help you understand the true view and action items for each account.

Creating Account-Based Views with Activity Timelines: This strategy goes deep into a single account view and maps the developer activities across a timeline. There are two views you can create to analyze the data: a) ‘Velocity View,’ which gives you the graph view of the velocity of the account by mapping the account score across time. This view helps you understand in real-time when an account is hot and when things are cooling down. b) The other view, the ‘Activity View,’ maps the developer activity across time. Here you can create further qualification criteria (e.g., 1 Github activity + 1 package manager install + 5 key pages on the docs read = Qualified) to identify the accounts where you want to focus.

Mining open source data for enterprise sales can be a highly effective strategy for commercial open source businesses. By understanding which organizations are using their products, and how they are using them, these businesses can better target their sales efforts and generate more revenue. However, the process of mining data for enterprise sales is not without its challenges. It requires careful consideration of the right intent sources, decoding developer and account identities from those sources, and deriving account intelligence from open source data. By following these steps, businesses can build more effective sales strategies and drive growth.

We are building Reo.Dev to help open source companies leverage their community momentum into revenue and we would love to jam with folks who are solving the same problem for their organizations.

Talk to us now

In contrast, anybody not living under a rock can vouch for the meteoric rise that software and software first companies have seen over the same time period. Software has created hundreds of high-growth, high-margin, highly-defensible businesses. If numbers are what you believe, the global Information Technology industry was estimated to be worth $5.2 trillion in 2020!

Marc Andreessen’s 2011 prediction that “Software is eating the world” seems to have come true

How did this happen? How did software eat the world with just 2X as many software engineers today as 10 years ago?

Developers today have super powers

While the number of developers may not have grown exponentially, the powers that software developers wield today is almost supernatural. Just for ease of visualization, think about the transformation of the foot soldier from a medieval knight to modern infantry to Ironman!

Software engineers today are equipped with an enormous toolkit that helps them write insanely powerful code, insanely fast. This has created a whole industry of software tools that are sold to, purchase-influenced by, or consumed by software developers. We call this the Developer-led Landscape.

Rise of the Developer led Landscape

The number of companies/products in this space has been increasing steadily over the least three decades. Overall, the Developer-led Landscape accounts for products that generate somewhere between $49B - $95B in annual revenue and account for over $0.5 trillion in enterprise value. Additionally, this market has been growing at 22% - 28% CAGR y-o-y

While the exponentially growing demand for software has been the over arching trend, the growth of the Developer-led landscape can be mapped to three key factors:

1.      Advancements in Programming Infrastructure

2.      Innovations in Digital Technologies

3.      Transformations in Industry Dynamics

To put it mathematically, (since everyone loves a good equation):

1. Advancements in Programming Infrastructure: A major driver has been the pursuit of developer productivity and productization of repetitive coding tasks. This has led to the rise of tools that made life easier and software development faster for developers. From, higher-level programming languages (such as Python and Javascript) to Integrated Development Environments (such as Eclipse, Visual Studio and IntelliJ IDEA) to Frameworks and Libraries (such as React, Angular, and Vue.js), developers today are able to build exponentially faster than two decades ago

   

2. Innovations in Digital Technology: The second dimension that has fueled the growth of the Developer led landscape are major technological advancements in digital infrastructure: Mobile platforms, Cloud computing, API infrastructure, Big data analytics, Blockchain technology and so on

   

   2.1. The Flywheel effect

   Every major innovation in technology has led to the rise of a whole new class of developer tools aimed at helping developers adopt the technology and advance it to the next level. This phenomenon has a flywheel effect where new technologies are getting adopted significantly faster in present times, which consequently pushes the boundaries of innovation and leads to further advancement of new technologies

   For instance, the widespread adoption of API infrastructure led to the rise of API-specific tooling, making it easier and faster to build API products. As API products became ubiquitous, it led to the emergence of L2 tools that help manage API infra

   

   As Cloud computing became all pervasive, thousands of developers tools emerged to help build and manage apps on the Cloud

   

3. Transformations in Industry Dynamics: Today major businesses and industries are being run on software and delivered as online services. Entrepreneurial, technology first companies are challenging incumbents for their role in defining the future. At the epicenter of this revolution are developers and developer tools

   This has given rise to a whole class of verticalized developer tools and APIs that are tapping into industry specific opportunities and solving industry specific problems

Future outlook

The developer tool landscape is only going to get busier and more complex! As new technologies continue to emerge, it will bring waves of tools that help developers adopt those technologies and innovate. Here are 5 trends that we believe will lead to future waves of developer tooling:

1. Artificial Intelligence and Machine Learning (AI, ML)

2. Augmented and Virtual Reality (AR, VR)

3. Blockchain technology (web3)

4. Internet of Things (IOT)

5. Quantum computing

The world is yet to realize the full potential of these technologies. Wide spread developer adoption and open innovation is the only way ahead, if we are to mine these technologies to the fullest. And for that to happen, a wave of developer tooling will be required that makes it easier for anyone to start building using these technologies

Another, major trend that has already taken root and will only amplify going forward is the emergence of specialized and super-specialized domains within software development. To help this sink in, consider the following Developer Roles that did not exist as recently as ten years ago:

1. Cloud Architect

2. DevOps Engineer

3. DevSecOps

4. Data Engineer

5. ML Ops Engineer

As new technologies emerge, the role of the developer will continue to become more specialized and complex, and the toolkit has to keep pace.

Source credits:

• https://evansdata.com/press/viewRelease.php?pressID=182

• https://www.developernation.net/developer-reports/de20

• https://www.future-processing.com/blog/how-many-developers-are-there-in-the-world-in-2019/

• https://github.com/TylerJewell/DevLandscape/blob/master/README.md#test-automation-26b-us-vs-126b-analysts

• “The Developer-Led Landscape” by Tyler Jewell

• https://www.comptia.org/content/research/it-industry-trends-analysis

This is because you will have a bottom’s up developer focused GTM motion, often driven by your devrel or marketing teams and a traditional top down sales led motion and these 2 funnels often end up looking very different. And like most of the developer tool companies, if your GTM motion is going to be a hybrid one, i.e. a mix of a top down and bottom’s up motion - you will need a single view of the account pipeline.

Hybrid GTM Motions

Your bottom’s up developer focused motion will have developers finding out about your product either organically, inorganically or through communities (Discover); learn about the product by going through docs or try out the product by playing around the free version or the open source community version (Evaluate); build certain prototypes or POCs to see the usability of the product (Build) and then you can use this organic growth opportunity to monetise the account with better upsale offering (Scale).

Source: The Developer Journey Map and Openview’s Dev Focused GTM playbook

Your top down sales led motion will have your quota driven SDRs and AEs reaching out to decision makers (generally mid to senior folks with budgets) , qualifying and converting them into customer. This will be your traditional conversational pipeline where you have a potential customer who is not showing an interest in you yet (Prospect), someone who is showing interest in you (Lead), somewhere you see a fitment of need and budget (Opportunity) and finally somebody who agrees to sign your dotted line (Customer)

The Traditional B2B SaaS Sales Funnel

Building a Single Organization Revenue View

If, like me, you are crazy about data and about aligning the sales and marketing organisation across a single pipeline; you will like to interpret this hybrid motion in a single framework.

I have seen many organisations using the bottom’s up GTM motion to identify a Product Qualified Lead or Account (PQL or PQA) and use that to fill up the Opportunity bucket in their pipelines. This method works well if you are selling a B2B software but if it is a developer software, this methods ends up being inefficient. A qualified account in a developer software company will have a lot of developer activity and business teams would like to measure that to build account based strategies. For example, AEs (account executives) will like to know if there is a developer activity in their qualified accounts to learn whether the account is alive, since no developer software is purchased without developers in the team trying out the product or against their recommendations.

PLG funnel when used in Developer focused growth

Similarly, this model rules out the importance of intra team collaboration that is needed to close developer tool deals at scale. If you are not measuring developer activity at the qualified and high probability accounts, you can potentially overlook risks of the pitch failing in developer adoption within the org. But measuring it will ensure your Dev Relations team can highlight potential support questions from advanced pipeline accounts in communities, your marketing teams can create specialised nurture and educational campaigns, your sales engineering teams can study product usage patterns to understand risks and help out the more important user.

Using a two dimensional matrix view for hybrid pipelines

I will like to propose here that a better way to look at this hybrid pipeline is in a two dimensional matrix structure rather than a linear funnel view. It will help business teams derive better business strategies.

Once you plot your accounts across their top down conversational activities with the sales teams and developer activity based on bottom’s up adoption, you will start getting the full picture of your Go To Market efforts. Different teams can have different strategy views from such a matrix.

For example, Marketing teams can look at high developer activity accounts and run targeted campaigns to tech decision makers (CTOs, CPOs, Head of Engineering) within the organization. They can segment developers across quadrants to run specific nurture campaigns. DevRel Teams can identify power users amongst accounts in the bottom of the sales funnel and use them as evangelists in advocacy within the account. Similarly, they can identify accounts towards the bottom of sales funnel with low developer activity and run targeted efforts in activating them and seeing that the product gets the required bottom’s up activation.

Similarly AEs and CSMs can design account strategies based on the matrix. They can understand better which are their ‘star’ accounts that might be open to buy more, which opportunities are ready to get converted and identify risks in accounts that are at the bottom of the sales funnel but not getting the required developer adoption within the account.

Pipeline are often created to study clog and imbalances. If you plot all your accounts on this matrix, by studying the density, the RevOps / strategy teams can decode the imbalance and the reasons behind it. For example a higher density of accounts towards the X-axis below might mean a low adoption of the company’s developer driven motion which might be a gap in adoption or an un-optimised developer experience.

Note: The top down funnel will typically reside in your sales CRM. The bottom’s up pipeline might be tougher to get as the data will reside in multiple systems - your product database, our support community, developers going through your docs and others sources. But we are building something here to help developer focused companies see their true account pipeline.

Check Out Reo.Dev

I used to see developers from potential customers asking questions on our discord support community, installing our SDK that we had put on github, using our sandbox, studying our docs, trying out our APIs in Postman collections and this I felt was my true pipeline. Even the C-level executives we spoke to or demoed our products delegated their product evaluation to 1-2 developers in their team and then these 2 developers were as important as the executive to us. But we could never get a complete picture of their product usage as these developers, being in their very nature, did not want to be disturbed by our calls, mails and tell us where they are in the purchase journey.

That is when I discovered that every GTM leader who is trying to sell developer tools is grappling with the same challenge - how to monetise from a developer led motion.

Developer Will Be the New Buyer of the Next Trillion Dollar Software Wave

Think of the last pizza you ate, the car you drove, your last financial transaction. Every industry leader from food (think Domino’s), automobile (think Tesla), retail (think Nike) to banking is transforming into a massive technologies company with a massive need of software to enable developers to build applications quickly. In fact every new technology wave, leads to a following wave of hundreds of Developer Tool companies helping developers to adopt that technology quicker (For example, rise of Fintech led to growth of Fintech Infra; same happened with growth of Web 3 and now Generative AI tools).

There is no doubt that in the coming years we will see many more Developer Tool companies. In fact GGV Capital predicts developer driven software to be the next trillion dollar market after SaaS and Cloud

Source

But the more interesting trend that we see is that the developer is the buyer for this next wave of software. It is an increasing trend in any modern organisation that the decision makers are delegating software purchase decisions to the developers. Developers today are not just creators, but are also massively empowered to either decide or strongly influence purchase decision of software that solves their problems.

A recent survey by Stackoverflow showed 66% of professional developers have at least some influence over their organization’s purchases of new technologies. This is up from 56% in 2020. BCG’s 2022 report shows growing influence of developers in enterprise tech sales. The report shows that Dev team is creating demand for software, shortlisting vendors, testing out the software and even taking the final decision of purchase. This trend is highest in cloud native enterprises but also emerging in companies in early stages of cloud adoption.

But Developer’s Buying journey is Unique and Often Hidden

Developers are informed buyers. They are averse to typical marketing tactics like ads, sales calls, nurture mailers or any other forms of rosy promotional marketing.

A typical developer’s purchase journey starts with a problem that they want to solve. And if they don’t want to solve it by building it themselves, they either research the solution or take the help of people they trust to guide them. Their journeys are very self research driven with intent signals within and outside the product ecosystem that they are trying to evaluate; and involves learning, evaluating and building things before they take their final call.

A lot can be said to describe a developer’s purchase journey, however this map puts it out very accurately.

As you will see, this journey is very different from a typical SaaS purchase journey.

In fact this journey is different from a typical PLG journey as here it is more than ‘try before you buy’ to ‘build before you buy’. For developers, much of the product is outside a sign up, in the docs, guide, sandboxes and open source.

Decoding Developer Led Motion Will Change the Game for Businesses Selling to Developers.

Developers have become one of the most, if not the most, important buyer of developer tools that are building the internet. But when we spoke to dozens of sales and marketing leaders in the developer tool industry, the pain of linking this developer led motion to revenue was visible. We are breaking it down to some of the common problem:

• No knowledge of the true revenue pipeline: Today revenue leaders in DevTool businesses lack one view of the deal pipeline. This is because they have developer’s intent signals are across multiple sources, many of them are incognito and to add to it, they are trying to marry their conversational top down deal pipeline to this bottom’s up motion.

  We spoke to CEOs and CROs who told us that every morning they try to make sense of their deal pipeline with intent signals across multiple channels such as their slack/ discord servers, their docs, sandboxes and more. We realised that many DevTool businesses have had to build their own custom internal product to solve this since no one solution solved this problem for them.

• Monetising their 100s of thousands of their Open Source users: Many DevTool leaders took up a Commercial Open Source strategy to democratise access of their product and bring in massive bottom’s up motion. But now they want tools to help them monetise this motion with their open-core or cloud products.

  Many revenue leaders told us that they regularly meet people in developer conferences from potential customer organization who tell them that they have been using their OSS version for a long time. They feel if they had this knowledge they could have tried to nudge them to a paid version that could actually have helped the customer.

• Linking their developer community to revenue: Many marketing and revenue leaders in DevTool companies have invested a lot in their developer communities. Now they want to monetise it. Their current set of community management tools help them learn who is engaging in their communities but does not help them convert this knowledge to revenue.

• Bottom’s up Dev motion is noisy and lacks signals: Revenue leaders feel their sales and marketing teams are overwhelmed by the noise of thousands of developers signing up, logging into community every month. SDRs are thus wasting time in the wrong inbound leads and growth teams are spending advertising budgets on accounts that will probably not buy.

And this brings us to the mission of helping businesses link their developer led motion to revenue. We feel the way Gong built a successful businesses deriving revenue intelligence from thousands of agent sales calls and emails in a Sales Led Motion; or the way 6Sense built a successful business deriving revenue intelligence from thousands of content based intent sources in a Marketing Led Motion; we will be able to do the same for a Developer Led Motion.

PS: Gaurav, Piyush and I are building Reo.Dev. If you want to try out the product or this is a pain that resonates with you, write to me at achintya@reo.dev.

In this blog, we will explore the best resources for developing a successful developer sales and marketing strategy.

Developer Markepear

Developer Markepear by Jakub Czakon is a blog that provides in-depth insights into what developers want from marketing efforts. The blog covers a wide range of topics like:

• Ultimate guide to developer marketing

• 25 developer marketing tools

The blog's extensive coverage makes it an excellent resource for anyone looking to develop a successful developer marketing and sales strategy.

OpenView Partner's Blog

The OpenView Partner's Blog is in general a great resource. Especially on developer marketing one of the standout articles is the Ultimate List of Developer-Focused Sales and Marketing Resources, which aggregates some of the best articles on developer marketing.

The blog is a great starting point for anyone looking to get started in developer marketing.

BVP Atlas

This blog by Bessemer Venture Partners has a wide range of resources that provide in-depth insights about developer focused GTM. Some of the standout articles focused on developer marketing include:

• Eight Laws of Developer Platforms- a classic must-read for understanding developers.

• Measuring the engagement of an open source software community

• How Developer Platforms can Triumph over three most common PLG roadblock

The Heavybit Library

The Heavybit Library is an essential resource for anyone looking to learn about developer marketing and sales. Some of the standout articles are:

• Connecting community to commercial success

• Our community loves our free product, now what

The platform provides valuable content from operators who share their hands-on experience in developer relations, developer marketing, and sales.

Developer Marketing Alliance

The Developer Marketing Alliance is a dedicated community that’s specific to developer marketing. The community offers a wide range of resources, including:

• Alliance Developer Marketing Community - A Slack channel, where you can connect with like-minded professionals.

• The videos covering their Developer Marketing Summit, which provide a lot of valuable insights.

• The State of Developer Marketing Report, which provides insightful data on the state of developer marketing.

The Developer Marketing Alliance helps you to drill into the tactics and mindset required to effectively market to the developers.

50 Lessons on Developer Marketing - Nick Moore

This twitter thread by Nick Moore provides 50 extremely valuable tips and tricks covering the right way to market to the developers.

IronHorse

IronHorse’s blogs offer valuable insights into what developer marketing is and what it’s not! Some of the best blogs address questions like: What is B2D marketing? How to build a thriving developer community? And, what some of the large companies are missing out about developer focused marketing?

Conclusion

Developing a successful developer marketing and sales strategy requires a unique approach that is tailored to the audience. While one size does not fit all, the resources mentioned in this blog do provide valuable insights and a great starting point to develop your own Developer Focused GTM motion.

PS: This is not an exhaustive list and we are sure we missed out some great resources. Please feel free to write to us at connect@reo.dev

Subscribe now