Building API growth strategies

Minh Nguyen
Pattern
Published in
12 min readJun 7, 2020

In this three-part series, we’ll explore a few principles of building API products. This article on growth strategies will be followed by thoughts on designing delightful developer experiences: discovery and execution. Subscribe to the newsletter

As the internet economy evolves, startups build increasingly specialised products. Each company wants to focus on what it’s best at, and rely on third-party products for everything else. This leads to the emergence of a tight knit ecosystem of interdependent products, all underpinned by a technology layer, a fabric that connects them all. Essential pieces of this fabric are the APIs (Application Programmable Interfaces) that startups have opened to distribute their products to the ecosystem. They enable convenient, secure, and scalable movements of information. APIs were initially perceived as secondary channels for traditional companies, but recently, a whole new generation of startups have emerged with API-first products.

With this article, we invite founders, product, growth, and technology experts to explore some growth strategies behind API products: how they bring unfair advantages, how they enable platform strategies, and power defensible growth.

Beyond the hype, understanding the emergence of API products

Looking back at history, one of the main drivers of globalisation has been the decrease in the cost of communication. Each innovation causing it to drop, and in turn accelerating exchanges. Richard Balwin describes these successive phases of disaggregation of the global economy as ‘great unbundlings’.

The first ‘great unbundling’ occurs from 1850 to 1914, pauses during the world wars, and then continues from the 1960s to early 2000s. It is characterised by an increasing specialisation of countries, the rise of international trade, leading to a divergence between regions ( industrialisation v deindustrialisation).

The second ‘great unbundling’ starts in the 1980s with the advent of modern information technologies. This phenomenon, also observed by Moore’s law, led to a more granular specialisation of intermediate goods and services: the company’s value chain are even more fragmented, with global supply chains, global sourcing of competing specialised workforce (off-shore), and vertical specialisation.

The past ten years have seen a rapid reduction in communication costs: companies have reached unprecedented levels of economies of scale, with marginal costs ever approaching to zero. According to Jeremy Rifkin, this might contribute to the emergence of a ‘zero marginal cost society' that would radically change the way society functions.

The behaviours and preferences of individuals have also evolved accordingly. With the reduction of the cost of technology, and a rising middle-class in global demographics, the world’s interaction is moving online: internet users jumped from 413 million in 2000 to over 3.4 billion in 2016. If the internet was a country, its economy would rank 5th largest GDP. People now expect instant solutions to their problems, on-demand.

These trends have deeply shaped the technology industry. For example, B2B companies increasingly choose to specialise on a unique product, and rely on highly scalable distribution systems to address a global market. They moved away from the generalist provider model, and now rely on ecosystems of partners. This creates a scalable and tight-knit web of interdependent companies, enabled by easy integrations and low communication costs.

Photo by Alina Grubnyak on Unsplash

In this ‘unbundled’ technology ecosystem, APIs are the fabric that connects all these fragmented yet inter-dependent parts. It is the technology layer that allows information to travel seamlessly and transactions to operate securely. As a consequence, a variety of products and business models have emerged:

  • products with API-first distribution eg. Twilio, Stripe, Onfido
  • products connecting APIs together eg. Tray.io, Segment, TrueLayer, Plaid, Fidel API
  • products aimed at developers eg. Snyk, Gitlab, Sentry, Pusher
  • product complemented by API features eg. Intercom, Airtable, Typeform
  • products with two-sided markets eg. Twitter API, Facebook
  • products with API as a secondary partner channel eg. Skyscanner
  • products with openness driven by regulations: open banking PSD2

Each of these types of product have their revenue model, this article will focus on API-first products, and how they present unfair advantages (1), enable platform strategies (2), and power defensible growth (3).

APIs have unfair advantages

API products aren’t the native apps or SaaS web applications that people might instinctively think of when talking about technology startups. They are unique in that their interface is programmatic, and therefore invisible to the human eye. Interactions are done between machines. This gives them unique attributes that shape a product strategy, in that they produce unfair advantages.

Versatility. API product’s first unfair advantage is that they are versatile. This comes from two factors: control of the end-user experience and modularity of the back-end capabilities. The control of the end-user experience comes from the fact that customers can choose to consume and present information and services coming from an API the way they want. They can fully customise the front-end presentation layer to match the look and feel, experience, and needs of their end-users. Everything can happen behind the scene, so that the end-user doesn’t even know that a third-party API is used. The second element is modularity: customers can pick and choose what features of an API product they want to use, often from the same technical integration. This allows for an infinity of combinations and experiences on the customer side, without carrying too much complexity in the product.

