APIs: A Strategy Guide

Chapter 4. Crafting Your API Product Strategy

APIs should not be geeky “science projects.” They are critical business tools. Successful APIs need clear objectives that relate directly to business objectives and track closely to key performance indicators (KPIs) for the business at large.

Strategy can mean many different things. When it comes to APIs, it is reasonable to speak about business strategy, implementation strategy, technology strategy, operational strategy, and promotional strategy. This chapter focuses on business strategy and specifically on crafting your initial vision of how creating an API will actually help achieve business goals. This chapter will answer the following questions:

• What is your business objective in creating an API?

• What is the vision for your API?

• What questions should be answered to create a comprehensive API strategy?

• What types of API strategies are being pursued?

• What objections should you be prepared to handle about APIs?

Establish a Clear Business Objective

First, and fundamentally, the key question to answer relates to exactly why you have decided to create an API to begin with.

What is the business purpose of the API? What are you trying to achieve? What problem are you trying to solve? What opportunity are you trying to take advantage of?

These are the fundamental business questions your strategy must answer, and they hearken back to an even more fundamental issue: your corporate vision statement and your vision for the API.

Have a Vision for Your API

Like any other product or major project, it is critical to foster a common understanding of what you are trying to accomplish. This is why the first step to successful API programs is to create a common vision for your API.

Note

Create a common vision for your API.

To some, a vision statement might seem too much like management-speak, but having a clear definition of success can go a long way toward creating buy-in and focus for your team.

A vision statement can help identify the top priorities: what must be done and more importantly, what should not be done. This becomes especially crucial down the road, as you clarify progress versus expectations for the project (especially if you get off to a slow start) as well as to avoid your team being pulled in different directions by competing interests (a significant risk, especially if your program starts to take off).

If you don’t have a good example of a vision statement on hand, here are some important things to consider:

• What is the ideal end-state and business objective?

• What are the important things to do day-to-day to get there?

• What are the three key metrics that measure success?

• What are the important things to do day-to-day to continue to meet the objectives over time?

If you can express these concisely—on one slide or one page—the vision statement can be a valuable tool to measure progress and focus resources.

We spoke with Steve Smith and Chris Patti about the motivation for creating AccuWeather’s API. “Not every country in the world has the same quality of public services that we do. Our user base is anyone on the planet, so a farmer in India should be able to pick up the phone and get a heads up if bad weather is headed his way. Right now that farmer might have nothing. Our vision for the API is real time, localized content to the individual, in any corner of the globe, in the right language.”

Corporate vision and API vision should align, and AccuWeather’s lines up perfectly. “The vision for the API is consistent with our vision for the company: ‘Save life and property’ To achieve this, we want to change how the content gets into the API. We want to be innovative in updating content in real time (example: thunderstorm data), and make sure we give back the freshest data with one call.”

Similarly, the New York Times API offers a good example of a vision statement. “The API has reoriented the company in how they view a classic old industry,” said Derek Gottfrid, now of Tumblr. “One thing that really helped was that we were able to tie the mission of the API to the core mission statement of the NYT: ‘To collect, create, and distribute information.’ In many ways the API is the purest sense of that vision and best practices,” said Gottfrid. “Once we saw the API as supporting the core mission, the NYT started to think of their entire business in a new way. This was about delivering information, just not using trucks to deliver papers.”

API Strategy Basics

Business assets such as information, a product, or a service, can be made accessible through an API. The next step is for someone to create a new, or modify an existing, app or site that uses the API in a way that provides value to an audience. When people use the applications supported by the API, the API provides value to the company.

The key questions to start any discussion of API strategy are therefore:

• Who will use the API? (Internal staff, partners, or external developers)

• What assets could be made available through an API?

• Who should have access to each type of available asset?

• How should the API make those assets available?

• What types of applications could be constructed using the API?

• What will motivate developers to use the API to create applications?

• How would those types of applications create value for everyone involved?

• How will the audience discover the applications?

In other words, before striking out with an API program, step back and ask: “What makes sense for the business?” In our experience, in most API programs, the initial strategy is only a starting point. There can be many surprises along the way and innovation and agility are two key benefits of having an API. Although having a strategy is important, if you have some business justification for moving forward, you might consider taking a calculated risk about the possible unknown benefits of creating an API—particularly for internal use where the ROIs we have seen are huge.

In creating a strategy, look at your markets. In general, each market where a company operates has one or more segments where the company is gaining, holding steady, or losing share. Common business objectives include:

• Accelerate share growth

• Move from stagnancy to share growth

