Some API products aren't purchased by developers
When the pursuit of product-led growth and developer marketing can be a trap
The resounding success of companies like Twilio, Stripe, Postman, DataDog and others has created the misconception that all API products need to have a product-led growth strategy targeted at developers. I’m using the term ‘API product’ (for lack of a better one) to define a broad category of software that must be integrated with an existing tech stack before it can be used.
The integration can be as simple as a POST request or as complex as deploying and scaling open source software in a k8s cluster. What they all share is the need to be configured by some amount of code.
This strategy typically looks like this:
Build a great website and developer documentation early on.
Use content to drive inbound interest.
Convert interest to users via a free tier and pay-as-you-go pricing.
As usage grows, convert pay-as-you-go usage to long-term contracts by promising better pricing, support, and premium features.
But this strategy is not a good fit for all API products and defaulting to it blindly can be a trap. In this post I’ve outlined some of my evolving thoughts (as is the purpose of this blog) on deciding if PLG and developer marketing makes sense for your API product.
Is a developer the decision-maker in the sale?
All API products exist because it is more economical (lower total cost of ownership, reduced opportunity costs etc.) to buy the capabilities they provide than to build those in-house. But in some cases, the reason for buying is engineering-driven, e.g. choosing a domain-specific database over using Postgres, while in others it is purely business-driven, e.g. building payroll features into your SaaS app. This distinction doesn’t ignore that engineering-driven decisions must ultimately have a positive impact on the business — it only serves to distinguish between API products that are primarily purchased by engineering teams trying to improve performance and product teams trying to grow revenue or cut costs.
Developers are the target user for both types of API products, but they only behave as decision-makers when the reason to purchase is engineering-driven. To use the same example, adding payroll capabilities to an existing app is primarily a product manager’s decision because it can add another revenue stream and improve retention. It’s not something a developer thinks about unless prompted by product management. Other examples include APIs for video streaming, integrating with different applications (iPaaS), embedding payments and banking features, and running background checks. Most developers aren’t interested in exploring the nuances of these capabilities unless they’re responding to a business ask.
On the other hand, purchasing a domain specific database, workflow engine, or serverless infrastructure are fundamental architectural decisions. Most developers are inherently interested in the tradeoffs between different approaches here, regardless of whether it’s a top priority at their day job. Additionally, keeping up with architectural trends and new tools can improve their resumes. Another way to identify these types of products is the Hacker News test — if you write about one of these topics, is your post likely to get engagement on HN? A PLG strategy targeted at developers is unlikely to succeed if the reason for buying your API product is primarily business-driven. Developers have no incentive to seek out your product out of pure curiosity.
Does the TAM have a long tail?
If your product can potentially be used by developers in hobby projects that are unrelated to their day job, PLG can be worth pursuing.
This was probably the most important GTM insight I’ve had from comparing my time at Twilio and Modern Treasury. Twilio’s TAM had a very long tail. Every week, a non-trivial number of developers signed up for Twilio with no intention of using it to solve a business problem. Maybe they wanted to build an SMS app to manage RSVPs to a birthday party or control their garden sprinkler with a text message. Twilio encouraged this type of behavior knowing that when the same developer needed to solve a business problem involving SMS or phone calls, they would probably call on Twilio.
The opposite was true with Modern Treasury. There weren’t enough developers interested in hacking around with bank payments for a side project. And for the few that were, getting access to bank rails as a solo developer was impossible. In fact, we had to abandon our quest to find a bank willing to underwrite small startups with uncertain business models. In hindsight, I think we waited too long to make this decision. We also built the GTM motion assuming that a breakthrough was just over the horizon, resulting in mistakes like hiring a growth engineering team to build out the self-serve product experience, instead of hiring a sales team, focusing on outbound sales, and building out the website.
If not PLG, then what?
Here’s a (non-exhaustive) list of things you can prioritize if your API product is unlikely to be a good fit for PLG.
Target product managers
Since business-driven decisions to build or buy a new capability are typically made by product managers, focus on quality content that will establish your company as a credible voice. Make your website and blog a destination for PMs looking to learn more about the space. Explain key concepts and help them evaluate alternatives while highlighting the advantages of your approach. At Modern Treasury, we saw success with our fintech glossary and content explaining how banks worked.
Great docs are still important
Don’t put your docs behind a form. They should be easy to find on your website, easy to understand, and allow buyers to start building a mental model of the integration.
Prioritize use case marketing
You should prioritize use case marketing as soon as distinct patterns in how customers integrate your product start to emerge. Examples of use case marketing I’ve seen work well in the past include:
Developer guides
Video tutorials and webinar discussions
Use case architecture deep dives on your blog
Guides to evaluate different vendors for the use case
Start outbound sales early
The absence of a long-tail makes it possible to build prospect lists segmented by criteria like potential use case and company size. When I was at Modern Treasury, we ran outbound efforts targeted at mature startups and mid-market companies with fintech, vertical SaaS, marketplace and e-commerce use cases. These types of companies had a clear business need for embedded payments and were likely to get underwritten by a partner bank.
Outbound sales efforts with messaging and collateral tailored to the unique needs of each segment will move the needle on revenue and customers when your company is still relatively obscure. It also helps to build a culture of outbound sales and marketing early on because it will continue to be an important growth lever as you scale.
Further exploration
My thinking on this topic is still evolving and there are a few more questions I’d like to explore in future posts:
When should you add account-based marketing to outbound efforts?
Should you make pricing public if you don’t have a self-serve product?
What tactics can be effective in organically growing engagement with your content, especially if you’re starting from relative obscurity?
Loved this