Building API Products That Create New Sales Models

One of the most consistent things about Revenium's enterprise customers is that their businesses are built on the foundation of sales-led growth (as opposed to product-led growth). This means that they sell & grow their products through the efforts of a senior outside sales team and grow revenue through add-on orders for those products. They typically sell access to their varied products and services via large annual or multi-year contracts and have a small number of large customers as opposed to large numbers of small customers.

Perhaps not surprisingly, many of these customers are curious about using newly developed APIs to add a self-service sales model to their product portfolio. Initially, this line of thinking can be quite jarring for enterprise product teams as they begin to get overwhelmed with trying to solve high-volume customer onboarding, support, product marketing, small-dollar invoicing, and many other problems from the Enterprise customer world that seem overwhelming to scale up to large numbers of small customers.

Although solving each of those challenges is not the focus of this article, we did discuss this in detail with one of our life sciences customers during the apidays conference: How to tackle the most common startup challenges when launching API products as an Enterprise. Not coincidentally, their API marketplace is a great example of an Enterprise using API products to introduce a new self-service sales channel to their customers.

💡One of the great things about API-first products is that they lend themselves incredibly well to a self-service customer acquisition model.

With a well-curated development portal, a well-planned SEO/marketing strategy, and proper API design & documentation, motivated developers can find and adopt your API products without the extended theatrics (NDAs, sales calls, free trial applications, pre-sales scoping calls, etc. etc. etc.) that typically accompany enterprise sales cycles.

Moreover, developers are quite accustomed to self-service API product adoption. They expect to be able to read your documentation and implement a solution on their own, so providing self-service sales models directly aligns to customer expectations.

If all of this perhaps sounds too easy to be true so far, there are some important considerations to get right when launching a self-service API product.

1. You will likely need to develop new support paths for small customers in your support organization who are used to dealing with small numbers of large clients. A common way to minimize the impact on your support organization is to limit ‘traditional’ (premium) support to the most expensive plans you offer for your API and to address the rest with expansive API documentation.
2. You need a strong API product analytics solution to show you who is using the product in what quantities, which customers are struggling to adopt the product, and which accounts have rising/ shrinking usage so that you can react accordingly to each situation.
3. Independent developers are rarely willing to pay in advance to develop a working solution. You will need the ability to enable free trials or freemium versions of your API product to create a logical path to monetization for you and your customers.
4. You need the ability to support credit card transactions in your development portal for the introductory versions of your product.
5. You will need an easy way to invoice what will initially be a larger number of small customers without burdening your finance team
6. You need proper alerting & notifications that identify when it is time to introduce traditional sales into the conversation with customers to convert them into your enterprise sales plans.

Depending on your situation, you may not need all of these capabilities in place on day one (we discuss the “quick start” method in this article). With that said, most items on the list above are common best practices with all monetized digital products.

💰 While you can solve all of the problems in the list above on your own with enough time & preparation, it will likely become clear that the build vs. buy math is strongly slanted in favor of “buy” for most enterprises considering this list of requirements.

The most common benefits Enterprises realize from the implementation of an API-only product & self-service sales motion are listed below:

1. API products often unbundle individual capabilities or features from a larger (more expensive) solution. This opens up new market segments & sales channels for the Enterprise.
2. While there is a risk of revenue cannibalization from customers who downgrade to an API-only plan, more often, we see that API-only products provide a customer retention mechanism for customers that otherwise would leave completely in favor of other options in the market.
3. Customer acquisition & sales costs are typically much lower in a self-service sales model (as are deal sizes)
4. Although deals start small, self-service opens up an important opportunity for client success teams to grow these accounts over time. This pool of small customers will undoubtedly yield a handful of future enterprise accounts, ultimately accelerating customer growth.
5. Lastly, one little talked-about side benefit of an API-only product is that building this new self-service sales motion creates a zero-friction free trial for your traditional enterprise sales teams to use. Instead of going through whatever high-friction process they used to follow, don’t be surprised if they quickly start pointing customers to your development portal to trial the product during a traditional enterprise sales cycle.