• Reverse share losses

Of course, not all API providers are commercial businesses and not all benefits impact the bottom line. For example, NPR’s goal in creating an API was to improve the services provided to internal teams, member stations, partners, and the general public in an effort to improve its public-service mission.

APIs Need a Business Sponsor

The most successful API strategies have a business sponsor. From what we’ve seen, API projects without a business sponsor generally have a lot more difficulty acquiring funding and ultimately starting the work.

Undoubtedly, there are developers in every organization and in the surrounding community who are inspired by the prospect of using a new and exciting API. We encourage this—but only if the innovation can be justified with a business objective. The business-to-developer (B2D) initiative is not usually generated by the business, but rather a technologist who is passionate about creating new functionality. Innovation is important, but if it can be attached to an objective that increases the likelihood of achieving KPIs from somewhere inside the business—“improve customer satisfaction” or “improve branding,” for example—it has a greater chance of securing the business sponsorship needed, which again, dramatically improves the chance of success.

At Sears, an innovative API project was justified by a mandate that the top two partners for the company communicate through the API. Despite being primarily intended as an innovation platform for developers, the project was justified on a B2B basis.

Business sponsors place developers, both internal and external, under the gun, peppering them with questions such as, “How quickly can you come up with your first app?” and “When will I see ROI?” The business sponsor can help develop metrics to keep the project moving forward and help get additional resources if they are needed.

Types of API Strategies

We categorize API usage in two dimensions: by who uses the API to create applications and by who uses the applications developed using the API. In each dimension, developers and users could be private staff, partners, or members of the public at large. The most important dimension for most companies introducing an API to execute strategy is the second: Who are the customers and how will they use applications? By knowing how your customers will use applications, you can better understand what kinds of apps you should be building with your API (or encouraging others to build).

The following section sets forth considerations and questions to keep in mind if you choose to pursue private or public API strategies. It also discusses exposing your API to partners.

Use Your Own API

Using your own APIs creates efficiencies. If one API can be designed to handle all inbound and outbound interfaces with your company, supporting that API is much easier than management of support resources. If new versions need to be created for different audiences, it requires more maintenance.

For example, at NPR, the organization created one large API and a tiered rights-management system so that different users and developers would get different content even though there was only one “pipe” to maintain.

Moreover, experimenting privately with your APIs establishes trust with other people using it because they understand that if you are committing your most important assets to it, your partners and outside developers can feel confident that the “rug” will not be pulled out from under them.

Private API Strategies

When an organization sets a strategy for a private API, the objective may be to foster innovation or to save money and improve efficiency. It is not uncommon for the improvements from a private API to find their way into a public API. That is why we encourage API successes to be publicized within the organization; they may have implications for external use.

One of the main goals of private APIs is to end bottlenecks, where groups with special expertise tightly control assets. By opening up access to assets to any (and potentially every) group within the organization, the assets can be used to their fullest potential. Currently, the most influential example of this kind of leverage power is in exposing valuable assets through an API to mobile development teams. Once the API is established and in full swing, all mobile teams can work on their own cycles to build the products that they need, without waiting as much on changes from dependent services like an internal database application. Again, because private APIs can also be exposed to partners as well, the limitation here will be with app development resources not with the constraints of the API.

Another emerging example where organizations can take advantage of APIs is by allowing internal developers to create innovative dashboard apps for use by project managers and executives. Groups that do not have technology staff can hire consultants to create applications to meet their needs. With an API in place, in addition, applications that make good use of APIs can be propagated across the organization.

Public API Strategies

Public API strategies have had a huge impact on a small set of very influential businesses that can attract sufficient developer attention, such as Google, Amazon, and Twitter. A public API creates an opportunity with unpredictable rewards. Here, the primary objective centers on the scale of adoption.

Public API providers ask themselves the following questions around their primary motivations, which also become success factors for the APIs:

• Does the public API play a key role in your overall business strategy (as it did with Twitter) or is it an ancillary business?

• What level of staffing and engagement are you willing to fund to support the public developer community?

• How does the public API get prioritized against other products?

• If you also run a private API, how do they relate to each other, both technically and in terms of business priority?

• What skills are already in house for a public API and what skills need to be obtained?

The practical questions to achieve these factors include:

• How do we scale the developer support staff?

• How can we enable the community to take care of itself and give them credit for doing so?

For all the major players we know of, internal use of the API outstrips public use by a substantial margin. In other words, if your public API is successful, your infrastructure is likely going to experience traffic from both types of applications.

Putting Together a Team

