📚GTM basics
Do you have any questions, need personalized guidance, or want to share your journey in this playbook? We'd love to talk to you. Reach out to us.
The evolution of GTM:
The 90s were the days of Sales-led growth, traditional sales approaches were characterized by face-to-face interactions between sales reps and CIOs.
Furthermore, the introduction of trial versions revolutionized the sales process. This enabled companies to target departments initially, allowing for easier adoption before scaling up to larger enterprises. This approach eliminated the need to involve high-level IT executives right from the start, streamlining the sales process significantly.
In the next couple decades, Marketing-led growth took the lead when companies could purchase keywords and utilize other forms of online advertising, companies could effectively target their desired audience with greater precision.
Today, a new market dynamic has emerged, centered around the concept of true self-service driven by the product. The buyer is the end user. This approach begins with individual adoption, gradually expanding to team usage through online self-service channels. Eventually, the sales strategy extends to cater to the needs of larger enterprises, completing the evolution of the go-to-market motion.Now that you know the history of software sales, it's important that you also understand the 3 fundamental business models important for this playbook:
Difference between B2B, B2C, B2D:
B2B (Business-to-Business): B2B refers to transactions and relationships between businesses, where one business sells products or services to another business. In this model, the customers are typically other businesses, and the products or services sold are often used in the production of goods and services for end consumers.
B2C (Business-to-Consumer): B2C involves transactions and interactions between a business and individual consumers. In this model, businesses sell products or services directly to end consumers for their personal use or consumption.
B2D (Business-to-Developer): B2D is a relatively newer concept that focuses on businesses providing products, services, or platforms specifically designed for developers. In this model, businesses cater to the needs of developers, offering tools, APIs, SDKs, or platforms that developers can use to build applications, software, or integrate functionalities into their projects.
B2D differs in that you are not selling to the ultimate end user of the product. You are marketing to a developer who will take your product to create or enhance something that they will then sell to their end user. Here, the main marketing push is to developers first, in a bottom-up approach. Additionally, because there might be complexity involved in adopting new technology, the B2D approach requires significant investment in educating prospective users on how to use the technology and inspiring them with suggestions on how they might apply it. Here, learning resources like blogs, case studies, and even tweets can all serve to inspire developers and show what’s possible with your product. However, these must be backed by resources like technical documentation and code samples which provide instructions on which bricks to use and how they snap together, crucial to enabling developers to embellish your basic blueprints.
The sales cycle can be fast – typically via your self-service developer hub – or longer if you are selling to larger companies in combination with your sales team.
GTM Channels matrix:
Here's a list of major GTM channels with their definition, context, and market.
Outbound
Initiating contact with prospective buyers (team leads, engineering managers) through calls, emails, LinkedIn messages, or other direct means without prior interest expressed. Recommended for infrastructure tools with potential company-wide adoption.
Suitable for developer tools with potentially high Average Contract Value (ACV) and Lifetime Value (LTV), supporting a higher Customer Acquisition Cost (CAC). Targeting large enterprises, emphasizing unique value propositions to specific engineering teams within organizations.
ROI-focused content enhances effectiveness; consider exploring lower CAC options initially, scalable once optimized.
ABM/ABS
Collaborative effort between Marketing and Sales to raise awareness and interest in developer accounts (logos) across various channels, including outbound tactics. Focuses on addressing multiple constituents and cross-organizational value propositions.
Same as Outbound, emphasizing the need for addressing multiple constituents and cross-organizational value propositions. Many constituents in the Decision Making Unit (DMU) within large enterprises.
Sales and marketing teams often organized around buyer segments rather than function.
Inbound
Creating developer-focused content (blogs, podcasts, webinars) to attract prospective customers to the developer tool business.
Lower ACV or LTV required, suitable for categories with less content saturation and products requiring evangelism or business process transformation. SMBs or Mid-Market with many potential buyers conducting research online.
Takes time to yield results but operates as a sustainable flywheel; good for initial testing of messaging and Ideal Customer Profile (ICP).
Paid
Utilizing paid ads on search engines, social media, or compensating influencers/affiliates to direct developer traffic to the website.
Simple to message value proposition, suitable for new categories with low paid competition. Tight, targeted buyer segments active in search and social.
Good for initial testing of messaging and ICP but difficult to scale efficiently; susceptible to competition outbidding.
PLG
Allowing developers to experience value from the product without human interaction, fostering viral potential and easy bundling with other products.
Low time and effort to retainable value, simple to message value proposition, single-player mode, and viral potential. Tech-savvy developers in a large, horizontal market primarily driven by end-user value.
PLG as a sustainable moat; early focus increases the likelihood of product-market fit; challenging to implement after scale.
Partners
Selling developer tools through channel partners, who generate demand, sell, and service the customer post-sale.
Easily bundled with other products, significant customization work required. Developers already buying through partners, with partners adding significant value beyond the end customer.
Most underestimate the time and cost to enable a partner; requires a tested direct playbook before enabling partners; offers scale leverage.
OpenSource
Leveraging open-source projects to build developer communities and drive adoption of related developer tools. I would say it's an extension of PLG.
Well-suited for developer tools with the potential for community-driven contributions and widespread adoption. Developers engaged in open-source projects.
Requires active community management; fosters a strong developer ecosystem around the product.
For Developer tools, it's also important to understand The developer journey map - It’s one of the most valuable tools in Developer Relations as it helps you think holistically about the experience from the developers’ perspective as they move left to right across the stages, their level of interaction increases with your brand, team, and product.
The Developer journey map
Your Developer Journey is one of the most important documents you will create.
It is like a roadmap that guides you through how developers interact with your company. It helps you understand where they are and where they need to go.
The main goal is to keep improving and making it easier for developers to move through different stages.
You should constantly refine the goals and key questions you need to answer, to move the developer along the journey through the stages. The majority of Developer Programs will only start to produce meaningful revenue when the Developer makes it to (and stays in) the Scaling stage.
You can also use your journey to inform improvements required in your Developer Experience and go-to-market execution. It is a living document and should be revisited with every major release or change in your offering to identify stumbling blocks to move the Developer from discovery through to scaling as quickly and efficiently as possible.
Additional resources:
Last updated
Was this helpful?