API Lifecycle Operations Stage

This post was originally published on the Nordic APIs blog as “API Lifecycle Operations Stage: Marketing Your API”. By reading this article you’ll understand what factors make up the API Lifecycle Operations Stage, and how you should address them. Transforming your API into something developers will want to consume, and learning what impact this will have on your business are things we’ll consider at this stage. Other critical actions involve maintaining a positive relationship with your API audience and offering the appropriate support channels.

To start, let’s take a look at your API from a different angle — one that presents your API as not just a developer-oriented tool but as a full product that solves a real problem. Keep reading to see how this angle can fine tune the promotion of your API to focus more on your audience’s perspective and needs.

Running Your API As a Product #

Why should you treat your API as if it were a full-fledged product? Isn’t the API something that’s supporting your existing product? Though it may sound strange, running an API as you would with any other product actually makes a lot of sense.

By definition, a product is something that exists to satisfy the needs of a group of consumers. Usually, during product development, you research what consumers need so that you can design your product accordingly. You also conduct research to understand how consumers will use the product that you’re designing. The results of these activities will eventually lead to the creation of your new product.

By applying the same strategy to your API, you’ll not only have an API that developers really want to use, but you’ll also fully understand your target audience— a vital aspect of attracting developers to your API. The second activity is not any less important, as it will greatly inform the API design process. By learning how developers will consume your API you’ll be able to adapt the following items, if needed:

• Access Control: Are developers building applications that act on behalf of several users? Does it make sense to use API Keys, OAuth or something else?
• Methods and Protocols: Do developers prefer REST, SOAP, Thrift, or something else? What makes more sense from a consumer point of view?
• SDK Programming Languages: Are developers using Ruby, Python or other languages? What SDKs should you offer and support?
• Asynchronous Operations: Is your API mostly consumed by Web browsers, mobile devices, or backend code? Are API calls made from behind firewalls? Can your API use webhooks?

If you don’t conduct product-oriented research then you’ll never understand how your API should be offered, and it will be much harder to pivot or gain traction in the long term. If you follow this strategy you’ll have the equivalent of product/market fit: API/market fit. Next, you’ll want to fuel your API usage growth by employing various marketing tactics to attract more and more developers over time.

Marketing Your API #

Marketing an API is very similar in concept to any other kind of marketing. You’ll want to produce material that will promote your API in a variety of ways. This starts with launching your developer portal, which will act as the official point of contact between your API and its consumers.

As your developer portal will be central to all your API-related activities, it should offer an easy access to all the following resources:

• API Documentation: Probably the most important resource, documentation should always be up-to-date and provide all information needed to quickly begin consuming your API.
• Application Registration: Offer an easy-to-follow registration process that any developer can understand. The output of this process should be an API Key or a Client ID and Secret if you’re using OAuth.
• API Console: Developers usually want to test your API without having to write any code. Either offer an API Console or provide ready-to-use code that can be copied and pasted. This first impression of API functionality should be succinct and powerful.
• SDKs: After testing, your developers will want to consume the API from within their existing applications. Offer the appropriate SDKs and follow the packaging and installation standards for each programming language. For example, if you’re offering a Ruby SDK, offer it as a Ruby gem.
• Announcements: Keep your audience up-to-date with anything you do related to your API. Announce all upcoming API changes and other relevant activities.
• Use Cases: Provide comprehensive use cases that your audience can identify with. Complement them with sample code that uses your SDKs. It’s much easier to understand how your API works by reading a story than by going through the full reference.
• Support: Offer a simple support channel directly from your developer portal. Whenever developers have a question they should be able to contact your support team from within the portal. Provide quick feedback on support requests and always follow up.
• Links to External Resources: Link to external resources that could help developers use your API. Have your documentation link to the standards that you’re following and provide relevant social media links so developers can follow your announcements.

If you implement all these suggestions you’ll have a superior API Developer Portal, but you still have to attract developers to it. Site activity should be combined with a permanent instrumentation of your API and Developer Portal usage so that you can correctly measure traction.

Using Different Traction Channels #

