Strategy

A good strategy starts with having a goal. However, it’s much more than that. Good
strategies define what you want to build, address business opportunities, align to reach a
goal, provide evidence of business value, and identify implementation challenges. Let’s
start by identifying the API product that you’ll build. Look back at the result of the
ideation process. The solution that you have identified to be the best is exactly what
you’re going to build.

The second thing you want to do is define why you want to build the API product. Here,
you have to gather as much evidence as you can to support the business value of the
API you’re designing. By now, you understand why the solution that you’ve identified
is valuable. Let’s rewind to the beginning of this chapter and dive deeper into
identifying why the problem is valuable. From the user interviews, you should know
that the problem affects a reasonable number of users. Now, let’s map the problem and
those potential users to value that is tangible to the business. To do that, go back to the
interviews and extract the impact that the problem has on the lives of users. You can
identify the impact by learning about whether users have to spend time or money
because they have the problem. This is what I call the cost of the problem. In other
words, having the problem has a cost to users, and they would prefer to have it fixed.
The cost of the problem is one of the indicators of what price your solution should have.
Other indicators include how much competitors are charging for a similar solution, if
there are competitors, and how much the user cohort that you interviewed can spend to
fix the problem. With all this information, you should be able to identify a price range
for your API product. To calculate the business value, you must translate the price range
into annual revenue for the size of the user cohort. By doing this, you will know how
much revenue you’ll be able to generate from the API product. And that is the evidence
that can answer the question of why you should build the API product. One of the
benefits of building the API is generating revenue, but there can be other outcomes.

Among the outcomes that an API product can generate, there’s the ability to create an
integrated product. Users often employ different solutions to overcome the challenges
they have. An integrated product is a concept that I developed in 2017. The concept
builds on the ideas of the whole product and augmented product. A whole product
consists of all the features from different products that customers use to solve their
needs. This idea was created by Regis McKenna, a marketer known for helping launch
the first Intel microprocessor and Apple’s first personal computer. The notion of the
whole product was popularized by Geoffrey Moore in the book Crossing the Chasm.
Augmenting a product is the act of making a product whole by adding all the features
that users need to it. The concept of augmented products was created by Philip Kotler, a
marketer and creator of the Total Product Concept strategy. The integrated product is a
version of the original product that’s been augmented by integrating features from other
products to make it a whole product. Integrating an API product is fairly easy because
it’s programmable and simple to connect to other APIs. Instead of augmenting a product
by building features or packaging the product with added features from partners, you
can integrate it with other products. The same thing happens with other products when
they’re integrated with your API. One of the best outcomes of your API product is when
someone else integrates it with their product. Your API product becomes a part of
someone else’s product, and their marketing efforts will help you grow. But to get there,
you still have to build the API.

Knowing how you can go from an idea to a complete running API product is one of the
tasks you have during the strategy stage. Planning the development of an API product
doesn’t mean that you know every detail in advance. At this point, what matters is that
you understand what resources you estimate you’ll need during development and how
much you think the project will take to complete. It’s important to know, for example,
whether you’ll need to hire people or whether you’ll need to reallocate people from
other projects. Another factor to include is an estimate of the risk that the project will
fail. These pieces of information can be used to prioritize the API product’s
implementation against other projects in the company competing for resources. After
you have put all the information together and the project has a positive review, you’re
ready to start talking to potential users of the API product.

As you saw in Chapters 2 and 4, understanding who your API users are is fundamental
to delivering a successful product. Now, you’ll learn what information you can obtain
from user persona research. To begin with, user persona research helps you get in touch
with real people. While some of those people might never use your API product, some
others will eventually become your customers. By interacting with real potential
customers, you’ll get valuable feedback. With the information that you obtain from the
interviews, you can build a list of user personas. User personas are nothing more than
fictional characters representing a specific type of person who would use your API. As
you know by now, each persona has unique characteristics, such as JTBDs, behaviors,
and challenges. Let’s see how you can identify those characteristics in more detail.