Once you establish your vision, mission statement, and strategy around the API program, you are ready to assemble a team to execute on the strategy.

A successful API program is driven by like-minded people who understand the potential that the API offers the business. The team should include a few specific roles (see Table 4-1) as well as a group of committed developers and operations personnel. With a strong team in place, the resulting API will be much more robust and the seeds of a vibrant community more easily planted.

Of course, at the beginning of an API program, each team member may have multiple roles until the team is able to grow. Some roles (like legal) are more consultative than part of the team in most cases.

Table 4-1. Roles in an API Team

Role	Tasks	Qualifications
Developer Evangelist	Sells the idea to all stakeholders: internal and external Gets out from behind desk to engage with developers Gets the support of an executive sponsor	Must be technically savvy enough to understand the API and what it can do Passionate about building cool apps with the API Strong marketing instincts and good judgment in representing your brand Effective social skills both online and offline
Product Manager	Creates overall product roadmap Facilitates decisions about features Understands how API is performing for customers and business Drives API improvements	Ability to rapidly prioritize competing requirements Ability to understand and simplify customer requirements
Community Manager	Often the same person as the developer evangelist	Â
Engineers	Design the API Write the API Provide technical support for the API	Experience in API design Knowledge of JSON, XML
Quality Assurance	Validates that the API is delivering the output as expected	Understanding of dependencies and how to interact with customers Experience in test development and continuous integration
Marketing and legal	Provides branding guidelines for using the API Promotes the API	Understanding of developers and the company’s marketing strategy Ideally, understands developer communities
Legal	Provides rules and guidelines for using the API Defines appropriate use of corporate data and customer data Vets any content licensed from third-parties	Understands developers and technology

The Developer Evangelist

Behind almost every great API program is a great developer evangelist. A developer evangelist makes it their personal mission to make developers using the API successful and to provide the API team with feedback to make the API better. The best developer evangelists are extroverted, technical people who get out in the developer community and frequent the same online and offline forums as key influential developers and thought leaders. This applies equally to a company with a private API—you must convince internal developers to adopt your API, and you need their feedback.

What do you look for in a developer evangelist?

• First and foremost, a great passion for building cool apps with your company’s API

• Strong marketing instincts and good judgment in representing your brand

• Technical skills (coding experience is a plus) that can relate to developers and their feedback and represent this to your API team accurately

• Social skills that can be effective in both online social forums and offline developer events, such as hackathons

You are looking for someone who can find developers and connect them with each other. This gives a small team the power to make a large group of developers successful with your API.

API programs that lack a developer evangelist typically have a hard time getting off the ground. Many companies mistakenly assign a nontechnical marketing manager who tries to cover the responsibilities part-time. This is not a good formula for winning the respect of programmers. If an evangelist cannot demand the respect of internal developers, how can they engage the external developer community?

Where can you find great developer evangelists? Often they are right under your nose, inside your company. You might first look for an internal developer who has a passion for building apps with your company’s data and APIs. You can also reach out to and get to know some of the great developer community managers for other API programs; not only will you get a feel for what kind of person you are looking for, but they may make a connection that can help you find your ideal evangelist.

We asked Kin Lane, API evangelist for Mimeo.com, who also runs apievangelist.com, about his view of this role. “Having an open public presence for developers is really important,” says Lane. “I blog and tweet in real time, as I’m building and coding and solving problems from developers. But it’s also critical to be listening and participating in key developer forums. For me this includes sites like Github and Stackoverflow. In the general open world this includes Twitter, Facebook, my blog and guest writing for other blogs. Doing this in real time is critical. You can’t go silent for 2 weeks while you’re at an event or you’ll lose credibility.”

Kin emphasizes the importance of evangelism for working with partners. “With partners, I need to always be educating them. Not only on my API, but also bringing to the table other complementary APIs and what is happening in the API space,” says Lane. “I also make sure I’m pointing them to any private resources they need. Many of your partner’s developers may be mandated to work with your API. You need to focus on their vested interest in making it work.”

In terms of internal accountability, Lane says evangelism cuts across all departments. “I have to report to all departments—technical, business, sales and marketing—to make sure they understand the opportunity and impact of the API and decisions related to it. Again, this also includes educating them on the existence of other APIs, for example, APIs that drive mobile development, so that they don’t reinvent the wheel. I constantly reassess the API program all the time. The investment and return of the API program is constantly evaluated, so I need to be constantly reassessing and selling the API program internally.”

Often the developer evangelist and the community manager are the same person. If not the same person, they should be very close in technical expertise, personality style, and willingness to go the extra mile to help developers use the API effectively.