Stickiness. The second unfair advantage comes from the technical nature of the integration. In order to use API products, companies need to invest engineering time and energy. While this can delay the initial adoption of the product, it brings two key benefits: commitment and switching cost. The act of buying is always somewhat of a frictional process. Having to invest some upfront resources acts as a leap of faith, and commits the business buyer into a relationship that resembles more of a partnership. The second element is the cost of switching. Once integrated onto a live technical system, switching to a competitor would require additional engineering work, especially if the product has been deeply integrated and a business logic built on top of it. Combined, initial commitment and higher cost of switching contribute to product stickiness, and reduced churn.

Scalability. The third unfair advantage of APIs is built-in scalability. The technical integration is usually similar for small volume and very large volume clients. It means that an API product can often easily scale and serve high-growth customers. This is why many companies with ‘picks-and-shovels’ strategies (providing tooling or infrastructure for high growth industries) often choose to distribute their products through APIs. Some nuance needs to be brought here. The scalability that we refer to here relates to how the product is distributed, at the interface layer. While it is very unlikely for the API itself to be the bottleneck in a product stack, underlying services might need to be (eg. a T-shirt customisation API would still require economies of scale to rapidly grow a manufacturing operation, or a processing API’s underlying data pipeline). Depending on your business model you might adopt different revenue models to mitigate this: transaction pricing, subscription pricing, real-time bidding, tiered pricing etc… APIs are revenue model agnostic in that sense.

APIs enable platform strategies

The first essential advantage of building API-first products is that it allows to build a product platform.

In this context, we don’t mean platforms as marketplaces (eg. eBay, Amazon, Airbnb), where the value is created by the presence of other users (cf. one-sided or two-sided markets). We mean by it the ability to offer a product to multiple markets, uses cases, or verticals at the same time. This horizontal approach aims at finding a common product and distributing it agnostically, rather than aiming for a vertical specialisation in a specific market.

Platform vs. Vertical strategies

For example, Stripe offers an API-based product that services all clients that need to process payments. It is a clear value proposition, solving a defined job-to-be-done. This core need is present across client segments (small shop owners, large enterprise companies), channels (direct, partners), use cases (one-time, recurring), and geographies (39 countries). By contrast, a vertical strategy would mean focusing on one market, but offering a one-stop-shop covering all needs the clients might have. For example, in the case of the small shop owner segment, it could mean expanding into inventory management, shipping, marketing campaigns etc…

A platform strategy offers three key advantages: product focus, long-tail market capture, and experimental expansion.

Product focus. It allows the company to focus on its core value. It means that the organisation can invest its time and energy perfecting their core competency. This has internal and external benefits. Internally, it gives clarity and focus for the team and prevents people from having to go too deep into a specific industry and getting distracted by adjacent offerings that only serve a specific vertical, use case, or geography. Externally, it helps position a product in the market, in a succinct and simple way. To the point where some API companies become synonymous for their product: Twilio for SMS, Sendgrid for emails, Onfido for identity verification, Stripe for payments etc…

Long-tail markets. The second strategic advantage of product platforms is the ability to capture larger addressable markets. Specialising vertically on a given use case, segment, or vertical takes a heavy toll on resources. That’s why companies adopting vertical strategies can only serve their largest addressable markets, and are forced to ignore or underserve the others. The problem is that the aggregate size of all the smaller markets might prove bigger than the largest individual ones. This is the phenomenon that Chris Anderson calls ‘long-tail’ markets. It explains the success of Amazon Books over Barnes and Noble, Netflix over Blockbuster, or YouTube over traditional media outlets. Each of these companies have been able to create scalable platforms that have the ability to service a very long-tail of niche interests, in a way that would be impossible for companies catering to only the mainstream.

Long-tail markets

In API-based platforms, servicing a niche use case leads to very little extra cost. For example, Twilio offers an API-based SMS product. In a traditional model, they would have to pick a few industries that heavily rely on text messaging (largest consolidated markets), for example with two-factor authentication, delivery notifications, or marketing campaigns. By serving them, they would have to ignore the long-tail of low-volume use cases. However, as an API-based platform, its SMS product can be used across a diversity of applications: from Uber’s driver notifications, Coca Cola’s vending machine technician dispatch, to Alaska Airlines’ flight notifications.

Experimental expansion. Having an existing robust and scalable API platform allows for experimentation. In traditional models, going to market in a new geography, vertical, or segment would require a lot of upfront product investment. The product would need to be adapted to cater for the market’s specific needs, as a required step of a go-to-market plan. Having a platform that is tighter in its value proposition, and distributed through an API, allows for simpler experimentation: the market specific adjustments can often be done in the way the API is consumed. The product investment being very small, the expansion budget can be primarily spent on marketing. Of course, once the product-market fit is validated, some further development might be needed to increase the product fit for full market entry. But these later investments are added only once the initial fit is proven, reducing the risk at a much lower cost of entry. The startup circles have focused a lot on product-market fit, but distribution is often overlooked: API product platforms enable ‘network driven growth’ , opening diverse, scalable, and repeatable growth channels.

