API Strategy for Decision Makers

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.