I recently came across a super interesting article by Achintya Gupta and Piyush Agarwal from Reo.dev about modern dev tool GTM practices. Check out their original content here via this link.
My main takeaways:
“Old” GTM processes don’t work for developer-focused businesses because:
All the teams are working independently in their own silos the developer champions (devrel teams), who are actually central to the transaction, lack an official method to assist in sales. Meanwhile, marketing teams are treating both the user and the buyer the same, even though they are distinct personas, and are frustrated that they are targeting developers who aren't interested in buying. BDRs are also struggling and feel like they are blindly reaching out to an audience that doesn't want to engage with them.
The prospect's willingness to engage with the Sales team is largely dependent on whether they have reached the point where they are prepared to buy. This typically means that developers have evaluated the product and recommended it to the buyers. Account Executives who stick to the old BANT (budget, authority, need, and time) framework risk focusing on the wrong deals or overlooking the right ones if they ignore this crucial step in the purchasing process, where management will seldom go against the developers' recommendations.
Modern GTM process for Developer-Led Sales
Recognition of two distinct personas in purchasing process: a Developer and a Buyer. Developers want to explore solutions on their own but value timely support and appreciate assistance from engineers when needed. The Buyer (CTO, CXO, VP Engineering, or VP Product) has access to budgets and is more receptive to a discovery call or a sales/marketing conversation. However, they will not make a purchase against their team's recommendation. In fact, any sales efforts aimed at buyers are likely to be passed on to the developers for trials and proof of concepts (POCs) for qualification.
Developers don’t want to be ‘sold’, so sales & marketing departments have to adapt: a hybrid GTM process that combines bottom-up with top-down. The Developer needs a bottom’s up activation which is educational, product-led, and community-led. While the Buyer will need more top-down support for a commercial function such as sales, especially for larger ticket sizes.
Collaboration & Coordination between Product, DevRel & Growth teams: Product teams require continuous feedback to enhance the developer experience during trials or proof of concepts (POCs), but such information is typically held by the DevRel team that manages communities. To encourage developers to either engage with support or opt for a paid version, the product team must implement growth triggers within the product. Additionally, the growth teams must identify and communicate to the sales team which accounts among the hundreds of leads and signups genuinely intend to pursue the product.
Stages of Modern GTM for Developer-Led Sales
Stage 0: Organization has a technical need
Stage 1: Developers search solutions for the technical need of the organisation
personal network, search the internet, read technical content about it, or ask within developer communities or forums
Stage 2: Developers start trying out solutions
Developers will be forking your github repos, trying out open source code or free trials
Success comes down to how optimized the product trial is in helping the developer get to ‘hello world’ or early success (I like the term ‘time to dopamine)
Stage 3a: Developers start building stuff with your product | Stage 3b: Early signals of Buyers getting involved
If you get there, you will see more pointed queries on your developer support channels
The right time to “get in” for sales teams, having developer-intent signals increases the likelihood for buyers to hop on a call (by then they are usually aware of their teams testing out your tool)
Stage 4a: Developer qualifies the solution | Stage 4b: Buyer builds a business case around the product
your free product, open source product or freemium product version gets a ‘good to go from developers’
either leave it for the dev to organically move up your PLG funnel or you push with the Buyer and build a business case with them; buyer interest will be at its maxima at this time
Stage 5: Buyer engaged in advanced sales and commercial conversation
Stage 6: Developers and Buyers experience success and evangelize the product within their networks
Cracking the Modern GTM for Developer-Led Sales
Think Account First; Lead Second
Triangulate developer intent signals and identify the accounts with opportunities (proximity to your ICP + signal strength), then approach the right persona within the Account
Understand who is a buyer and who is a user from your lead database
Differentiate a Buyer from a User / Developer, signals:
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
Setup a Developer Database to Nurture Developers from aspirational accounts
Traditional GTM strategies like retargeting, email follow-ups, or discovery call requests may be suitable for Buyers. However, the approach for Developers must be entirely different. It must focus on educating them, assisting them in finding solutions quickly and providing the support they need. This fundamental difference requires a complete alteration in the messaging they receive, the content used to nurture them, and the individuals who interact with them when they seek support.
Establishing this database will assist the DevRel and Support Engineers in prioritizing developers from significant accounts. The insights or triggers of Developer Activity in the CRM wouldn't prompt you to reach out to the developer for selling, but rather to prioritize the accounts and buyers within those accounts appropriately.
Analyse and Strategise Account Entry based on Accounts with Relevant Developer Activity
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 collaborative cross-functional approach is required, with a program owner and shared visibility of program data across all participating teams, to ensure everyone is aligned with the ultimate goal. Without a product-led bottom-up approach, a Developer won't be persuaded to recommend a product, and without a DevRel function, they won't receive the necessary support to achieve quick wins with the product. Similarly, the marketing function plays a key role in drawing both Developers and Buyers into the sales funnel, while the Sales function carries the process through to the final stages, ensuring the closing of deals, finally.