API Strategy for Decision

Makers
Growing Your Product Through Customer
Observability

Mike Amundsen and Derric Gilling

API Strategy for Decision Makers
by Mike Amundsen and Derric Gilling
Copyright © 2022 O’Reilly Media. All rights reserved.
Printed in the United States of America.
Published by O’Reilly Media, Inc., 1005 Gravenstein Highway North,
Sebastopol, CA 95472.
O’Reilly books may be purchased for educational, business, or sales
promotional use. Online editions are also available for most titles
(http://oreilly.com). For more information, contact our
corporate/institutional sales department: 800-998-9938 or
corporate@oreilly.com.

Acquisitions Editor: Melissa Duffield

Development Editor: Gary O’Brien

Production Editor: Jonathon Owen

Copyeditor: Amnet Systems LLC

Proofreader: Clare Jensen

Interior Designer: David Futato

Cover Designer: Karen Montgomery

July 2022: First Edition

Revision History for the First Edition

2022-07-12: First Release

The O’Reilly logo is a registered trademark of O’Reilly Media, Inc. API

Strategy for Decision Makers, the cover image, and related trade dress are
trademarks of O’Reilly Media, Inc.
The views expressed in this work are those of the author(s) and do not
represent the publisher’s views. While the publisher and the author(s) have
used good faith efforts to ensure that the information and instructions
contained in this work are accurate, the publisher and the author(s) disclaim
all responsibility for errors or omissions, including without limitation
responsibility for damages resulting from the use of or reliance on this
work. Use of the information and instructions contained in this work is at
your own risk. If any code samples or other technology this work contains
or describes is subject to open source licenses or the intellectual property
rights of others, it is your responsibility to ensure that your use thereof
complies with such licenses and/or rights.
This work is part of a collaboration between O’Reilly and Moesif. See our
statement of editorial independence.
978-1-492-09678-8
[LSI]
Chapter 1. What Is API Product
Strategy?

As the report title suggests, this report covers application programming

interface (API) strategy for decision-makers. In an era of APIs everywhere,
it is no longer enough for a company to simply have an API. APIs must be
planned and designed properly to achieve product-market fit. That means it
is essential to have a vision and a plan to make sure the APIs you are
offering to your target audience are solving important problems and adding
value for both you, as an API producer, and your API customers.
The 2021 edition of Cloud Elements’ State of API Integration report
pointed to a series of statistics on the advantages of a well-planned and
implemented API strategy. Over 44% said it increased speed in meeting
line-of-business needs, and 40% identified increased innovation as a result
of their API strategy.
While this report focuses mainly on the work of designing, implementing,
and managing external API products—ones designed to meet the needs of
external customers—the basic elements can be applied to internal efforts as
well. The recommendations here apply both to companies that already have
an established set of products and a culture that supports them (we refer to
them as established enterprises) and to digital natives—companies that
focused on an API product from the start. While the path to success might
be slightly different, the goals are the same: creating and executing on a
coherent product strategy for APIs.
Mert Aktas of UserGuiding defines product strategy as “a high-level plan
that describes what a company wants to achieve with its product and how it
plans to achieve it.” Typically this includes a product vision and particulars
on the product features and functionality, as well as how that product fits
into your own company’s portfolio and the wider market in general. More
specifically, APIs are products in the digital realm, and they can benefit
from the same management and attention to detail as products in the
physical world.
This report will focus on the three key elements mentioned above (vision,
particulars, and product fit) as they apply to the world of successful API
products. In this chapter we’ll talk about what API product strategy looks
like for both digital native and established digitally enabled companies. In
Chapter 2 we’ll dig deep into the step-by-step process of making your API
strategy come to life. And in Chapter 3 we’ll explore the power of
observability, monitoring, and analytics as a means to quantify, track, and
validate your API strategy.
To start, let’s talk about API strategy in general and the challenges
companies face as they roll out their digital products.

Understanding API Product Strategy

Getting a handle on a solid API product strategy starts with a foundation of
product thinking in general, and product thinking is all about solving
problems—primarily your customers’ problems. In his book The
Innovator’s Dilemma (Harvard Business Review Press), Clayton
Christensen explores the notion of “jobs to be done”. Christensen says,
“When we buy a product, we essentially ‘hire’ something to get a job
done.” Customers have a problem, and they’ll use your product if it
effectively and efficiently solves that problem. If your product does it well,
they might hire you again the next time this (or a similar) problem comes
up.
What every company needs, whether their products are physical or virtual,
is a solid product strategy. One that identifies customers, understands and
solve their problems, and does it in a profitable way. Christensen’s notion of
jobs to be done is particularly important for digital products. In an
environment where creating, marketing, and distributing a product can all
be done virtually, it is easier than ever to hire a company to solve a
problem. It is also just as easy to hire some other company if that first one
doesn’t make the cut.
Product Strategy Foundation
An important element of API product success is adopting a product-centric
strategy for your APIs. This puts the notion of products and solutions ahead
of technology. It also lends itself to the idea of solving problems for people
rather than creating products because they are cool. A product-centric
approach is the start of creating a solid foundation for your API strategy.
In his book Strategize (Pichler Consulting), Roman Pichler points out that a
key element in a successful product strategy is the process of validation. It
is not enough to come up with a good idea for a product. You also need to
assess the value of your product idea. For Pichler, the three pillars needed to
validate your product strategy are:
Market and needs
Who is your target audience? Who is likely to buy and/or use this
product? What are their pain points, what are the typical problems they
are trying to solve, and what help do they need in getting past their pain
points in order to solve their problems?

Business goals
How does this product benefit your company? Does it generate direct
revenue? Does it help sell another existing product by creating more
users or business traffic? Or does it reduce your operating costs?
Increase your brand equity?

Key features and differentiators

What are the key problems this product addresses, and what is it about
this product that is different when compared to other available options?

It is important to dig deeply and explore each of these three pillars of your
API strategy. They produce a foundation to help you make other important
decisions along the way regarding development schedules, costs, and key
performance indicators you can use to track your success.
The three pillars of product strategy allow you to establish a solid
foundation. Next you need to apply these techniques to your API program.

Establishing Your API Strategy

While it is true that a solid product strategy is essential, APIs offer
additional opportunities and challenges that don’t usually present
themselves to products that exist in the real world. Efforts like market
research are the same whether the product is a new physical phone or an
API that makes it easier to create apps for that phone. But the cost of
developing and distributing an API is quite different than the cost of an
actual device that might use an API. And this gives product managers and
other decision makers an important advantage in the world of APIs.
The effort required to create a working prototype for an API is relatively
small when compared to the effort required to create working hardware.
Think of the challenge that automobile manufacturers face when they want
to experiment with new technologies and designs. In the virtual world of
API products, you can explore new ideas relatively quickly compared to
many other fields of business. That is something you can take advantage of
when you establish your API product strategy. More prototypes mean more
opportunities to validate your designs, market assumptions, and customer
needs. In fact, you can more easily run parallel, even competing design
sprints early in your development cycle to quickly learn what works and
how you can best meet both the needs of your market and your own
company goals.
Another key element in successful API product strategy is a focus on
metrics. APIs offer an excellent opportunity to create and track important
business metrics like total customers added today, number of completed
sales, successful up-sell, and other important elements. We’ll dig deeply
into metrics in Chapter 3. For now, keep in mind that observing the business
activity of your API is an important part of your API product strategy.
So good API product strategy leans heavily on using inexpensive
prototypes to explore market opportunities and validate your product and
customer assumptions and company goals. It’s also important to pay close
attention to key challenges of creating a successful API product. And we’ll
cover that in the next section of this chapter.

Key API Strategy Challenges

We’ve already seen how API products offer some important advantages
over real-world products. As you might guess, there are also some special
challenges when creating API products.
For established enterprises, APIs are often seen as an add-on or as a
support-only role in comparison to the long-standing products within a
company. But this approach may cause companies to miss out on important
values and benefits of APIs. In some cases, the most important market for
your API may be entirely different from the ones you relied on in the past.
For the so-called digital native companies—the ones that started out as API-
driven—new competitors in the field or shifts in market demand can
challenge the validity of your current API offerings. You may have been
operating in a market that few of the big companies thought interesting.
How do you handle new challengers in your market space?
Finally, whether you are an established enterprise or a digital native,
successful APIs are often driven by change themselves. New customers and
calls for new features can cause problems when it comes to supporting and
releasing updates over time. Good API products need to be able to balance
future changes with ongoing stability.
Let’s start with the role that change plays in API products and the challenge
that brings.

Supporting Change with Stability

One of the unique properties of API products is that they can be easily
modified and improved even after the product has been released to the
public. The ability to support change over time is a powerful advantage
when leveraged properly. It can also be a nightmare. A product that changes
too often confuses and frustrates users, and that can result in loss of
customers and loss of revenue.
First, it is a sign of a good API when customers start suggesting ways to
improve it. New features and additional functionality can help you retain
existing customers and attract new ones. A good API product makes
positive change a core feature. As you establish your API program, make
sure everyone on your team knows that supporting updates is a key to
success. You can even make this one of your products’ key metrics (see
Chapter 3).
At the same time, it is imperative that adding features does not break the
API or render it unusable for existing customers. The only thing worse than
adding too many changes is adding just one change that renders all your
customers’ code worthless and costs them time and money to fix. Great API
products support improvements without invalidating the investments of
existing customers.
Balancing change with stability can be a challenge, but not one that is
insurmountable. In cases where each transaction represents revenue, it’s
important to never interrupt the cash flow and never cause your customer
added pain. Salesforce handles this problem by releasing side-by-side
updates. When it has a new release (three times per year), Salesforce just
publishes a new API package and announces that to all customers. It does
not shut down access to the old API. Customers are free to move from their
current release to the new one any time they wish. Salesforce never
jeopardizes the customer’s investment.
 THE MANY VERSIONS OF SALESFORCE
Salesforce currently supports more than 20 side-by-side releases
(versions) of its core API. This requires a big commitment on its end to
support all the versions and keep them up and running properly. For
Salesforce, the cost is well worth it. This might not be true for smaller
companies or ones that rely on an indirect revenue model (see the
following).

In cases where the API does not represent direct revenue but instead
provides easy access to your core business, lots of side-by-side releases
may not be the best choice. Instead, you can adopt the “compatible change”
approach where each new feature is added in a way that doesn’t break any
existing features. Essentially, this means adding new things and never
taking away existing things. This is the approach used by Amazon Web
Services (AWS). In an article for the New Stack (“Werner Vogels’s 6 Rules
for Good API Design”), AWS’s Werner Vogels put it this way: “Whatever
changes you make shouldn’t alter the API such that calls coming in from
the previous versions won’t be affected.” Like Salesforce, AWS never
jeopardizes its customers’ investment or its incoming revenue stream.

AMAZON S3 : BACKWARDS COMPATIBLE SINCE 2006

One of the most-used APIs in the AWS collection is its Simple Storage
Service (S3) API. It was first released in 2006, and, despite adding quite
a few new features over the years, the original first-generation APIs
published in 2006 are still supported.

Whether you’re using the Salesforce or AWS approach, a key challenge to

creating and maintaining a great API product will be supporting change
with stability.

Established Enterprises
Established enterprises—companies that already have an established set of
products and a culture that supports them—typically face challenges as they
enter the world of APIs. First, some established companies may have a
product mix that seems to have no direct relationship to APIs.
For example, a company that build homes or supports highway maintenance
or produces consumer goods like skin care may have little to no experience
in designing and building APIs. For these organizations, discovering market
needs, matching them to business goals, and creating and supporting APIs
may be a stretch at first. However, all companies produce and consume data
—sales data, manufacturing data, market data, and so forth. And there are
often many opportunities to turn that data into information. And that
information can be the start of a valuable API product.
Some established enterprises are already using APIs and possibly even
creating their own APIs for internal use. They know the technical details
already. They just need to turn their talents outward toward the marketplace.
Sometimes the market need is found with another audience in the same
business domain. For example, the audience that consumes your company’s
consumer products doesn’t need an API. But the organizations that
distribute your product might be a great target audience for some of the data
you’ve collected about how your consumers purchase and use your goods.
The API product might be a way to augment your existing goods and
services and may have an entirely different audience. Established
companies need to be prepared to look in other places for ideas on what
makes a great API product.
The world of APIs often leads companies to adopt a dynamic culture, one
that is engaged in continuous learning. Peter Senge, author of The Fifth
Discipline (Currency), says, “The only sustainable competitive advantage is
an organization’s ability to learn faster than the competition.” For most API
companies, the pace of change is fast, and data about the market streams in
every minute of every day. Each online transaction provides evidence on
which consumers are using which products—even where and when they use
them. This data can be used to better understand your target audience and
determine how to improve your products’ features and functionality.
As established companies transform into API providers, they may find that
their day-to-day culture also needs to transform to support a dynamic
learning organization.

Digital Natives
Companies that focused on online products from the start are often called
digital natives. They represent many organizations that have popped up in
the last twenty years. These digital natives have many advantages over
previously established companies. They created their tech stack from day
one. Their culture has had to deal with fast-paced rates of change since their
founding. And digital natives have had a chance to learn the process of
discovery, design, and deployment of virtual products.
But not all digital natives are actually API-driven companies. Many are
online-based organizations focused on a particular product domain (think
Salesforce, Box, QuickBooks, etc.). These companies led the first wave of
online services by hosting the application online instead of expecting
customers to install the software on their own machines. This is an
important first step but not the last one.
API-driven companies provide one or more services without providing the
user interface. Companies like Stripe for payments and Twilio for SMS
messaging only provide the API and expect consumers to create their own
UI and applications in front of the API.
Of course, there are companies that have been successful at doing both.
Salesforce started as an application-as-a-service company and grew into a
platform that hosts APIs as well as the application itself.
Even if you are a digital native, you may not have reached the point where
APIs are a core part of your product mix. When that’s true, digital natives
can expect to see the same kinds of challenges as established companies.
Another key challenge of digital natives—even those who are already
hosting successful API products—is losing contact with their target
audience. API users and developers are often looking for the next wave or
the newest technology. Some digital natives that have been around for a
while might be perceived as old-fashioned or out of touch. Companies that
maintain their position in the online market need to be ready for the next
language, the next storage system, or the next user interface technologies
and must be willing to adapt their own offering when called upon to do so.
Salesforce is an example of a company that has been very successful in this
regard. Its initial offering was an online application. Then it provided an
API that others could use to build their own applications. Then it offered
new APIs to expose previously unreachable functionality. To date,
Salesforce hosts multiple language platforms and several leading-edge
products that engage developers and meet their needs.
Digital native companies need to be ever vigilant and stay in close touch
with their target audience and advances in the market.

Summary
In this chapter we talked about the importance of having a product-oriented
approach to APIs and meeting the challenges of successful API products
whether you are a digital native company or an established enterprise.
Chapter 2. Creating an API-First
Strategy

In this chapter, we’ll walk through the entire API lifecycle from inception to
deprecation. We’ll dig into different ways to develop a strategy to monetize
APIs and drive growth of the API business. Many of the topics discussed
here are for API-first businesses where the consumer of the API is a
customer. However, there are other business models around APIs, such as
partner programs.

Discovery
Discovery is top-of-funnel awareness and exposure of your API. Discovery
promotes your API to developers and provides them with an understanding
of its value proposition. Any successful product requires a plan for
discovery in order to drive successful adoption. However, technical
audiences are typically skeptical of sales and marketing, which can make
product discovery a challenge. If you build a massive inside sales team to
push an API solution onto decision makers, the success rate of outreach can
be lower than what you might experience with other buying personas.
Unlike in the past, professional developers in an individual contributor role
enjoy a tremendous amount of ownership and autonomy to make decisions
on which technologies to adopt to accomplish their task. This means buying
software is more decentralized than before. However, most professional
developers are task-oriented, with an ever-increasing backlog of tickets to
complete. Even if sales reaches out to the ideal customer with a healthy
budget who could gain tremendous value out of your API, the timing could
simply be off. Developers have competing project priorities and
deliverables. This means outreach has to occur at the right moment to pique
a developer’s interest.
Introduction to Inbound Marketing
Because of these challenges, one of the most effective ways to attract
developers to your platform is with inbound marketing and a self-service
approach. Inbound marketing is the art of pulling in developers like a
magnet rather than forcibly pushing your platform on to them. This can be
done with genuinely educational content like blog articles, ebooks, and
videos.
Even if developers are skeptical of sales and marketing, they love to
discover and tinker with new things. That feeling of discovering the next
best thing is a powerful emotion. Think of the last time you discovered a
new app and told your friends. Maybe it was in a Reddit thread or through a
news article. Inbound marketing leverages this emotion to make it appear
that the developer discovered a new tool or platform on their own, when in
fact they were marketed to.

Inbound Marketing Goals

Different inbound marketing strategies can achieve different objectives,
some of which might include:

Increasing brand exposure and driving website traffic

Creating new leads and sign-ups
Nudging existing leads to integrate your APIs

Once you have your core objectives, you can lay out a content strategy,
which is the cornerstone of inbound marketing. Content should be genuine
and interesting to developers but still relatable to the specific pain points
your tool solves.
It’s a fine line how specific you want to be. If you go too broad, then you’re
not really pulling in the right developers that would adopt your solution.
You can’t push out content that tells a developer to sign up when they don’t
yet even recognize they have a problem. The way to solve for this is by
mapping the above goals to content that targets various stages of the buying
funnel:
Increasing awareness
Should be informational and resourceful. Example titles that do well
are How to XXX and Best Practices for YYY.
Content designed for exposure is typically not gated (meaning an
email sign-up is not required to view the article).
Not selling, just exposing the developer to the problem space. For
example, apiguide.io exposes developers to the challenges of
developing APIs.

Creating qualified leads

Thought leadership content/make yourself the domain expert

Reasons to buy into the thesis/idea/product you’re solving
Still not about your company, rather just the problem/solution
If generating leads is important, this content can be gated

Considering your product

Results and benchmarks from using your solution, technical

whitepapers
Case studies and comparison charts, which can be gated

If you don’t have any product analytics tools in place, now is the time.
Instrument everything you can (see Chapter 3). Instrument your APIs.
Instrument your web apps. Make sure every advert or external link is
leveraging Urchin Tracking Module (UTM) parameters. This enables you to
understand which acquisition channels have the highest return on
investment (ROI) and to drive product growth. Top-of-funnel growth is no
longer ideal. You should only be investing in channels that lead to direct
conversions. For most developer platforms, this means customers have
actually integrated and are actively using your API.

Adoption
While discovery is focused on top-of-funnel awareness, adoption is focused
on getting developers to experience their aha moment. However, APIs are
unique in that typically little value is received from the API until a
developer finishes their integration work. This can make onboarding and
activation challenging as a lot of investment into integration needs to occur
before value is seen. This onboarding experience might vary depending on
whether you’re a relationship-driven business with many sales touch points
or you’re leading with the product and a developer-first strategy. However,
both types of businesses have common stages a developer typically goes
through as part of an adoption funnel.

First Hello World

First hello world is the stage when a developer makes their very first API
call. This might be accomplished by doing the initial integration of a
software development kit (SDK) or using a tool like Postman to make a few
test calls. The time to first hello world is the time it takes to go from initial
sign-up to making that first API call. Tracking this time and conversion rate
is important to understanding the onboarding experience and effectiveness
of documentation. Because the developer has invested their time into testing
the API, there is some intent to explore the API further. However, the
developer hasn’t seen much value yet from the API and can get stuck in this
stage, aka “kicking the tires.”
A great onboarding experience can help get a developer to this stage. This
means designing the API to be easy to consume and providing good sample
code and tutorials.

First Working App

Unlike first hello world, the first working app is a full working solution
using the API. At this stage, a developer is able to see the value of the API
and may have end-users already using the solution. At this stage, the
developer may demonstrate the solution to other colleagues and advocate
for further adoption. If the developer’s solution is revenue generating, this
stage is sometimes called first paid app.
Many times, a developer doesn’t reach this stage due to gates from other
stakeholders such as security, legal, acceptance testing, and architecture
review. Empowering the developer with the enablement content and tools
can help get them to a working app faster. To assist with acceptance testing,
provide automated tests that a developer can run to validate their
integration. To help with architecture review, provide solution guides and
diagrams that walk through your API’s security and architecture.

Monetization
For many API programs, the API is a product being sold for direct revenue.
This requires a go-to-market strategy to monetize the API effectively.
However, as we saw in adoption, there can be many stakeholders that can
weigh in or veto a decision to purchase an API product. Even if your
proposed economic buyer of your API solution is not part of engineering,
APIs are deeply technical in nature and require extensive input from
different engineering teams, which can create a complex process for selling
an API.

Land Developers First

Instead of trying to appeal to every stakeholder with a complex, top-down
sales process, start by landing developers first with a self-serve onboarding
experience. This doesn’t mean you forego the sales team, but what you’re
doing is getting developers to start seeing value in the API and advocate to
their leadership team before they engage with your sales team. This process
is commonly called developer-first adoption or product-led growth. Your
goal is to get a developer to pay a token amount on a credit card such as
$50/month. They should be able to do this quickly and in a self-service
fashion. Procurement is not involved for this stage, so the subscription can
simply be placed on a manager’s credit card.

Sell Through Developers

Once your customer is already paying on a self-service plan and meets
certain usage criteria, your sales team can become engaged. Because the
customer already received initial value from the API, the sales team takes a
consultative approach, such that the discussion becomes more of an upsell
discussion. Sales guides the customer on how to gain more value out of the
API or navigate certain business requirements the customer may have. A
customer may consider upgrading due to increased usage, new use cases, or
advanced requirements.
This means your sales team should understand a customer’s usage to
identify when to engage a customer in a sales process. In order to do this,
you should set up an API analytics tool which can track the API usage for
each customer through an account-based dashboard. This provides a single
pane of glass into each customer’s and pilot program’s usage for sales and
customer success. It’s recommended to set up automatic notifications, such
as through Slack, when a customer’s usage trend changes. For example,
when an account’s API usage increases by more than 10% week over week,
then they may be ready for a sales discussion. Other indicators include
inviting additional team members to their subscription or utilizing
additional APIs that they were not using before.

TIP
Because your sales team will not be able to engage with every self-serve customer
directly, it’s recommended to utilize an automated email platform like Moesif
Behavioral Emails to guide customers at scale. For example, let them know when they
reach certain quota limits or experience errors with the API. This can be a static
threshold, specific to a plan, or even specific to groups of customers.
Ensure the API Creates Business
Even once you’re able to get developers to use the API, this doesn’t
necessarily mean the API creates business value. Developers may adopt an
API just to experiment with a new technology, create a hobbyist project,
pick up new skills, and so on. However, businesses don’t care about a
simple “Hello World” API. Instead, businesses are purchasing an API
because they see it adding value to the organization. When it comes to
business value, the three types include:

Reducing cost or time (versus a homegrown solution)

Unlocking additional revenue for the organization
Reducing risk for the organization

Pricing and Packaging

If you’re selling your API, there are many ways to package it, depending on
your business goals. Due to their transactional nature, many APIs enjoy a
usage-based billing model (also called pay-as-you-go [PAYG] or
consumption-based billing) to unlock revenue growth, but there are many
different approaches you can take. Areas that you should consider in your
pricing strategy include billing, packaging, and invoicing.

Billing Strategy
Billing strategy impacts adoption and customer activation the most and is
usually driven by the product department. Prepaid billing is when a
customer pays for a service upfront before it’s consumed. On the other
hand, postpaid billing is when a customer pays after the services were
already consumed.

Prepaid billing
Prepaid is the most common model for traditional softare-as-a-service
(SaaS) and enterprise software companies. Because the API provider gets
cash upfront before any services are rendered, prepaid models can be a
lifesaver for the business as they can increase cash flow. This is especially
important if your acquisition or setup costs are high, which allows you to
invest further into product and growth. Prepaid is also beneficial for
customers as it provides spend predictability and reduces the processes
involved for procurement. Because usage amounts are unknown before
payment is made, you can handle usage-based billing through a committed
spend. This might include volume discounting. However, prepaid might
force a customer to do mathematical estimates before they have real-world
data.

Postpaid billing
On the other hand, postpaid is where you’re extending credit to your
customers as they use your platform until they pay. Postpaid can simplify
consumption-based business models since a customer doesn’t need to guess
how much they will consume. Instead, they can just enter their credit card
and deal with the bill later and see how much the damage was (like dining
at a restaurant or bar). Postpaid billing has been popularized by
consumption-based models, like the digital advertising industry and, more
recently, the cloud industry. A benefit of postpaid is that a customer does
not need to commit ahead of time before any value is seen.
However, there is a downside. Because you’re extending credit, it can be
abused by customers depending on your offering (like a dine-and-dash
scenario). Having good safeguards and limits is important to ensure a
customer doesn’t accumulate too much credit before they purchase.
Postpaid can also have higher cancellation rates. A customer could use
much more of an expensive service than expected and then have regrets.
The following table shows some of the pros and cons of each approach:
 Prepaid billing Postpaid billing
Description Customer purchases credits/quota Customer only pays for their usage
ahead of time that is later consumed after service is already consumed
Pros
Better cash flow Less onboarding friction
More familiar with traditional Easier with PAYG
enterprise

Cons
Onboarding friction Additional credit risk
Harder with PAYG More easily abused

Packaging Strategy
Packaging strategy impacts contract value and expansion revenue the most.
Because not every customer will receive the same value and pay for the
same amount, packaging refers to how your different SKUs and offerings
are presented to a customer. You might use different features or usage
components to enable customer segmentation.
Tiered pricing is a packaging technique common within SaaS to create a
“good,” “better,” and “best” plan, each with a predefined set of features and
quotas. PAYG, also called usage-based pricing or consumption-based
pricing, is another packaging technique where a customer purchases a
quantity or volume such as a number of API transactions. PAYG is an
accelerant for developer-first or product-first organizations. This can also be
important when customers have very low levels of usage.

Tiered pricing
Classic tiered pricing makes it easy for customers to understand their costs
and makes pricing more predictable, a plus for large companies purchasing
software. It’s common and well understood within the SaaS industry,
reducing complexities around billing. In addition, it’s super easy to
implement. You don’t need any metering or analytics to track usage. You
can just implement a subscription billing software solution.
The issue with tiered pricing is the disconnect between price and perceived
value. As a customer comes close to the limits of their plan, they naturally
should upgrade their plan. However, the price jump to the next plan can be
significant, which can cause scenarios where the customer doesn’t feel
ready for the next tier. This can be exaggerated if the tiering utilizes too
many variables. It’s uncommon that a customer will exceed all limits of a
plan and will instead exceed only one quota limit. However, the next plan
has “too many extra items” that the customer doesn’t need (such as
additional features). Similarly, you don’t want more than three or four tiers.
If you have too many, it creates analysis paralysis.

Pay-as-you-go (PAYG) pricing

Because of these issues with tiered pricing, a more modern approach is
being utilized where customers pay for their usage. Consumers have
utilized physically metered plans for quite some time, like gas and electric
utilities. This concept of metering can be applied to digital products that
have a usage-based component. Common things to meter on include
transaction volume, gigabytes sent, or unique users.
A benefit of usage-based pricing is that the price to perceived value gap is
significantly reduced as customers only pay for what they need. PAYG is a
great accelerant for product-led growth or developer-first businesses. You
can design a self-service plan that hooks in customers and then allows them
to grow their usage over time. In other words, your pricing model has built-
in expansion revenue. However, PAYG can be challenging without knowing
what is going on in terms of customer usage levels. Moesif’s analytics is
one solution that can meter API usage and automatically invoice customers
through a provider like Stripe. See this guide for a step-by-step guide on
how to implement prepaid with PAYG.
The following table lists some of the pros and cons of tiered and PAYG
pricing:
 Tiered pricing PAYG pricing
Description Traditional SaaS pricing with predefined Usage-based or consumption-
suite of features/capacity for each tier based pricing based on a unit
price
Pros
Enforces a minimum spend More optimal for customer
Predictable for customer Less friction in expansion
Easy to implement Can “appear” cheaper

Cons
Friction in expansion Can upset customers with
billing surprises
Rigid, not aligned to value
Complex to implement

Choosing the right usage metric

With usage-based pricing, it’s important to choose the right metric to meter
and bill on so that it’s correlated with the business value received. Billing
for every API call is likely a poor metric since some APIs are low value
(such as a status probe). Similarly, you might offer both a batch and
nonbatch API. If you’re building an SMS API offering, then a single API
call that sends 100 SMS messages as a batch and then transcribes them
creates a larger amount of value for the customer than an API call that sends
just a single SMS message. In this case, billing based on number of SMSs
sent would be a better metric than billing on number of API calls.
As a secondary example, let’s say your API handles sending marketing
emails but also provides the ability to store email templates in the platform.
If you bill based on number of templates stored, that might be a bad metric
as it’s unlikely a customer receives value simply by storing additional
templates in the tool. If the customer drafted a massively large number of
email templates but never sent a single email through the API, their bill
would still be large. On the other hand, customers sometimes have strange
behavior, like consistently deleting old email templates after they’re sent
even though it would have been better to keep the email template in the
tool. In this case, customers get value by automating the process of sending
marketing emails. Thus, a better metric aligned to customer value would be
the number of unique contacts emailed per month or number of emails sent
per month.

TIP
It’s best to automatically notify customers when they exceed key quotas or plan limits so
as to avoid upsetting them with billing surprises. This can be done with behavioral
emails. See the Moesif blog post “Top 5 Behavioral Emails Every Developer Tool
Should Use”.

Common Value Metrics

The metric to use will depend on the API and business. It’s important for
the metric to be measurable in production, easy for your customers to
understand, and correlated to the value a customer receives from your
product. It should also be accurate for billing purposes. Most value metrics
can be bucketed into one of the five types shown in the following table,
depending on the business:

Name Example When to use

Transaction volume Number of API calls, APIs and event-based platforms such as SMS and
messages sent analytics

Revenue/cost share % of revenue, transaction Platforms focused on money such as payments or

fee expense reporting

Data volume Gigabytes sent, minutes Platforms focused on data such as logging or
made storage

User-centric Monthly unique users that A modern version of charging per seat or per user
are active

Resource Compute units, active Compute infrastructure such as a database or

hours virtual machine

Invoicing strategy
Invoicing strategy impacts cash flow and is typically driven by the financial
team the most. Once you decide on a billing model and how your offering is
packaged, you’ll want to determine when invoices are triggered and
generated. Unlike billing and packaging, which have an impact on product
and expansion revenue, invoicing strategy has a larger impact on unit
economics. With recurring invoicing, you invoice the customer on a
schedule such as per month or per year. On the other hand, you can also
invoice customers once they reach a threshold, such as when they reach a
certain quota or outstanding spend. This type of invoicing is called
threshold-based invoicing.

Recurring invoicing
Recurring invoicing is the more popular of the two and easy for customers
to understand. You can invoice them in a prepaid way (which is usually a
fixed price) or send a bill for what the customer’s usage was for the prior
billing period. For buyers of enterprise software, recurring invoicing is
usually preferred as it’s predictable and easier to plan for. There are a
couple of downsides, which usually come up with extreme PAYG models.
If you have some customers with extremely low volumes, where they are
paying only a few pennies or dollars per month, the transaction fees will
exceed the cost of service. Similarly, if a customer can quickly rack up a lot
of credit within a billing period, or the value received is very transactional,
this could create a large accounts receivable balance in between billing
periods, even though the service has since been rendered. This is common
in the digital advertising industry where large spends can accumulate
quickly.

Threshold-based invoicing
In order to combat the poor unit economics of recurring invoicing,
threshold-based invoicing can be leveraged. With threshold-based
invoicing, the invoice is not generated until a certain threshold is reached. If
prepaid, this means a customer is purchasing credits which can then be used
(which might be far in the future). If postpaid, the invoice is generated after
a threshold is reached, such as $1,000 in ad spend. This ensures you only
have up to $1,000 outstanding for a customer at a time, regardless of their
monthly spend. Threshold-based pricing is not without downsides. It can
heavily complicate accounting, since the spend is not predictable and not
exactly aligned to a billing period like quarterly or yearly. The time could
be open ended and not well defined.
This table lists the pros and cons of both types of invoicing:
Recurring invoicing Threshold-based invoicing
Description Customer invoiced on a schedule Customer invoiced only after a credit
like each month, quarter, or year threshold is met (can be prepaid also)
Pros
Easier for finance team Reduced transaction cost
More predictable Easier for prepaid

Cons
Bad unit economics for low- Harder for finance to recognize
cost SaaS revenue
Complex if prepaid Company liability

Pitfalls of Usage-Based Billing After Release

Beyond just implementing a data pipeline to handle usage-based pricing,
there are a number of other challenges that come up especially in managing
customer expectations. A common problem is customers who blow through
their usage far quicker than anticipated, creating a large bill they did not
expect. This can be especially true in APIs and tools that have a data
volume component.
It’s important to reach out to customers to keep them informed of this. One
way to achieve this is via automated emails that warn customers of their
usage once certain predefined thresholds are met. In this case, even though
the quota is not a hard limit, you’re letting the customer know how much
they used for the month.
It’s also helpful to give customers some control around these thresholds. No
one wants to receive 10 emails a month on their usage even though it’s a
predictable bill. Providing a UI for customers to adjust those thresholds can
help ensure they get alerted only when needed.

Deprecation
Deprecation is considered the end-of-life phase of a product lifecycle. In an
ideal world with unlimited budget, an API is perfectly designed to handle
every customer use case and can live on forever. However, real-world
products are budget constrained and require ongoing investment to meet
ever-changing business requirements. Thus, a normal course of business is
to decide whether to deprecate an API or replace it with a new version.
Deprecating an API is the process of letting customers and partners know
that the support for an API may end in the near future and discussing
migration plans. Deprecation could involve removing specific fields or
endpoints or retiring an entire platform. Sunsetting an API is the final
process to safely end-of-life an API and shut down its service.

When to Deprecate
A decision to deprecate can be due to a variety of reasons, some of which
are listed here:
Cost to maintain the service exceeds revenue
If the service is no longer profitable and costs more to maintain than the
revenue, you may want to sunset that service.

Migrating to a new API platform

If a replatform or rewrite is already on your road map, this can be a
good time where underutilized features are removed for scope
reduction.

Improving the developer experience and reducing bloat

Sometimes you want to refactor your API spec to make it cleaner and
easier to use.
Pivoting in product strategy or business objectives
When pivoting product strategy to meet new business objectives, you
may not have the time and resources to maintain old use cases not
aligned with those objectives.

Loss of key team members and institutional knowledge

If the original owner of the service or feature transitioned out of the
company, the cost to ramp a new member up may exceed the value of
the feature.

Security or compliance risk posed by legacy features

Maintaining a vulnerable endpoint for legacy support could expose you
to unnecessary security or compliance risks. A sunset plan should be in
place to move customers to an updated implementation.

Inefficient or bug-prone API

Some APIs may be bug-prone or subject your infrastructure to
reliability issues. For example, an export API may not have large
adoption yet may consume the majority of your support tickets or
causes outages.

How to Sunset an API

A well-defined deprecation process helps minimize the disruption to your
customers, which could be other teams at your organization or revenue-
generating customers. Depending on your customer obligations, this
process may take six months or longer. Part of this process requires
sunsetting, which is a period where the API is functional but only with
limited support.

1. Identify customer impact

The first step is to understand the impact from the deprecation using API
analytics. You should have a good grasp of who is using the soon-to-be-
deprecated APIs and how it impacts customers’ implementations. At a bare
minimum, you should understand what percentage of your customers are
actively using the deprecated feature. However, simply measuring counts of
API calls is not sufficient. You should have a quantifiable business metric to
measure impact, such as potential lost revenue and cost to support the
deprecation effort.

2. Announce the deprecation plan

Once you’ve decided to move forward with the deprecation, you will need
to announce your deprecation plan to your customers. This should be
published on your project blog, changelog, internal wiki, or any other
channel that customers turn to for information. It’s highly recommended to
email customers directly and overcommunicate rather than risk upsetting
someone later.
You should also mark the endpoints as deprecated in any developer docs or
API reference that you have.

3. Email customers when they use the deprecated API

Even though you announce the deprecation via email or blog, not everyone
will view the announcement or they may forget about it. This is where
providing a personalized customer journey based on their API behavior is
critical. Each time a customer uses the deprecated feature, let them know
right then. This can be done through a combination of HTTP response
headers and behavioral emails (customer lifecycle emails).
To make it easy for your customers to migrate, it’s recommended to include
helpful info like which deprecated APIs were accessed, volume, and the
user agent. These emails can be automatically configured using a platform
like Moesif or HubSpot. It’s recommended to set up a recurring workflow
to remind customers periodically if they continue to utilize the deprecated
API.

4. Warn customers using HTTP response headers

Even if you send warning emails to every customer in your database,
sometimes the person responsible doesn’t receive it since the developer’s
contact information is no longer valid or emails got sent to spam. The
recommended way to ensure the appropriate developer receives the
deprecation notice is by in-app notification. While the first thing you may
think of is an in-app portal, not everyone logs into an API provider’s
dashboard on a regular basis.

5. Implement a brownout strategy

You can never overcommunicate a change that could break a customer’s
integration such as API deprecation. However, sometimes the developer
still does not take action. One way to semi-force customers to do something
is with a brownout or rolling-blackout strategy. This strategy turns off
access to the feature or service temporarily, such as for 15 minutes on
Tuesday at 6 p.m. PST. This will help trigger any alerts and alarms that your
customer may have set.
It’s recommended to enforce a brownout when the chance a developer is at
a computer is high, when they can take action quickly but end user impact
is minimal. If you expect a large number of support tickets, you can
implement a rolling blackout where only select customers at a time are shut
off rather than everyone, just like a rolling power outage that’s planned
during very high demand, such as in heat waves.

WARNING
A brownout strategy may not be appropriate for certain mission-critical APIs such as
financial or healthcare APIs.

6. Monitor usage to see if safe to deprecate

Now that you executed the majority of your deprecation plan, it’s a good
idea to analyze how usage of the deprecated endpoint is trending to see if
it’s safe to follow through with shutting off access permanently. Hopefully
by this stage, not many customers are accessing the deprecated endpoints or
features. You may have a few stragglers, which are ghost services that are
no longer maintained, but it’s better to be safe and fully understand who is
still using the endpoints.
If the API users are critical customers, you may need to delay your shutoff
date for a period to work with those customers. Large customers with
complex systems are sometimes the last to migrate. This can be done easily
using an API analytics tool.

7. Shut off access to the feature

Now that you’ve added all the steps to properly sunset the feature, it’s time
to permanently shut it off. Check one last time to ensure no adjacent
services are erroring out due to dependencies that were not realized earlier.
Congrats, you correctly went through the steps to sunset an API.

TIP
Check out this step-by-step guide on how to responsibly deprecate APIs incorporating
impact analyses, announcements, warnings, brownouts, and safety checks.

Summary
A developer-first go-to-market can be a great way to accelerate adoption
and monetization. However, it requires having the proper tooling and
process in place to ensure developer communication and onboarding are
seamless.
Chapter 3. Making Your
Strategy Observable

In this chapter, we’ll cover the terms observability and monitoring and the
role they play in establishing a reliable way to “see” how developers are
finding and using your API product. By collecting data on developers as
they explore your API products, you can discover where you need to
improve your developer experience and what features really matter to your
audience, and you can uncover bugs and problems your developers are
dealing with as they try to use your API.
Above all, it is important that you get in the habit of “designing in”
observability and monitoring metrics when you create your API products.
As Geoffrey Moore, author of Crossing the Chasm (HarperCollins), put it:
“Without big data, you are blind and deaf and in the middle of a freeway.”
First, let’s talk about the terms observability and monitoring, and then we
can explore the notion of product analytics and how you can use it to
improve your API products.

What Is Observability?
Observability is a method of determining the internal condition of a system
through external outputs—in other words, having the ability to “see” into a
running system to determine its overall health and efficiency. Launching an
online service means you are responsible for maintaining that service—
keeping it up and running—in order to meet the needs of users.
The challenge of creating and maintaining any API product is that, since it
is virtual, it is hard to “see” what is going on from moment to moment. Is
the service up and running? Are customers able to successfully complete an
order? Is that a machine online that is running out of memory?
To answer these questions, we need to observe external parts of the system
(number of completed orders, wait times for requests, etc.) and derive
meaning from those observations (e.g., it is taking too long to read a record
from the database) in order to, if needed, do something to improve the
efficiency of the product.

Monitoring and Observability

It is worth pointing out the difference between monitoring and
observability. In Site Reliability Engineering (O’Reilly), the word
monitoring is defined as “Collecting, processing, aggregating, and
displaying real-time quantitative data about a system.” This is, basically, the
work of identifying key metrics, in real time, and making them available for
review.
As we mentioned earlier in this chapter, observability is the process of
determining the internal state of a system based on external outputs. We can
observe the health of a system by inspecting and analyzing the results of
monitoring. Quality observations are dependent on solid monitoring output.
You can greatly improve the observability of your API by paying close
attention to the values you monitor or publish. You can’t easily determine
the time it takes to complete a user order if you don’t monitor the latency of
the checkout and payment steps in your product.

Levels of Observability
Just as there are different points of view, there are different types of
observability. Successful API products support observability for multiple
points of view. For this report, we’ll focus on three observability types:

Machine
Service
Product

Machine-level observability
At the lowest level, you have machine-level observability. Typically
machine-level observations include things like CPU, memory, disk access
speeds, and other similar values. When you deploy your API product into
production, it will run on individual physical or virtual machines (usually in
clusters), and each machine has its own observable health status. For any
API product, you should be able to view—at any time—the machine-level
status of each running instance in your service cluster.

Service-level observability
The next level is service-level observability. Services are the dedicated
operations that run on various machines. The ability to read and write data
from the database, process an API request, validate inputs for an order, and
the like. These are all service-level metrics. Essentially, you need to be able
to view the service-level status of your system at all times. Often this is
provided through a dashboard that lists the rate of object reads/writes,
backlog of processing requests, and so on. Service-level metrics focus on
that status of individual URL endpoints (e.g.,
/shopping/computeTaxes, customer/update) instead of that
condition of machines (see above).

Product-level observability
At the top of the stack is product-level observability. At this level, you are
monitoring the rate of key business metrics such as completed orders, added
users, and abandoned shopping carts. Product-level metrics for your API
are tied directly to your business goals (net new revenue, increased
customers, etc.). It is essential that your API product implementation make
it easy to track the status of these business goals. Usually these are not tied
to any single endpoint but are, instead, derived from a series of steps (e.g.,
selecting an item, placing it in the cart, and checking out).
Successful API products support observability at all three levels. By
combining metrics on machine performance, service reliability, and
business goals, you can get a comprehensive view of the health and success
of your API products.
Implementing API Product Analytics
API product analytics is the process of identifying important business-level
goals (e.g., onboarding new developers), selecting monitoring values for
that metric (count of added developers per day), and then inferring the
success level for that product metric.
For this report, we’ll review three important product metrics since they
relate directly to keeping a close eye on your API-first strategy (see
Chapter 2):

Onboarding
Time to first hello
API depth

These are just examples of the kind of project-level observability you’ll

need in order to create a successful API product.1

Onboarding Metrics
A key metric to track for API products is the onboarding of new developers.
As discussed in “Land Developers First”, developers are often the first
target audience for any API, and understanding the status of your
onboarding experience is critical to the success of your API.
Example metrics you can set up as monitoring output in order to gain
observability into your API onboarding are:
SignedUp
The act of opening up or creating an API account for your product.
Usually some exchange of a developer’s identifying information for
access to a subset of your API product.

APIKey
The moment a SignedUp developer creates an API key that allows them
to start making API calls on your platform.
FirstCall
The first API call made using the APIKey for that SignedUp developer.

The above list is a skeleton of the onboarding process. By monitoring (and

dashboarding) these values, you will get a view into the process and can
make some decisions on how you can improve your overall onboarding
experience.
Some questions to ask yourself as you review the data:

What is the average time from SignedUp to APIKey to FirstCall?

What percentage of developers who SignedUp reach FirstCall?
Is there a big fall-off between SignedUp and APIKey or between
APIKey and FirstCall?

By analyzing the data, you may find you’re getting a high SignedUp rate
but a low APIKey rate. Maybe it is too cumbersome to generate an APIKey.
What if you made that easier or maybe automatically generated an API key
for them?

NOTE
This onboarding example assumes there are three steps (SignedUp, APIKey, and
FirstCall). If your product onboarding has more steps, you need to be sure to include all
of them in your Onboarding Product metric.

At this stage, your goal is to turn prospects into customers as quickly and
easily as possible. Maybe developers get an API key but aren’t motivated to
make that first API call. The next product metric can help you with that.

Time-to-First-Hello Metrics
The time-to-first-hello (TTFH) metric (see “First Hello World”) is the one
that tracks the developer making the very first API call on your product
platform. This is a critical measure of the value of your API product. And
the quicker you can get a developer to make that first call, the better. Jarkko
Moilanen, coauthor of the book API Economy 101, says that “developers
should be able to test APIs using code examples within just 180 seconds of
engaging with the product.”2
There are a handful of values you can monitor in order to gain observability
into your developers’ TTFH experience. For example:
APIErrors
Are developers experiencing errors when they try to use your API?

SDKBugs
Are there bugs or unexplained errors coming from SDKs your
developers are using to access your APIs?

ImplementationFlaws
Sometimes developers end up using one or more of your APIs in ways
you didn’t anticipate. For example, they need some bit of data about
their customers, but it takes three or four API calls to get that data.
These repeated calls might be more error-prone or introduce
performance problems and even increase the likelihood of experiencing
API call errors.

Paying attention to the API calls your developers are making gives you a
pretty good view of what they understand about your API from
documentation, examples, and any other sources like peer-level support
from other developers. The most common barrier to TTFH is usually client-
side API errors.
Poor documentation
Maybe developers can’t figure out the proper URL or arguments or
HTTP methods to use when calling your API. If yes, maybe you need to
modify your API product documentation.
Unexpected usage
Maybe they are using your API in ways you didn’t anticipate and are
getting unexpected results. If this is true, you may need to offer more,
clearer example calls to help developers get started.

Troublesome SDKs
Maybe they are using your own SDK (or ones created by other
developers) and the SDK itself has bugs. You might need to encourage
new developers to skip the SDKs to start to make sure they get a quality
TTFH experience.

It is a good idea to treat every attempt by your developers as a kind of gift

—one that tells you a bit more about the developer as well as your API.
Learning from their experience gives you an opportunity to improve your
product as well as their experience.
But TTFH is not the end of the line. It is also important to pay attention to
how seasoned developers use your product.

API Engagement Metrics

Once you get developers signed up and past the first API call, you want to
pay attention to what they do next. Do they explore other APIs in your
product? Do they just keep making the same couple of API calls? Do they
just disappear altogether? The long-term success of your API depends on
building a strong relationship with your developers and helping them learn
how to use more and more of your APIs. You want to get them to go
“deeper” into your product.
Often developers start using your product because they have a particular
problem they needed to solve and your API does that for them (see
“Understanding API Product Strategy”). However, it is to your advantage to
help developers discover more features of your API, too. It could turn out
they have other problems that your product solves and they haven’t figured
that out yet.

Monitoring for API Depth

Possible monitoring values to help gauge developers’ API engagement are:
A list of the APIs most commonly used (API-MCU)
The number of different API endpoints called by a single developer
Which SDKs are used and how often (if you support API SDKs)

Knowing the most commonly used APIs (API-MCU) can give you a
valuable view of which parts of your product are seen by developers as
most beneficial. You might be surprised by what you find. Sometimes the
most popular APIs are not the ones you expected. Developers might be
telling you they need more APIs in a domain, that they want easy access to
data properties that are currently difficult to reach, and so on. In some cases,
developers may be giving you hints on additional API products you can sell
them.
Once you have good numbers for API-MCU, you can also get a direct count
of the number of different endpoints called by each developer. For example,
if developers typically only call a small subsection of your API, you might
have an opportunity to expand their use of your product. Or developers
might be telling you which APIs are not needed. This can help you focus
your bug-fixing and feature-building activities for future releases.
Also, if you provide API SDKs for your developers, you can track which
releases (by language) are more popular, or which ones are not used at all.
Just like the API-MCU case, getting a handle on SDK usage can help you
focus your efforts for future releases.

Increasing Developer’s API Engagement

A good way to increase your developer’s API engagement is to publish
emails, blogs, and videos that cover select API features and/or SDKs (see
“Introduction to Inbound Marketing”). For example:
Segment marketing
Initiating a mini-marketing campaign that targets a segment of your
users with nudges to try out new features can be a great way to track the
success of both your marketing efforts as well as the value of particular
API features.

Feature onboarding
You can create dedicated “onboarding” experiences, or “pilots,” for new
endpoints too. Write up a short tutorial with multiple steps developers
can take to interact with a new API and set up metrics to track each step
along the way. This gives you a chance to see if there are places where
developers experience problems or just abandon the tutorial due to lack
of interest. Using an account-based dashboard can help track
onboarding goals and ensure pilots are successful.

Developer advisors
You can identify “heavy users” of your APIs and invite these developers
to try out new experimental features or early updates to SDKs.
Essentially, you’re inviting developers to tell you what they like, what
they wish was different, and how to improve your product in future
releases.

Increasing API depth is a great way to improve your relationship with

developers and learn more about the API product space and how you can
help solve your customers’ problems.

Summary
In this chapter we covered the terms observability and monitoring and
talked about how you can use monitored metrics to observe the way
developers are using your API. We also talked about the idea of API
product analytics, including tracking API onboarding, time to first hello,
and increasing the API depth of your developer community.

1 For an in-depth view on API product analytics, check out Moesif’s blog post “API Analytics
Across the Developer Journey”.
2 Art Anthony, “API Onboarding Is Broken (and How to Fix It)”, Nordic APIs blog, January
2022.
Chapter 4. Next Steps

The aim of this report is to introduce the notion of API product strategy and
offer a guide to the product strategy journey and some of the key decisions
you need to face along the way. This boils down to three key strategic
challenges:
Committing to an API product approach
Managing the product lifecycle
Establishing an observability culture

Committing to an API Product Approach

First, in order to build a successful API program, you need to adopt an API
product point of view (see Chapter 1). The foundation of a solid product
strategy can be summed up in three elements:

Market and needs

Business goals
Key features and differentiators

Knowing your target audience and their needs is the first step. Recognizing
where the needs of the market and your business goals overlap helps you
keep your efforts focused on profitable work. And targeting key features
that separate your APIs from competitors helps ensure your product will
stand out in a crowded field (see “Establishing Your API Strategy”).

Managing the Product Lifecycle

The lifecycle of an API product has many steps and requires clear decision-
making through the process (see Chapter 2). Once your product is released
into the market, you need to make sure developers discover your product
when and where they need it (see “Discovery”). You also need to make sure
they can adopt your product and incorporate the API into their own
lifecycle (see “Adoption”). Of course, it is important to pay attention to the
product’s monetization to make sure you are properly monetizing the APIs
(see “Monetization”). And finally, you need a transparent deprecation
strategy in order to keep your organization focused on useful, profitable
API products going forward (see “Deprecation”).
The key to a sustainable API product strategy is to be constantly working
the lifecycle, continually renewing your commitment to market needs,
creating new products to meet those needs, and observing the constant
stream of feedback in order to identify successful APIs and future needs.

Establishing an Observability Culture

Once the strategic decision is made to launch API products, you need a
reliable and consistent way to gather key metrics and use those metrics to
get a clear view of the state of your products and programs (see Chapter 3).
You need more than status reports on individual machines or running
services in your IT infrastructure. You also need to track key business
capabilities like developer onboarding, time to first hello, and API depth
usage in order to identify successful products that need additional funding
and support. See a comparison of open source API analytics and monitoring
tools.
Building observability into each and every API product you create (see
“Implementing API Product Analytics”) makes it possible for everyone in
the organization to see which products are successful, which deserve added
attention, and which should be closed up in order to better fund the products
that are contributing to the company’s business objectives.
What’s Next?
Launching and supporting an API product platform is not rocket science,
but it does require lots of decision-making, and good decisions rely on
quality information about the market, your APIs, and your customers.
Committing to a product-centric approach, diligently tracking your API’s
successes, and continually working the product lifecycle are all important
elements of a successful API product strategy.
In the end, it’s all about hard work and persistence. As Dan Waldschmidt,
author of Edgy Conversations: How Ordinary People Achieve Outrageous
Success (Next Century), puts it: “The only thing standing between you and
outrageous success is continuous progress.”
Appendix A. Additional Reading

This appendix lists some recommended books, articles, and recordings that
cover additional aspects of API products and strategy.
Chapter 1
“Launching API Programs in Non API-First Companies”, Moesif
Podcast, March 2022. Great interview with Jeannie Hawrysz, leader of
API Programs at SAS.
Product Design for the Web, Randy J. Hunt (O’Reilly, 2014). Another
solid source on product-oriented APIs.
“Serverless Architectures”, Mike Roberts, martinfowler.com, May 22,
2018. A good reference on the serverless space.
Strategize: Product Strategy and Product Roadmap Practices for the
Digital Age, Roman Pichler (Pichler Consulting, 2016). This is a fine
book on the big picture of product strategy and execution.
“What Does API Monitoring Mean for API Product Managers and
Growth Teams”, Derric Gilling, DZone Integration Zone, April 20,
2020. Nice post that ties together business goals and API monitoring.
Chapter 2
“Automatic Notification of Quota and Billing Issues”, Larry Ebringer,
Moesif blog, September 14, 2021.
“How to Integrate Moesif and Stripe to Easily Monetize Your APIs”,
Matt Tanner, Moesif blog, March 30, 2022.
“How to Show the Business Value of Your APIs with Embedded
Metrics”, Derric Gilling, DZone Integration Zone, June 23, 2021.
“A Simple Way to Implement Usage-Based API Billing is Finally
Here”, Matt Tanner, Moesif blog, February 16, 2022.
“Tracking a Developer’s Journey from Documentation Visit and Sign
Up to First API Call”, Derric Gilling, DZone Integration Zone, July
20, 2020.
“What Is TTFHW?”, Matt Tanner, Moesif blog, January 19, 2022.
Chapter 3
“API Analytics Across the Developer Journey”, Adam DuVander,
Moesif blog, March 1, 2021.
API Economy 101, Jarkko Moilanen et al. (Books on Demand, 2019).
Chaos Engineering, Casey Rosenthal and Nora Jones (O’Reilly, 2020).
Crossing the Chasm, Geoffrey Moore (Harper Business, 2014).
Site Reliability Engineering, Betsy Beyer et al. (O’Reilly, 2016).
API Traffic Management 101, Mike Amundsen (O’Reilly, 2019).
About the Authors
An internationally known author and speaker, Mike Amundsen consults
with organizations around the world on network architecture, web
development, and the intersection of technology and society. He works with
companies large and small to help them capitalize on the opportunities
provided by APIs, microservices, and digital transformation.
Amundsen has authored numerous books and papers. His book Design and
Build Great Web APIs (2020) for Pragmatic Programmers Publishing is an
oft-cited reference. Amundsen also contributed to the popular O’Reilly
book Continuous API Management (2020, 2018). His book RESTful Web
Clients was published by O’Reilly in February 2017, and he coauthored
Microservice Architecture (O’Reilly) in June 2016.
Derric Gilling is the CEO of Moesif, the leading API analytics platform for
product owners to better activate and monetize customers. He works with
both startups and large enterprises on launching and scaling an API-first
strategy. Gilling is a frequent speaker at developer conferences, including
API World, Developer Week, APIDays, and DevRelCon.