APIs power defensible growth

Consumerisation of B2B. For a long time, the distinction between B2B and B2C startups has been the primary lens in analysing growth strategies. Consumer companies would rely on growth levers like virality, network effects, or freemium models. B2B companies would rely on different growth channels, such as enterprise sales funnels, strategic partnerships, or industry trade-shows. However, in the past few years, business buyers have increasingly started to behave more like consumers, in the way they buy technology products. According to Forrester, nearly 75% of B2B buyers now say that buying from a website is more convenient than from a sales representative. This probably needs substantial caveating, based on customer segments, levels of sophistication of products, or criticality of the product for a given customer. But there is still a visible trend towards the consumerisation of B2B: new product-led growth strategies have emerged, where the product is put at the very front of the user journey, and is an integral part of the acquisition, qualification, and activation phases of new customers. A generation of SaaS companies have incorporated great onboarding experience as acquisition strategies. Products like Notion, Slack, Stripe, Intercom or Airtable are easily discoverable, and allow people to immediately access the product upon sign-up. A business buyer, regardless of company affiliation, can immediately use the product and realise its value: taking notes on Notion, making a first payment on Stripe, or creating a workspace in Slack. For API products, where the interface is programmatic, this translates in designing great developer experience: public and exhaustive documentation, self-serve access to a sandbox account, developer tools and community…

Defensibility. Successful startups go through three main stages of growth: product-market fit (‘right idea, right time’), rapid growth (scale aggressively), and reinforcement (build overwhelming defensibility). This has been very well documented with case studies for companies like Facebook or Uber. While the literature on the first two phases is abundant, the last phase is least talked about. It has to do with retention of clients, but it goes deeper than this. It is about leveraging compounding growth to create unfair competitive advantages, preventing new competitors from entering the market. Revenue growth should not only be used to increase gross margin, but to build ‘moats’ to defend the product (a16z). Defensibility can be achieved in many ways, through network effects (marketplaces, social networks), data (machine learning models, unique insights), brand (trust, exposure)… For API products, their unfair advantages (versatility, stickiness, and scalability) all naturally contribute to building defensibility: data can be captured faster and at scale, brand can be publicised to an infinity of channels, network effects can be accelerated.

Product-led defensibility for scale-ups

But there is more than that, if combined with a platform strategy, addressing the long-tail market becomes a powerful defence strategy against smaller competitors. As scale-ups grow, it is common for them to shift their focus towards larger enterprise clients (cf. common migration paths). That’s a great opportunity to displace incumbents and secure larger and longer contracts with very high-revenue clients. But to do so, startups need to heavily invest in building enterprise sales organisations, accept higher cost-of-acquisition, lower gross margins, and longer sales cycles. While all internal resources focus on that shift, they often expose themselves to new entrants: more nimble and aggressive on pricing, they can better service and capture smaller tier clients. It is harmless at first, but as they gain momentum by ‘picking up the breadcrumbs’, they might reach a scale when they become serious contenders and direct competitors. To prevent it from happening and build defensibility, the key is to keep a door open for smaller clients to adopt the product. Low-maintenance and highly scalable APIs and developer experience can allow for that.

Growth engine. Combining high consumer-like expectations on product onboarding, the need to create scaled product-led growth strategies, and the technical nature of API-led products stresses the vital importance of the developer journey. In this new world, the API integration is no longer an afterthought thrown to a technical team after a decision made by ‘the business’, but rather a central piece of the customer journey and growth strategy. The developer journey should be designed as part of a growth engine, with qualitative and quantitive criteria at its heart.

Example developer funnel

The table above illustrate how a developer journey can be designed as a systematic growth engine, by applying Dave McClure’s AARRR model (or Brian Halligan’s flywheel). In the next articles, we will dive deeper on how to design delightful developer experiences, and build high-performing teams and cultures to execute on it.

API-based products now constitute a fabric that connects an entire ecosystem of technology startups. This fabric allows for a convenient, scalable, and secure distribution of products. But more than that, it has also shaped new growth strategies. Leveraging their unfair advantages (versatility, stickiness, scalability), APIs enable platform strategies to ensure product focus, long-tail market capture, and experimental expansion. If combined with product-led growth principles, exceptional developer experience powers new ways to unlock defensible growth.

Thanks João Craveiro and Morgan Bruce for reviewing early drafts 🙌

Want to be first to receive the next article by email? Subscribe to Pattern on Substack

--

--

Minh Nguyen
Pattern
Editor for

Product @Onfido. Thoughts, ideas, occasional musings. Subscribe on pattern.substack.com