[MUSIC PLAYING]
SPEAKER: Welcome back.
In this video, we want to share the approach to an API product
mindset and give you examples on how to design your first API
product.
Let's get started.
I often get this question from my customers
at the start of an engagement.
What is an API?
The formal definition of API is defined as application
programming interface.
It is a way for systems to communicate with each other.
It leverages and reuses data, functions, and applications,
and combines them into new business opportunities.
And furthermore, it connects consumers
of data, systems, and applications
with providers of the same.
Now that you have the formal definition,
you are probably asking yourself,
how does this affect my business?
In the next few slides, we will discuss a recommended approach
to designing your APIs, making it easier for the developer
to discover and begin using your APIs
in order to implement their application with speed.
So now you may ask, what is an API product,
and why is it important to my business?
Approaching an API with the consumer experience in mind
is the cornerstone of an API product.
We call this an API first approach,
or outside in thinking.
Let me give you an example.
For those of you who are MBA fans, when
you think of Steph Curry's basketball shoes,
you might envision a cool blue and white shoe
that enables you to jump higher and farther than anyone
else on the court.
You might envision yourself shooting thee point baskets
from midcourt.
Now, the shoe doesn't really do that.
But it creates the vision of someone doing awesome things
when they wear that shoe.
You want to build the same vision
or need with an API product.
With a focus on the consumer experience,
the API product can encompass a similar vision and experience
for an API.
Let's dig into how this is done.
To understand the need for an API product,
you must first understand the user.
Let's start with asking four key questions
centered around the user of your API.
Who is the user, what are the user's needs, why do they
need it, when do they need it?
The answer to the first question is simple.
The user of your API is an application developer
who will create applications using your API.
The application developer is also known as the API consumer.
Let me give you an example.
A lottery company in the UK wanted
to make purchasing a lottery ticket easy for their players.
Their goal was to give everyone the ability
to make a purchase any time, anywhere.
However, there were some regulations
that needed to be met before the player could
purchase the ticket.
First, the purchase of a lottery ticket
must be made from within the UK.
This requires that the application be
able to geolocate the player.
Luckily, most telcos have a location API available for use.
Next, the lottery requires the purchaser
to be at least 16 years of age.
Therefore, the application must be able to identify the player
and look up the player's profile to determine if the minimum age
qualifications are met.
This can be done through an identity API.
Once the minimum qualifications have been met
and the player is ready to purchase,
the application must provide the ability to pay.
The Billing API allows the application to accept payment,
and the player to complete the purchase of lottery ticket.
The API product is formed as a collection of APIs
that provides the user with the experience of purchasing
a lottery ticket, and ensuring that the minimum qualifications
are met.
Purchase must be made within the UK,
purchaser must be at least 16 years of age,
payment can be completed as part of that transaction.
Furthermore, including reusable assets
such as an enterprise security policy and a traffic management
policy will ensure adherence to corporate requirements,
enabling faster time to market.
Because the lottery API product packages
all of the necessary items, applications
can be quickly created to allow purchasing
of lottery tickets over a wide variety of experience
that is convenient for the player,
like online, mobile app, and kiosk purchases.
Another example of the API product mindset
is with one of our customers who is the leader in ticket
sales and distribution.
The company uses APIs to enable customers to discover events
such as concerts or sporting events,
and provides the ability to purchase tickets on the spot.
This capability is provided through APIs
made available to partners who include the features
within their applications.
Perhaps you are planning a weekend getaway
and want to reserve a hotel room.
In the process of reserving a room on the hotel website,
you might see a link to explore events within the local area.
The link allows you to discover events in the area,
and enables you to buy tickets.
A one stop shop to complete your weekend getaway agenda.
To enable this experience, API products
make it easy for partners to create the user experience.
Let's take a closer look at this partner API product.
The company's partner API product
addresses two key challenges, how
to enable both internal developers and partner
developers, and how to ensure the appropriate level
of security to stop bots from circumventing limits placed
on ticket purchases.
Since security was a must have, that policy
was automatically included in the API product.
In addition, consumers wanted to find events
using various search criteria.
Search by artists, such as Beyonce,
search by venue, like the AT&T stadium,
and search by dates for the event.
The Discovery API had all of the necessary calls
to obtain the event data.
Finally, in order to reserve and purchase the tickets,
you need a commerce API to complete the transaction.
This could all be bundled in a simple to use API product.
Over the course of its use, the company
found that the needs of the partner developer
were the same as the needs of the internal developer.
So one API product could meet the needs
of both types of API consumers.
Now that you have an understanding of the API
product mindset, how do you go about building an API product?
Let's dig into this.
Key factors in building an API product
are, design your API product with an outside in mindset.
This requires understanding your customer and the use case.
In the case of the National Lottery focused on the player,
you might take on the persona, as a player consumer,
I want to purchase a lottery ticket while I'm on the go.
For wealth management, as an individual investor,
I want to view my account holdings.
Or, as a financial advisor, I want
to view my client's account holdings.
Taking a look at the consumer's view
informs how to design your API product
from the most common use cases.
Next, take a look at the needs of your application developers
who will create the experience for your customers.
They need a way to get started quickly with your API product.
That's why documentation is so important,
but documentation alone is not enough.
Make it easy for your developers to discover your APIs,
say through an Apigee Developer Portal.
The documentation makes the APIs accessible.
And finally, review the analytics
to determine what works well and what needs improvement.
Then, continue to iterate to improve your API products.
Gone are the field of dreams.
There is so much information bombarding you
through the world wide web, email campaigns, social media,
and even robocalls to disturb you,
that everyone is on information overload.
In order to get the attention that your API product deserves,
you have to market and evangelize
your product directly to your target audience.
Focus on your developer needs, give them
what they want as far as ease of use, onboarding, and adoption,
and make it fast and easy to consume.
API product mindset means understanding
the needs of others in the digital value chain,
both upstream and downstream.
The application developer is the consumer of your API product.
Documentation describing the product
is the key to its success.
Likewise, for developers to get started quickly
with an API product, you must provide
foundational information to get started, such as what data does
the API product provide, how to access it,
and what is the format of the data?
To recap, the API product mindset
consists of three key focus areas.
Focus on the user experience, think outside in, and get
a good understanding of the user's needs in order
to create a positive experience.
Make it easy to consume with documentation and sample code.
Time to market is key.
Every enterprise company is jumping on board
to enable digital assets.
The first to market will have a leg up on their competitors.
Iterate.
Don't try to boil the ocean, but design for extensibility,
design for the basic value proposition,
get feedback, and continue to iterate to improve the product.
Thanks for your time, and be sure to watch the next video
to learn about customer journeys.