In order to obtain the best possible results, fostering your API user base should be done across a number of different channels. Along the way you should measure activity on each channel and adjust accordingly. As you’re about to see, marketing channels have different costs and you should understand how much, on average, each new developer is costing you to acquire.

In the Product world, this value is often called Customer Acquisition Cost or CAC, and can be used as a model to determine if any of your channels should be abandoned. To append this, you should also estimate the total future revenue obtained from each new developer using your API. The Customer Lifetime Value or CLTV is what defines how much revenue, on average, each developer will generate.

To make a profit, you should always aim for a CAC smaller than the CLTV. Otherwise, you’ll end up paying more for developers than the potential future revenue that you’ll obtain from them. With this in mind, let’s look at some possible traction channels.

Evangelizing Your API #

Evangelizing is one of the methods used by most of the popular APIs. Evangelizing is usually done by meeting developer groups in person to share stories about how your API can be used. So-called “API Evangelists” are used to promote APIs using online media, and in person by attending developer-oriented meetups, conferences, and other related events.

Naturally, this type of promotion can have a cost range of nearly nothing — especially if you’re doing it by yourself online — but can be more costly if you employ a group of dedicated evangelists to attend every possible developer conference. Be pragmatic by starting small and measuring your results along the way.

Hackathons #

Another popular traction method is promoting your API at a hackathon. Hackathons may be geared toward a specific industry or theme and are often location-based — allowing you to target specific demographics. Even though hackathons don’t have audiences as large as some developer conferences, you can use them to discover and promote new use cases that can be showcased on other channels.

Again, costs might vary. You can start by sponsoring smaller hackathons, and eventually grow to a point where you’re hosting your own API hackathons at different key locations.

Integrations and Partnerships #

An interesting way to gain traction is to attach your API to the growth of other products and APIs. This can be done by creating integrations that will make your API easily available and consumable by developers who use other products. Integrations often address specific use cases, so carefully study which one will attract the largest number of developers. Some integrations might be as easy — such as writing the code and publishing a guide — but in some cases you might need to engage into partnership development.

Here, the cost will mostly be associated with software development activities — but don’t forget that you’ll also have to maintain and support the integration after it goes live.

Supporting Your API #

Support always works better the closer you are to your audience. Understand where your API consumers usually ask for help and have a saying in those places. Don’t force your developers to use specific tools and processes that don’t make sense from their point view or you’ll start to see them abandoning your API after an unsuccessful usage.

A simple way to grow your support channel is to keep things open. Keeping API-related activities as publicly transparent as possible means your support team will spend less time replying to the same requests.

Use GitHub #

GitHub is considered the most popular developer-friendly service and API providers should take it seriously. By using their free plan you can create a repository to provide an easy-to-use support channel. GitHub offers a way to manage issues related with code changes and openly interact with developers. An example company following this approach is Spotify, who has been very open about all their API-related issues through GitHub.

Other Developer-oriented Support Tools #

Research your developer audience to understand which other web services they use the most. It’s important to have a presence on them as well. Popular services include Stack Overflow, specific subreddits, Twitter or Facebook. Although social media isn’t specifically a support channel, you can use it to quickly give feedback to any questions developers might have about your API. Remember to always be open and to provide helpful responses.

Next Steps #

By now you should know that in order to grow your developer audience in a sustainable fashion, an API should be treated just as if it were it’s own product. Your Operations activities will then consist mostly of marketing your API by implementing the best possible Developer Portal and by following a combination of different traction channels.

The Operations API Lifecycle stage will inform you on what exactly it takes to push your API into high-growth mode. You’ll also discover marketing expenses related to developer attraction, aiming to have that value be much lower than your revenue — otherwise you won’t have a business.

As you learn and your API experiences real world consumption, you’ll likely have to refine your offering. If you’re not obtaining the desired traction, consider revisiting the Analysis Stage to refine your business objectives. If, during Operations, you find that there’s a missing feature or change needed you should follow the Development Stage. Finally, if your acquisition costs are so high that you can’t possibly maintain a flow of incoming developers you should consider jumping to the Retirement Stage of the API Lifecycle.