Developers act, think, and behave differently than your average customer. So selling, marketing, and supporting them should be different too. As an API-first company, WorkOS focuses on selling primarily to developers. WorkOS CEO Michael Grinich, Developer Success Manager Betsy Calender, and VP of Developer Experience Zeno Rocha share how to price your product for developers, market it to developers, and support them as they scale and use the products.
Doing Business with Developers
Developers haven’t typically been the buyers in enterprise software, so why should you build for developers? Well, in the past several years, there’s been a tremendous number of companies that have built specifically for developers and use this as a way to get into these new markets, displace incumbents, and disrupt the competition.
This trend is only going to grow. Twilio, for example, built a next-generation telecom through an API. They took the entire world of telephony and reduced it down to a few API calls.
According to Gartner, 98% of companies plan to use APIs in their business, either internally or publicly. Anyone who says the developer market is not strong is behind the times.
What’s Different About Selling to Developers
Product-led growth is a popular topic these days. In PLG, you have something like a freemium motion to acquire customers. Developer-led growth is like that, but a bit different, with characteristics around self-serve onboarding similar to freemium. This allows you to have like a really cheap acquisition for customers, but the billing model is typically a little bit different as well with usage-based and consumption-based models.
So why sell to these developers? It’s clear that the market is large, but why is this actually happening? Why is this transition occurring now? The main difference that’s happened in the last few years is developers used to only influence product decisions, but they didn’t actually have budget authority. They couldn’t buy anything. That’s no longer the case.
A ready-made global market that has budget
Developers today control an incredible amount of budget. They’re able to actually swipe a credit card, and what starts off similar to a freemium self-serve product can turn into a six-figure contract in just a few months. One of the biggest changes that’s happened in the tech industry in the last ten years is developers having buying authority.
The US has the largest developer population today. However, India is growing extremely fast, as are APAC and Latin America. So becoming an API-first company actually allows you to not only be developer-first, but actually global-first from the very beginning.
The developer-led sales motion is different from a typical SaaS sale where you might sell top-down from a sales-led approach, wherein you’re starting with management, and the execution filters down to the wider org. The deal is signed first, and then the implementation happens. With developer products, it’s the opposite. Oftentimes the implementation happens. They’ve done the integration before. Management might even know that they’re using a product. It might even be months later that a VP of Engineering or a CTO or CFO realizes that they’re built on a new platform. So this structurally is a completely different GTM and requires really rethinking how your entire organization is structured.
Developers hate opaque pricing. If you have a pricing page that says Contact Us, developers will just close the tab and leave. Very few are looking to engage with anyone. It needs to be free or very affordable to get started so they can just put in a credit card and get started. Your pricing also needs to be usage-based so developers aren’t paying for things that they’re not using.
The magic of developer products and the pricing model is the expansion. You have the opportunity to upsell new features and capabilities to them. The contract size grows. Net dollar retention and negative churn metrics are very favorable with developer products. People will spend an order of magnitude more money a year later than they did when they signed up.
A word of caution
There are a couple of pitfalls to be aware of, though. Developers absolutely hate paying for something they’re not using. Getting them to commit to some minimum because it satisfies a sales quota, and then a year later, them not feeling like they actually got the value out of it really stings developers and ruins that relationship.
You also don’t want to have friction in the buying process. A freemium type of self-serve experience is super, super important with developers. They’ll evaluate your product for months without even contacting you.
And lastly, for developers, you really want to talk about the capabilities of your product, what the features actually do, and not use language like ‘unlock revenue’ or ‘unlock sales,’ something that might be more applicable to a business decision maker.
What’s Different About Marketing to Developers
Marketing to developers is super hard to do, and very different from traditional marketing. Developers typically don’t like traditional marketing. If you’re trying to do email marketing, they don’t read their email. They probably will never respond to your LinkedIn messages. So how do you reach them?
Before you can think about marketing, you need to focus on branding. Not for the next year or for the next month, but for the next five or ten years. And it always starts with all the small details that you probably wouldn’t think of. From your landing page to your documentation to your dashboard, all these little delights are what ultimately create a brand that developers are going to love, that they’re going to praise, and they’re going to promote and talk to their friends and recommend to them.
The opposite is also true if all those details are frustrating to deal with, like poor documentation or slow loading times. All of these little frustrations create a brand that developers are not going to really trust, or they’re going to be indifferent to it, which is probably the worst thing you can have for a brand.
Features, not benefits
Marketers are typically taught to focus on the benefits and not the features, but with developers, that’s counterintuitive and can be harmful. So you really want to focus on the actual problem and specifically what your product does to solve it.
Gated content doesn’t get leads
We’ve learned that we need to capture those leads. We need to get those email addresses, and gated content is a big part of how we do it. However, that doesn’t work with developers because they’re going to ignore any attempt that you make to convert them. If you force them to sign up for content, you’re just as likely to get a fake name or a disposable email address.
Instead, think about channels. What are some of the places that you can explore and places where you can find developers? You’ll need to find developers where they are. If you try to do something in a way that is not really authentic to them, they are going to feel it. Be as authentic as possible. So if you can get them to follow you on channels they’re already on, that’s probably a much better thing to do because then you can keep engaging with them later on.
Some channels include Hacker News, Twitter, and StackOverflow. Also, consider the different formats available within marketing. Some people might like blog posts, others might like videos, or some just want to see the code right away.
The voice and the tone are crucial with developers. If you make a small mistake, they’re going to notice. You have to be really careful, and a way to bypass that is to prove yourself as a highly-technical resource. Write content that they can relate to that feels technical enough that they’ll feel like your company knows what it’s doing and really understands their problem.
What about leads? What about qualifying those leads? Users know why you’re asking for their email, their phone number, and their company size. Most users are willing to pay the ‘price of admission’ for the information they want. Developers typically are not.
Rather, you want to make your product easy to sign up for because, ultimately, with developers, word of mouth is what counts. (That’s also the best way of doing marketing in any type of segment, really.) Developers are really loyal, so if you earn their trust, it’s possible that’s going to be your best marketing channel. The best product ultimately is what it’s what’s going to win. So make sure that you focus on that and foster that experience as much as possible.
How to Support Developers
Now that we’ve learned how to sell to developers and how to market to developers, how do we support developers? What tools should we use? What things should be avoided?
Use Slack for support and feedback
Slack is a great tool to communicate with developers. It ultimately reduces the friction because they already have Slack open, so they can navigate to it and communicate with feedback and support questions. WorkOS also extends their support to help their customers’ customers, and this enables them to be a knowledge center and build trust with developers.
WorkOS also aims not just to be reactive but also proactive, and so is constantly letting their developers know about upcoming changes that they may need to do, know what to take action on, and a lot of different navigation, all in the same familiar tool of Slack.
Using Slack also eliminates the need to have them fill out a long support form or add way too much automation that can potentially reduce engagement and increase frustration. Also, make sure you close the loop on any feedback you get because it’s really annoying if you give a piece of feedback and you never hear back from it.
Use your own product
It’s important to actually use your product and test it out before releasing it to your developers. Your team needs to be experts before it goes live so they can answer any questions your customers have. This also enables internal feedback on bugs or friction points.
- Be developer zero.
- Proactively communicate with your customers.
- Build for expansion. That expansion effect is a huge part of developer businesses.
- Make sure to start for free.