Modern GTM - Introduction

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; atleast till they have experienced the product themselves
• It prescribes creating steps and action items specifically for 2personas - the User (someone who will try your product but will not havethe budgets and authority to purchase it) and the Buyer (someone whowill listen to and be heavily influenced by the User, might only partially trythe product themselves, but will have the budgets and authority to purchase theproduct)
• Also, organizations need tohave Hybrid GTM processes, a mix of Bottom’s up and Top Down; where theUser will need content, education and a strong self serve motion driven bymarketing and product teams (Bottom’s Up); while the Top Down sales team drivenprocesses 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.