How to sell to developers (tldr: you don’t, sell to their boss)

So I’ll start heavy, you don’t sell to developers, not directly. 

They don’t want ROI discussions or pricing negotiations with an account executive. 

They want to solve their current (tech) problem with your dev tool. 
They want to see that they actually can use it in their work setup.

My take is that you market to developers
and you sell to their boss (or their boss's boss). 

Ideally, after there is adoption and buy-in from the end-users, the developers. 

But if selling to developers is about not selling to them then how do you actually do it?

Well, there are a few tried and tested go-to-market motions that work for dev tool companies:

• open-source like MongoDB
• product-led-growth like Snyk
• inbound like DigitalOcean
• account-based-marketing like Snowflake

There are also, partner, paid, and other options. In this post, I’ll explore all of that. 

And while I like to think I know a thing or two about marketing to devs, I consider myself very much a first-year student of dev-focused go-to-market motions still. 

This article is primarily a learning journey for me. Hopefully, you’ll learn something with me. 

We'll talk about:

• Why not sell to developers
• Marketing vs selling to developers
• How to sell developer tools 
• Dev tool go-to-market motions
• Pricing, packaging, and designing a free plan
• Outreach in dev-focused GTMs
• Product-led sales for dev tools
• Selling open-source software

Also, let me know where you disagree or have thoughts or resources on the subject. 

Ok, let’s start at the beginning. 

Why not sell to developers

“But why not just sell to a single dev? You have JetBrains IDE, for example.”

Yes, you do. But you also have hundreds on hundreds of dev tool startups that failed miserably at monetizing. 

A recent big public failure was Kite (AI tool for code writing) with 500k + monthly active users. They wrote an amazing retro which was later discussed on Hacker News.

The most important takeaway from it was this: 

“Our diagnosis is that individual developers do not pay for tools.“

In theory, devs could pay for tools and some small percentage of devs actually do. 

Some are building their own thing over the weekend and they will happily pay for infra and tools then. But those fall more into this prosumer bucket or it is their hobby. 

But at work, devs don’t pay for tools themselves. 

They may use open-source, or they may build some small hacky over-the-weekend solution, or they may just use that JetBrains IDE for work without a license. 

The point is this. Individual contributor devs are not the best market to go after. 

Or let me put it this way. You should market to devs, get them to experience your value prop, to adopt your product. But you shouldn’t go after them when it comes to sales. 

That said, throughout this article, I will talk about “selling to developers” meaning a go-to-market motion that sells products whose end users are devs. 

One more thing before we start. 

Marketing vs selling to developers

I know some folks (especially tech founders) see it almost the same. For me, there is a difference, and it is important. I see it this way:

Marketing to devs is about making people aware of your dev tool, and the market category, reaching out to devs in their channels, sharing your story in the community. It is about converting them to free trials or downloads of your library. It is about figuring out the strategy for positioning and messaging, branding, design. It is about enabling sales motions to close more deals. 

Selling to devs is about closing deals. Converting free users to paid, converting leads, teams having a problem you solve, to paying customers. 

Those overlap with lifecycle marketing, webinars, activation, upgrade sequences etc.

That means things can get blurry:

• If you are running a product-led-growth self-served motion marketing is mostly closing the sales as well (at least before you want to sell to bigger enterprise orgs when sales will be needed again). 
• Or if you are running a pure outbound, then salespeople are actually educating buyers about the problem and solutions, about your brand. They are doing the job of marketing. 

Ok, now, what do you need to do to sell dev tools?

How to sell developer tools 

To sell dev tools effectively, you need more than bottom-up adoption. You need a strategy for delivering and extracting value at the team and at the enterprise level.

I liked how someone phrased it in this Hacker News thread.

“Bottom-up really requires the “and up” part:

- each pricing plan targets an org scale
‍- and the features address those problems

‍That’s why websites tend to go from selling you on individual features (5 servers a month!) to team features (10 headcount!) to organization features (auto-invoice! SAML!). 

‍Your entry point is the bottom user (5 server home IOT), who convinces a manager (our team needs this!), who convinces a director (we can solve this org issue!).”

So the path to money is: 

Individual (no money)-> Team (some money)-> Organization (big money). 

The way I see it, you need to:

• Get people to know about it (problem, solution, brand)
• Get people to try it (ideally for free)
• Get people to use it (ideally at work)
• Get people to pay for it (ideally other people) 

The packaging you choose is crucial here and needs to work together with your GTM motion. 

For example, say you have a big blog that gets 1M+ front-end devs to your site monthly. But your pricing page says “contact sales” followed by a classic top-down enterprise outbound sales motion. 

You are missing out big time on devs who would have tried and potentially used a free version of your tool before any commercial discussions started. They would have tried the free, self-served inbound experience. And some percentage of those would enter sales conversations in the future.  

Overall, I strongly believe you need to have a free option when selling to devs. Some of the dev tool GTM leaders I highly respect share this view. Adam Frankl wrote about it, and Adam Gross spoke about it. 

Basically, you need:

• Free plan: so that individual devs can use it (no buyer)
• Team plan: so that you can get some value at the team level (typical buyer is a team lead) 
• Enterprise plan: so that you can sell value at an organizational level (typical buyer is a VP-eng, compliance etc)

Whether that is with open-source or PLG models doesn’t matter. But if you don’t have a free experience devs can use before their team buys the product you are missing out. 

Also, if you can be more transparent than “contact sales for pricing” please do. Devs really hate to get on calls to wait through a demo to get pricing. 

Don’t get me wrong, there is a time and place for a live demo. But do it on their terms, when they need it not when you want to push them through the funnel.   

I like how Posthog approaches it in their homepage copy. 

They basically say don’t talk to us:

• we give you transparent pricing
• we give you a freemium product
• we give you a recorded demo

Don’t talk to us… unless there is something that you need. If that is the case we are here for you. 

But there are at least a few important considerations when it comes to how devs want to buy software and how much buying power they have. 

Akash Bhatia , Nipun Misra and Ishan Vishnoi dissect it in "The Growing Influence of Developers in Enterprise Tech Sales". Here is a TLDR of that. 

Layer of the stack vs buying influence

• Different dev segments operate in a different layer of the software stack and because of it have different influences on buying
• DevOps engs, Network engs, and Security folks have more influence because they touch deeper parts of the stack. You convince them you are good.

What matters during the awareness stage:

• Mention from industry peer 26%
• Community mentions 13.3%
• Third-party evaluation 8.3 %

What matters during the shortlisting/testing stage:

• Ability to test in user their environment 23.7%
• High-quality docs 19.7%
• Vendor test environment 10.1%

Tips for building a strong dev-focused GTM motion:

• Build a strong developer community by focusing on content moderation, personalization, and platform gamification.
• Contribute to open-source projects or release an “open core” offering.
• Provide free or low-cost consulting services during onboarding and implementation.

Ok, so how about we talk about those GTM motions already? Here you go.

Dev tool go-to-market motions

Mark Roberge from Stage 2 Capital recently wrote a great article on startup GTM motions. 

This article feels like 20 years of seeing people try, succeed and fail packed into 10 min read.

It is not about dev tools but very much applies. 

Anyhow, he says that really there are only 6 options:‍

• ‍Outbound: You reach out to buyers directly via email/linkedin trying to get them to see a demo. A “classic” sales approach that devs “love”.‍
• Account-based-marketing (ABM / Account-based-sales (ABS): There is actually a great episode of Exit Five with Hillary Carpio Head of ABM at Snowflake talking about their philosophy‍
• Inbound: You rely on people finding out about you through your content and raising hands (signing up or requesting demos). Digital Ocean is great at that. ‍
• Paid: You advertise to devs on social platforms, google search, podcasts, and newsletters to get people to sign up or see a demo.  ‍
• Product-led growth (PLG): Your product gets people through the door. You have a free or low-price product that people can use and then you try and scale that usage and get people to higher plans. ‍
• Partners: You partner with other vendors or distributors to let them sell your product in some sort of bundle. 

I'd add option 7, open-source, as to me this is a distinct flavor of a product-led-growth motion.

Most successful companies sell through more than one GTM channel. But you should find one that actually works before going for the second one. 

So if you see a GTM strategy that kind of works, put your limited resources there and scale it before playing with the next one. Stack them. But stack on top of things that work, not on top of things that are “meh maybe”. 

I liked what Adam Gross shared about stacking dev tool GTMs.

He suggested to:

• first nail the adoption of the free single-user product. Can be an open-source or free tier of a PLG offer. 
• then nail the self-served PLG at a team level
• then nail the outbound / ABM motion at an enterprise level 

There are a few interesting considerations depending on the GTM model you choose. 

Let’s go into a few of them here.

Pricing, packaging, and designing a free plan

In dev tool go-to-market motions having a free plan that people can start with is crucial for your growth. 

Whether it is via PLG or open-source you should have a free offering. If you don’t, one of your competitors will have it and they will be the default for folks to at least test out. 

But what should go into that free plan?

You want to make it good enough so that some people can actually use it at work but not too good so that they never need to upgrade. 

Another thing is what you put in each tier to make the transition to bigger plans (upsells) natural. You can bundle by capabilities, support, user management or product usage. 

This seems hard but seems to be an incredibly important lever for growth. Some pricing and packaging plans make the upgrades easy, some don’t. 

I like what Postman, the API platform did with their pricing.

You have a super basic free plan that still allows multiple people to use it.

This makes it possible for teams to test it out or use the basics of it in the work environment and then upgrade to team or enterprise plans when they need deeper collaboration or more security and user access control. 

Another great example is how Retool did its free plan. 

Kyle Poyar from Openview actually wrote about this extensively in this article. 

TLDR is this:

• You make the free plan valuable enough so that your target audience can use it (for example devs working on enterprise teams)
• Give users enough (testing) time to experience the value before you push for upgrade
• Track the number of active customers as a leading success metric (this is basically your sales pipeline for the future)
• Design smart experiments and test different paywalls and feature bundles
• Even the best (free) products need marketing around it -> properly launch your free plan
• Make the most of your free plan launch with a GTM plan

I highly recommend reading the entire article, btw. 

Outreach in dev-focused GTMs

Outbound outreach is generally tricky. But when your users are devs this gets extra hard. 

There are some interesting tactics and strategies to go about it though. 

Middle-out dev tool sales

The idea is to outreach to the middle, team manager, while you help devs adopt and provide materials that show ROI/value to the team manager’s boss (VP/director/CTO). 

It was discussed in this Hacker News thread: 

“Apart from bottoms up and top down, there is a strategy called middle out where you target engineering managers and then simultaneously get developers excited with product experience and directors/VP(purchasers) excited about product value. 

‍This generally accelerates purchasing decision. 

‍What I have seen go wrong with pure devtool bottom up is devtool can see value but org does not value the tool. Just devs do not have purchasing power to get to a target Annual contract value that can justify valuations they raise. Everything is devtool space has become product led by design.”

So It is a flavor of outbound that really takes into account how dev/eng organization is structured. 

If you think about it is a small-scale ABM, really. Developer, team leader, and maybe VP of engineering who will ask that team lead some questions. 

Handle Inbound Leads with Use Cases and Outbound by Vertical

In this interview with Casey Clegg (ex senior director of sales/cs at Twillio) they explain the role of technical BDR in dev-focused GTM motions. Especially self-served motions. 

When a dev signs up for your tool they don’t want to talk to sales. They either want to build or they want to see if they can build. So help them. 

If you have technical BDRs who could honestly ask the question “what are you building? how can I help?”

Ideally, those folks would be technical enough to actually help. But if they know their way around the product, docs, resources, and technical folks around the company you should be alright. 

Another important bit is this, the inbound and outbound leads are different and should be treated differently:

• inbound leads: typically know what problem they have and they want to solve it now(ish). So give them docs/resources that solve those use cases. 
• outbound leads: typically don’t know they have the problem yet. Or it is not painful enough. Get their attention by giving them articles, case studies, best practices, benchmarks, specific to their situation (industry vertical, domain etc) 

Product-led sales for dev tools

Just to make it clear dev-focused PLG self-served motion doesn’t mean no sales team. 

Absolutely not. 

Take a look at some stats from the “2022 developer-focused GTM playbook” from OpenView

The best PLG companies have big sales teams. And there is a reason for it. 

At some point of evaluation regardless of how great your docs are, how transparent is your pricing, and how simple is deploying your tool on the customer’s infrastructure, people will have questions or custom needs. 

Actually, the main PLG sales pattern is that at a certain stage of usage/adoption users start having “enterprise” needs like custom predictable plans, SSO, security layers etc. That makes for a great spot to add sales into the mix. 

So product-led sales does not mean no sales people. It just means a different approach to sales that relies on helping people use and buy the product rather than selling the value of the product to them.  

Most users of your tool will hopefully experience the value. And they will help you sell it to their org. Your job is to help them do that. Again, individual contributor devs are not buying. Their boss is buying and they are helping you sell it. 

Product-led vs enterprise sales-led motions

I like how Gabriel Madureira (ex MongoDB, now at PlanetScale) explained the differences for a Decibel VC article: 

With that in mind, Gabriel suggests to:

• Identifying the gaps: lean on data to find the spots where buyer journey sucks
• Testing Human intervention: reach out to people around those moments (hitting limits, hitting product onboarding roadblocks). 
• Equipping humans with data and conversation starters: your sales team should know when and how to reach out. 
• Testing with enough scale vs. depth: make sure people test and refine playbooks with enough accounts (and data) to actually mean something
• Creating and iterating on PQLs: figuring out the leads, should that be people or accounts, what type of activity you need to mean intent, is hard.  
• + Building a team of people who can pull it off: this is not your typical sales rep profile. Needs to be tech-savvy, lead with empathy, capable of diving into the data

One part seems to be especially tricky. Definition PQLs.  

Good product-qualified lead definition

Signup is most often not enough to say you have a product-qualified lead. You often need more activity. But ultimately you want to find more intent. 

Now, there are some best practices of defining Product Qualified Leads (PQL) or Product Qualified Accounts (PQA) but in dev-focused setups, it seems hard. 

Elena Verna defines PQA as:

“Product Qualified Accounts are the subsets of self-serve sign-ups that fit your ICP and have a strong product signal.”

According to Verna that product signal could be:

• Usage volume
• The breadth of feature usage
• The velocity of usage (i.e. big influx of new users)
• Behavioral components (i.e.visitng ToS pages)

Building on that folks from Pocus define in their “Product led sales Vol 1” ebook:

In dev tools, there is an additional consideration. 

Product usage and education often go hand in hand and it is hard to see what is happening. Especially when people are getting into the product. 

Taking this all together we can create a dev-focused PQA definition:

Customer fit:

• Enterprise vs Startup
• Number of employees
• Tool stack (“Are they on Kubernetes?” vs “Are they building on nodejs?”)
• Growing team
• New director hired
• Recently raised funding
• User roles
• Industry
• Geography

Product usage AND education:

• docs and resources visits
• comments on the support slack channel
• GitHub PRs
• Questions on Twitter
• Growing Invites 
• Usage volume getting close to plan change

Buying intent:

• Emails/chat/slack questions that suggest intent (“How does pricing work”?, “Do you support SSO?”) 
• Pricing visits
• Case study visits
• Demo request page visits
• Terms of Service or Security page visits
• X comparison or You vs competitor pages visits
• G2 crowd intent

Product-led sales seems like a way to go for many dev tools really. 

So I suggest going deeper into the subject with these resources:

• Product led sales volume 2 (ebook)‍
• Ultimate guide to product-led sales (podcast)‍
• Product les sales at Retool (podcast)

Selling open-source software

I found this quote that clears up a lot around OSS monetization for me:

“... a user community is a group of people with excess time but no money, and customers are people with money but no time.”

And this is something you need to figure out in OSS:

• who is the community user and who is the target commercial user
• what do each of those users needs and what they will pay for
• put the features/support that the target (enterprise) user will pay for behind the commercial product while leaving all the features that the community user (who will never pay) can use and spread the word about your OSS product. 

Easy peasy but looking at how many companies failed at it, including huge community successes like Docker, not so lemon squeezy. 

That is likely because most if not all OSS projects start with no commercial plans, they build great products, give all the features away. 

But then the community adoption grows and you start thinking wow, let’s monetize it!

And at that point, it may be hard to take away some features from free and put them in paid without alienating the community. 

Or you may have chosen the OSS license that isn’t actually great for the monetization you wanted. Choosing the OSS license btw,  is actually connected to monetization a lot.  

• Very open like OpenStack -> good for the community growth, problems later when many forks
• Limiting (GPL) like Mongo -> good for company/product defensibility, potentially blocking community growth

Ok, but how should you package that commercial product then?

Found a talk from Heavibit where Ashley Smith shares her learnings.

She gives this good rule of thumb:

“So you’re monetizing the developers when they go to work, you’re not monetizing the community”

What it comes down to is focusing your paid plan on:

• Collaboration features (commenting, team roles, permissions)
• Managed services / SaaS product
• Support and professional services
• Enterprise scale needs -> SSO, SSL, support

The most famous implementation of OSS monetization is Red Hat.

And recently their monetization was discussed on Hacker News and in a blog post by the Gitlab CEO.

The biggest reason why it is most succesfull seems to be:

"Red Hat takes Linux and certifies it against all kinds of government, safety, privacy etc standardards, such as PCI and FIPS and numerous local ones.

As a result if you are a government or many large companies you simply cannot download Linux and YOLO it."

So the magic is in the boring, paperwork stuff which actually makes sense as those the things most folks, devs very much included, would happily pay for not to deal with.

A more structured explanation of OSS monetization models comes from “How to sell open-source software” by John Mark Walker.

Basically there are four options:

• Open Source upstream community, proprietary downstream product. (Confluent, Databrics, Cloudera)
• Limited upstream open source community, proprietary downstream product. (GitLab)
• Upstream open source community, downstream licensed product built with open source software. (Red Hat)
• Upstream open source community, downstream SaaS product. (MongoDB, Sentry.io)

He explains those so well that I really suggest you just read that instead of me trying to paraphrase ;)

Conclusions

Ok so what does all this mean?

Here are my takeaways:

• Think of users (devs) and buyers (team leads, CTOs) as connected but separate entities. 
• Give users what they need to adopt your product and hopefully share it with other devs. 
• Talk to them about adoption, solving use cases. 
• Give your buyers reasons to buy at a team level and organization level (enterprise). Give them economical reasons to buy this for their devs. 
• Have a free and commercial tier of your product and think carefully about what goes where. 

And above all don’t sell to individual devs, educate and enable them. Sell to their boss.