JTBDs are one of the most important elements to gather from interviewing potential
users. A JTBD represents not just what people are trying to accomplish but also has the
potential to identify what features your API product should offer. JTBDs represent the
needs and motivations of your potential customers. While a JTBD refers to a task that
someone is trying to accomplish, a feature is a solution that accomplishes the job. As an
example, a JTBD involving payments could be “paying for an online service quickly
and easily.” A feature that would provide a solution for that JTBD could be a simple-to-
use web form that connects to a payments API. If understanding the tasks your potential
users spend time with is important, knowing how they would use your API also helps
you shape your product.

One key area of API user persona research is identifying the behaviors of potential users
of your API. The goal is to know how a user would consume your API if it already
existed. This exercise helps you understand the attributes that your API should have to
fit with the way users think and work. For example, knowing these behaviors will help
you understand whether users prefer to make a single request and receive a large
amount of data or whether they would rather like to make multiple requests that retrieve
small amounts of information. It also helps you identify what type of authentication and
authorization users prefer and even understand what content type users are more
inclined to work with. Behaviors are also connected to user challenges, another area
worth investigating.

While JTBDs represent the tasks that your potential users have to accomplish,
challenges represent all the obstacles that users face while they’re trying to complete
their tasks. Knowing the challenges that users face helps you avoid directions that
would create similar challenges. For example, a challenge related to online payments
would be “not remembering a credit card number.” By knowing about that specific
challenge, you could avoid having a credit card number as input for your API.
Challenges and JTBDs are tied together, and they’re both part of how your potential
users go through their daily activities. Another area to study is the benefits that users
would get from using your API.

Knowing how your API makes people’s lives easier helps you identify what capabilities
you should implement. An API capability can correspond to a whole feature or be a part
of it. Each benefit that users reveal can map directly to one capability. You work
backward from the benefit to how your API would help users realize it. Following the
previous examples related to payments, suppose a benefit is “easily making online
payments without having to remember a credit card number.” This benefit would map
to a single capability of making a payment using a previously stored credit card.
Another interesting thing about benefits is that you can use them in your marketing
communication. In this case, you could announce your API by writing that “users will
be able to easily make online payments without having to remember their credit card
numbers.” So, not only can user benefits inform you of what capabilities to implement
but they can also guide you in your marketing activities. Another area that is critical in
understanding how your API will be implemented is knowing what tools your potential
users are already using in their daily tasks.

By identifying what tools your potential API consumers already use, you can
understand what architectural style to implement. REST, GraphQL, gRPC, and SOAP
are the most popular API architectural styles. Knowing which one to use is critical to
the success of your API product. Each API architectural style has advantages and
disadvantages, so understanding how to choose the right style is critical. First, let’s see
how the different architectural styles compare. First, you pick attributes such as
discoverability, performance, and reliability. Then, you create a matrix that lets you
compare architectural styles at a high level. It’s important to remember that the
attributes and their attribution to each architectural style are entirely up to you to define.
As an example, let’s see what an architectural style attribute matrix looks like:

REST GraphQL gRPC SOAP

Simple to use ✔ ✔ ✔
Discoverable ✔ ✔
Reliable ✔ ✔ ✔
Performant ✔ ✔
Scalable ✔
Observable ✔ ✔ ✔ ✔

I follow two rules that help me decide which architectural style to use whenever I’m
designing an API. First, I make sure that users can easily consume the chosen API
architectural style with the tools they already use. There’s no point in picking an
architectural style that none of your potential API users can consume. Second, I
guarantee that the chosen architectural style can work well with the operations and the
type of data that the API will handle. By combining these two rules, I end up with an
API that can be consumed by users while making it a good technical solution for
handling the implemented capabilities.

By now, you should understand how the JTBDs, behaviors, challenges, benefits, and
tools you use connect to your ability to identify the features, capabilities, and
architectural style of your API. Next, you will learn how to define those characteristics.