Objections to APIs

An API strategy that involves offering some applications to the public may raise some eyebrows. After all, what if the API just cannibalizes existing channels and redistributes existing traffic?

Table 4-2 summarizes common objections we’ve heard and provides responses.

Table 4-2. Objections to APIs

Objection	Response
We are afraid our content may be misused	Content available via a well-managed API is at less risk than content on a website. You can identify a particular abusive user and shut them down, or if an inappropriate app is written, you can deny API access to the whole app.
We are afraid of the load on our systems	Load on systems is a good problem to have. It usually means that your audience is growing, either in unique users or in loyalty metrics. If not, then it means that your systems need substantial tuning. In any case, there is something very valuable to be gained here. Moreover, utilizing techniques like rate limiting can offset any concerns around server load. Using third-party vendors to help manage the infrastructural part of the API is also an option.
We are afraid of security threats	Security threats exist with any system exposed outside of a company’s firewall. Whatever measures are taken to safeguard against such threats on the website should be taken against the API as well.
We are afraid page views (and ad revenue) will go down	This should be part of your cost/benefit analysis. How much money do you expect to lose? How can you protect yourself against that? From our experience, you are more likely to grow your audience through the API program than to lose revenue opportunities. The bigger your audience, the more ad impressions you are likely to serve.
We are afraid of how our brand will be used	An important facet of creating an API is making sure your brand is represented properly. This can be handled in the terms of use of the API, requiring proper attribution with your content. You can also embed such attribution in key fields as they get distributed. Generally, developers are more than happy to adhere to any such rules.
We are afraid that we will be overexposing our business assets to our competitors	Understanding your competitive advantages and protecting them is a critical aspect of your API design and offering. Using rights management can enable you to expose the right assets to the right audiences, allowing you to protect yourself from your competitors.
We are afraid that we will create conflicts in expectations between the public developers and potential partners	If you maintain key partner relationships through your API program, it is possible that a public API could compromise your negotiating power with them. The partners may have everything they need in the public API, so why would they pay you for access to it? Understanding the boundaries of each audience and establishing clear terms about how they can operate is critical to serving these audiences effectively.
We are afraid that support costs for different API audiences will be higher than expected and may not be cost-effective	If you are exposing different APIs to different audiences, it is likely that one of these audiences has a higher priority than another. If you are leveraging a private API for your mobile strategy, it is likely that the internal development teams account for a much larger percentage of the overall traffic than the public developers. Meanwhile, your API team has limited time and resources to address the needs of the various audiences. It is important to consider audience prioritization when determining which tasks to focus on. It is also important to communicate effectively what the various audiences should expect in terms of responsiveness to requests.

NPR Overcomes Objections to a Public API

Initially NPR was concerned that opening a public API would enable outside parties to draw content from non-NPR products, which could end up sabotaging NPR’s page views. This had implications for revenue since each page view could generate ad impressions. If an end user consumes an NPR story on a page hosted by someone else, NPR would lose the opportunity to convert the page view into an ad impression. Ultimately, NPR decided that the risk of limiting the reach of NPR content was more serious than any potential cannibalization of page views. NPR’s differentiating product is audio. If someone sees a full-text link to NPR and clicks through to the audio—which embeds an ad within the first 30 seconds—the NPR API succeeded and at least the audio ad impressions are preserved.

Meanwhile, NPR’s total page view traffic grew by 100 percent (see Figure 4-1) after the API took off from internal use. Leveraging the API internally enables tremendous growth potential, even while offering a public API.

NPR was able to add 80 percent more total page views in this timeframe while continuing to grow traffic on NPR.org. That suggests that mobile traffic was not cannibalizing the traffic of the main site. Rather, these page views were additive. And for a company like NPR, which generates revenue on banner ads for their news articles, this type of page view growth has a direct correlation to the bottom line.

Figure 4-1. NPR traffic growth in requests per month

The New York Times faced some similar objections when deciding to open parts of its API for public use. “After much internal debate, we released some parts of the API externally,” said Derek Willis. “There needed to be some persuasion that this wasn’t a bad thing. We wanted to make sure we weren’t just giving content away.”

“Once we started doing public data APIs, we had a long discussion around the terms of service and how they might differ across different types of data. We also had to think through not only the benefits but also the different demands and use cases of different types of partners and developers. For example, we didn’t offer the full text of articles in the public APIs for quite a while; the first API was an article search that returned just a short truncated article. Even now, most of our public API usage is for large partners, such as Amazon,” said Willis.