[MUSIC PLAYING]
SPEAKER: Enterprises have long relied on KPIs
to align all areas of the business,
and this applies to digital initiatives as well.
Many executives at large enterprises
are now connecting the dots between the performance
of their core business and their relevance
of digital capabilities powered by APIs.
To facilitate the next steps in realizing value
from these critical assets, enterprises
need to become savvy in the use of key performance indicators,
or KPIs, to drive digital programs.
Good KPIs are sometimes not obvious at first glance,
and supporting metrics play an important role.
Stronger programs will often proactively shape their highest
level goals and KPIs to anticipate
broader transformation.
Following some important guidelines.
Number 1, focus on driving growth, breadth, and speed
of API adoption by the application programs that
depend on them.
2, accelerate the velocity of iterations
in, not only API and app development,
but also the creation of user facing digital experiences.
And 3, align the metrics of the API program
with developers and channel partners using those APIs.
We have seen some common pitfalls when defining metrics
at the onset of API programs.
The program should not be a standalone P/L function
with metrics set in isolation.
Generally, avoid using number of APIs
produce as a top line target.
Publishing API is not the same as creating value
through the consumption of that API.
Lastly, avoid measuring your API program like a project.
Targeting and making decisions on APIs
in traditional terms of budget, timeline, and quality
will force managers to focus on completion and timeline,
rather than creating value.
The traditional project metrics can still
be measured but always be careful
of incentives and behaviors this will cast on your team.
Whatever direction you take, the first step
is to establish KPIs for your API program
that are direct contributors to enterprise metrics.
Connect these enterprise metrics to digital experiences,
and measure the velocity at which digital experiences are
created.
These are most important metrics.
In most cases, the API programs to succeed the enterprise
must align metrics for all elements of the digital value
chain, including backend systems, API teams, API
developers, apps, and end users.
This might be a lot to process at one time,
so let's take a look, one at a time,
at some possible KPIs in your API program.
We'll describe what each one of them
are, their benefits, and some of the pitfalls and potential sub
metrics.
One common metric we see is number of APIs.
Often used to drive short-term productivity,
this target often ignores the fact
that APIs must also have easy use utility.
Segment out your APIs by their various functions
or capabilities and look for ways
to measure reusability rather than just volume.
Tracking the number of developers
is a target commonly intended to improve adoption.
You can target metrics developers retention rates,
as well as the number of active developers
within your community.
Some also use a conversion funnel approach
to see how they can convert from developers who are browsing,
registered but not active, to trial user,
to actual production usage.
Be cautious in making this a singular focus, though.
Pair this with feedback from developers
and look at where developers drop off over time.
Customers don't experience APIs directly.
They only experience the apps that they use the APIs with.
Be careful using this KPI.
This target is important, so measure this
with good API instrumentation and app analytics.
For example, knowing how many customers
are connected to all of your company's apps
using the same authentication API
would be a great way to showcase the re-use of that API itself.
Depending on the type of business
you have, this may or may not be an immediate KPI.
However, the potential of APIs to expand your ecosystem
is a powerful capability.
Use this target to reach out to partners,
drive adoption, and demonstrate the success
of the platform expansion.
This is a key ecosystem metric for any platform.
This target may be useful to drive reach.
Use this target by segmenting the apps of partner
and/or internal and by line of business.
If the program creates a lot of apps that are only used
internally and not by customers, it
can sometimes feed internal criticism and abandonment
of the program.
This one is a great productivity metric.
In order to enable app teams to rapidly create new customer
experiences, API teams should become adept at quickly
turning around needed APIs.
Some teams will create a metric called time to hello world
describing and benchmarking the end to end time
to create a very basic API.
You can define it any way you want, but it's a catchy
and instantly understood concept.
Reducing developer friction to access your API platform
is a key target.
Start measuring this early on and distinguish
between the duration for the initial signup,
the duration it takes to get apps approved,
to the duration it takes to go live with an app.
Traffic growth helps with both indication of usage
but also scalability.
This target helps API programs develop a strong DevOps
and RunOps culture by continuously monitoring,
improving, and driving value through the APIs.
Be sure to target this with a related metrics
up and down the value chain, including latency, reliability,
and scalability.
This target focuses the API program
to build relevance across the business
and to drive re-use of the APIs through backend assets they
connect to.
Particularly valuable APIs, such as those that provide access
to unique data or proprietary functionality,
may become a greater asset to partners
and provide entrance to new markets.
This KPI also helps the team escalate blockers
to the proper executive level for resolution.
APIs themselves don't always reduce costs,
but they are critical to broader internal refactoring of value
chains, which do reduce costs.
It can be hard to initially measure
cost reduction from APIs, and sometimes it
stirs dissent amongst managers.
Significant cost reductions are usually realized from the rise
in API reuse and increase in APIs,
allowing the company to purchase more
of the off-the-shelf software.
For example, HR can replace old internal systems and process
by exposing the data through APIs to better Cloud-based HR
software, even more compelling.
Instead of taking capital investment
and building new consumer facing or customer facing
applications, the company can invite
partners to co-innovate and build multiple experiences,
leveraging the company's APIs and core assets.
This leads to a reduction from reduced research
and development spend within the company and in relation
to the speed and market, the new channels
the company is able to access by going to multiple markets
with multiple partners.
Direct revenue can be a tricky KPI to target.
APIs are enablers.
They need an adoption cycle before proving their relevance
to revenue, also it's a purely API Business model.
If you're not one of these kinds of businesses,
you might see a way to upcharge and claim
a share of the revenue for the usage of your APIs
similar to cost of goods sold or chargeback method.
Instead of targeting NPS of those digital experiences,
use NPS to gauge the app developers who
are adopting and calling APIs from within their apps.
To get even more detailed, you can
measure the NPS between internal app
developers versus external and partner app developers.
In early stages, your APIs and documentation
may be really immature.
So NPS is less useful than just getting qualitative user
feedback.
Another aspect to target is the quality of APIs.
Track response times, error rates on your APIs,
and whether they meet the SLA and standards you're expecting.
Don't boil the ocean and focus your team on a handful or less
of measurements that are important to the program's
success.
You can prioritize them or change them over time.
KPIs are metrics are living tools
and should be revisited periodically.
What is important at the beginning
will not be important later on.
Here's an example how we suggest pacing these metrics
and their focus areas over time.
When getting started in the crawl phase,
track the number and type of APIs producing the engagement
of the app developers.
Focus on execution improvement with KPIs for speed and quality
of API development.
Once APIs are in use, shift the focus
to adoption and increase of the ecosystem.
Focus on the number of apps, the number of partners,
or the number of customers that are
using the newly minted APIs.
Once a good production cadence around APIs
is operational and begins to run,
add more familiar business impact
reporting to the dashboard, such as direct revenue, NPS,
breadth of business, and cost reduction as agreed to
with the rest of the executive team.
If you want more information, please check out
the community for ebooks, articles,
and other related topics.
Thank you for watching.
[MUSIC PLAYING]