The 2 Things to Attract Developers to Your Product, or Marketing to Developers
Bottom-up go-to-market approaches are becoming a needed strategy for attracting developers to your product. This post explores marketing to developers and the types of 1) content and 2) distribution to attract this buyer cohort.
Cracking the code (no pun intended, well, maybe…) on how to attract more engagement and business with developers and engineers can be a challenging transition to make from traditional B2B SaaS methods. Since every business is becoming a software business this cohort has become a critical buying profile in recent years; especially given the increased focus in bottom-up product growth strategies. However, traditional b2b and SaaS marketing and sales motions don’t translate to results with a developer cohort.
Meet the developer cohort; a Client-Server hello :)
Through this post I’ll use the term ‘developer’ as a broad label for this cohort — the people in an organization that matter the most for bottom-up adoption of tools and services. Their jobs are to keep the infrastructure and applications that provide a company’s product or service, running. This can include engineers (software, network, test, etc.), architects, security operations, developers, SRE, DevOps and more. Their day-to-day involves fingers on the keyboard work and are intimately involved in the code that makes up network and application communications, and technologies that keep businesses running by creating solutions, optimizing transactions, defending the service and troubleshooting issues with the software and technologies. For your pursuit you may want to further segment within the category of ‘developer’ for more granular messaging and approaches as there will be differences in problems that different subsets of Developers have to deal with- more on this in the Persona Identification section below. This Developer cohort is at the core — or epicenter — of any digitally enabled business today.
A shift in marketing and sales motions; top-down & bottom-up methods
B2b SaaS or Enterprise sales traditionally focused on a tops-down marketing and sales motion. That is, target an executive buyer persona or team and produce relevant content in the form of thought leadership, white papers, webinars, sessions at events/cons — that addressed the corporate or business unit pain points in conjunction with sales conversations. The goal was to gain interest through registering (lead form) for one of those items then pursue the ‘lead’ to schedule a demo and move the prospect organization and their buying team down the funnel, if the solution could meet the clients’ needs and address their problem. (or in an ABM strategy identify your buyer and influencer personas and target them for engagement with ads, one-to-one outreach, messaging, etc.)
During this process, the client team may have a tiger team or evaluation team that included a member or two from the departments that would be affected by the purchase and forced to adopt the product- IT, finance, engineering, operations — so their concerns and needs are considered in this evaluation/sales process. Assuming there is a fit, the vendor product or software is procured, deployed to the client, training and on-boarding provided and customer feedback taken in through course of the relationship.
Given the critical role of Developers it becomes increasingly clear why this cohort isn’t as responsive, nor have the time for, the traditional b2b marketing and sales process described here. That’s not to say sales processes don’t work at all, but that’s a topic for a different post, and addressed with successful results here and here.
Now, as software and applications are the driving force in a company’s value proposition, many of the developers prefer to seek helpful and relevant recommendations and feedback from peers or communities on software and tools that may suit their needs/use cases. This opens the new approach to provide more technical based content through documentation, trials, code samples and encourages organizations to build more technical relationships by providing those types of options. There is an increase in developer relations (DevRel/Community) and developer marketing to help meet the needs of this cohort. However, it should be noted this cohort does not like “marketing” — they don’t want fluff, a process or calendar scheduling, but want to get straight to the point of their issue and don’t want the sequence of ‘being marketed to’ when they’re simply doing research for a service that doesn’t meet their use case or need. The developer persona is already exposed to access to documentation, tool trials, etc., based on experiences with free and open source software (FOSS) and tools where they are rarely required to fill out forms to get gated content (a traditional lead generation framework), but trial a product and interact with solution architects or customer success on the back-end of this behavior for license or capability expansion. As Sara Varni CMO of Twilio says — “Rule number one in marketing to developers, is ‘Don’t market to developers’.”
As ‘fingers on keyboards’ practitioners that keep the business running, developers are dealing with problems in-the-minute and therefore eschew traditional marketing and sales processes. As previously stated, they prefer to reach out to their colleagues or friends on the topic, communities, seek word-of-mouth recommendations or explore existing ‘community’ topics on the issue. In the search for a solution, developers want to get exposed to the applicable product or tool ASAP. This can be quickly done by companies providing a self-service method — free trial/demo, SDK, GitHub repo with samples, and technical documentation — that can be coupled with a low-cost per license trial model to best determine if a tool or software will integrate and solve the problem they are dealing with. The experience provided by free and open source software (FOSS) and tools has helped these preferences- getting access to a solution with minimal friction or sales process. Because of their day-to-day role combined with the ability to engage with new products/services through a repo, free trial or low cost trial version that doesn’t require budgetary approval- this makes developers the key buyer and top-priority influencer for tooling and software purchases in this bottom-up approach.
The bottom-up model is proving to be an accelerated method of adoption and sales as discussed and presented here (see case studies section). Businesses pursuing this model offer free and low license SaaS monthly fees to gain adoption within an organization, since these price points, most likely, do not require some sort of budgetary authority to procure them. Free trials and low-cost license/SaaS fees really alleviate the pain point of sunk costs for a solution that doesn’t work, only requiring the time of an engineer or developer and potential compute/instance/ingress fees for their evaluation. You can begin to understand how a bottom-up SaaS offering marketed to developers, demonstrates great value for all involved; enabling a discovery process and purchase decision without having to interact in a traditional purchase funnel process. If the trial works out, the product can be formally procured, scaled to fit the organization, and grow within the new client organization.
What types of content are developers engaging with?
Here is a look at what I’ve encountered as preferred content, or ways to interact with content, from a tops-down and bottom-up view (caveat: this isn’t exhaustive and I’m sure there are many other components that can be added): Any business pursuing a developer audience should do an inventory of their current content assets to see what gaps there are in content offers.
Steps you can take to begin marketing to developers
The most important facet here is to understand who you want to market to and where they can interact with your content.
Persona identification / ICP
I mentioned I grouped a few titles together and collectively refer to them as “developers”. If you’re in a similar situation, you’ll want to identify the types of developers that your product is meant for, maybe you only want site reliability engineers or software developers, build out a deep profile that allows you to really understand what they do. What are the use cases your product/service addresses that are relevant to that persona? What are their pain points, problems, or obstacles? What is their day-to-day like? You can see my broad example here:
Database segmentation
If you have a list, a database of prospects with multiple persona types you’ll want to go and assign their persona so that you can develop segmented messaging for your campaigns. Sometimes you may not have a message for a certain segment and it’s okay to use them as a suppression list from your marketing outreach. You can then start to measure typical database marketing KPIs based on the segment which will help illustrate what works and doesn’t work with various cohort audiences.
Publish — Email / Post
Map out your content publishing calendar with a newsletter or email cadence to consistently reach your contacts to let them know about the latest assets and their message. This can be multi-pronged distribution as you publish a newsletter to your list, post to your social media sites (Twitter, LinkedIn, YouTube) and integrate it in any community posts or discussions you have (Slack, Reddit, Hacker news, Discord).
Publish what your product does but in a manner that portrays it as a solution to the use case or specific problem that the developer is facing; and you may have many of these. I’ve found that code snippets, screenshots are very helpful in the messaging to begin to integrate the product and how it is helping in that moment of the problem discussion. One popular tactic is to compare your solution to how developers might solve it without your solution (or are currently solving the issue)…this conveys that the method is more than they should do or what they want to do; think of it as the equivalent of a “messaging cost calculator.” Ask for comments, questions and offer a technical brown bag virtual webinar/demo to better illustrate that use case solution as the next step in seeking engagement from the audience. IF you’re in the position to leverage an existing client to share their experience for this use case, this will greatly advance the validation of your product as the solution or product to use.
KPIs / Success Metrics — revenue related vs. community related
This post is more focused on the development of new business with developers. There is a whole different metric set for developer relations that manage community or product with an existing client base.
Other traditional metrics (email opens, blog reads, etc.) are not a priority to the interaction metrics below. Traditional metrics are good for diagnosing decreases in sales or triangulating what messaging works to grow developer trials and adoption.
In talking with a few folks on the development side, their top metric is either downloads or free trials- depending on their model and then progressing the growth from that starting point. (For new business/users). Others also incorporate a metric around engagement or questions as part of the process.
If you’ve stayed with me through this post, I’d love to hear your thoughts or how you’re approaching developers. I’m eager to hear other experiences and ideas.
This post originated as a place to document my lessons learned with marketing to developers and provide other helpful resources for those learning more about developer marketing, DevRel and bottom-up SaaS approaches. I may update this post as time goes on to better reflect new understandings with this important audience.
Explore these other great posts I’ve come across that describe similar experiences and their results:
https://shimont.medium.com/switching-top-down-sales-to-bottom-up-product-led-growth-30be52f7dba7
