Product teams often serve as the nexus between all organizational units within a company, ensuring that a specific line of business follows a clear roadmap and that cross-functional alignment drives success. At their most empowered, product owners are like miniature CEOs for each offering within a company.

Unfortunately, in today’s complicated IT landscape, not everything that should be thought of as a product receives the designation. In my time as a digital consultant, I’ve seen one particular technology too often dismissed as back-office minutiae — application programming interfaces, or APIs.

APIs can be the glue that binds a company’s resources together and the mechanisms through which an enterprise’s data, functionality, and other digital assets are accessed and distributed. They enable software systems to communicate and let developers leverage software for new applications and digital experiences, abstracting underlying complexity into a consistent interface that allows data and functionality to be combined and reused with unprecedented flexibility.

Unfortunately, many business leaders see APIs as middleware and thus as undeserving of the resources of a full-fledged digital product. Their organizations create APIs as one-off projects, with engineers moving on to other projects when they are done and no one looking after an API’s maintenance or whether it offers utility beyond the bespoke use case for which it was created.

This is a problem because APIs can unlock digital assets that otherwise would be captive within enterprise silos. An API that exposes a customer database can likely be used and reused for numerous purposes, for example, and treating developers as customers of this API can help increase adoption of and the amount of innovation around it. But such a powerful outcome is unlikely if an API has been created only as a system integration detail rather than as a product with an owner who oversees a full lifecycle, from ideation to adoption to iteration. Put bluntly, a project-oriented attitude toward APIs misses the boat.

Pitney Bowes, a company I’ve worked with at Google Cloud, offers a high-profile example in which a notable enterprise has treated APIs as products and given its API program the same treatment it would give to any go-to-market offering. After selling traditional mailing and shipping solutions for nearly 100 years, the company transformed itself into a provider of digital logistics and e-commerce solutions by building out 160 public APIs and 400 internal APIs. This enabled its developers and partners to easily consume the company’s location intelligence and shipping services in new, agile ways. It also accelerated the company’s internal project timelines, shortening the average project lifecycle from over a year to just a few months. What’s more, APIs not only introduced efficiencies and reduced costs, but also opened new revenue streams. Because developers can more easily leverage individual Pitney Bowes business capabilities for their applications, the company’s services are manifesting in new ways — such as when Pitney Bowes technology is harnessed to let customers print USPS shipping labels from within the context of an online marketplace.

Manage APIs as products

Traditionally, but wrongly, APIs have been considered pieces of other products. They’ve been built by the IT team at the request of product owners every time a project came up that required one. When the funding spigot is flowing, APIs generally receive support. But once the project runs its course, the APIs are neglected and quickly grow outdated.

Without consistent resources, APIs can’t be adapted to fluctuations in the enterprise and market dynamics. Worst of all, project-oriented APIs often end up siloed within the business unit that gave birth to them, which defies the benefit of modern APIs: to not only allow enterprise assets to be reused by other business units and partners but also accelerate the business’s innovation by increasing the number of developers interacting with its capabilities.

In contrast, if an API is treated as a product in its own right with its own owner lobbying for consistent funding, the API can be iterated according to shifts in internal and market trends. Ideally, the product owner should continually monitor an API’s engagement and collect and synthesize analytics to improve quality of service. Product-minded companies frequently launch APIs as minimum viable products in order to get ideas to market faster, then use API consumption analytics to understand developer engagement and refine APIs to be even more attractive, powerful, and intuitive.

With the help of management tools that facilitate dynamic changes, an API product owner can also help ensure that developers benefit from the latest and greatest build with minimal interruption.

Virtually all traditional product ownership responsibilities can be easily applied to an API. An API product owner is responsible for galvanizing the entire company around their API’s value. Their team can answer any questions users may have about the API’s value proposition or how to use it. It may sound trivial but having dedicated experts available to assist with any question that may arise can be a boon to an API’s velocity.

Additionally, if a dedicated product owner is assigned to pilot a company’s aggregate API program, they can use comprehensive monitoring and analysis of all API traffic to derive insight into which APIs drive value and which don’t. This can save considerable time and money from being wasted on the wrong bets. The product owner can also create API bundles segmented according to each developer community the program wants to serve. Here, the goal is not just to expose enterprise assets, but also to encourage repeat consumption. When it comes to third-party engagement, these bundles should seek to improve partner stickiness to cultivate and maintain new revenue channels. Just as any product is only useful if it has users adopting it and sticking with it, APIs are typically valuable when they attract communities of repeat users.

Tools and processes that turn APIs into strategic assets

To drive an API as a strategic asset, an API product manager should support the API with management tools and processes.

First off, it’s necessary to establish comprehensive security layers for an API so cross-functional internal groups and third-party partners are comfortable using it. Mechanisms that apply protection with introducing user friction — such as OAuth, API key verification, XML/JSON threat protection — are strongly encouraged. It’s also often prudent to integrate machine learning functionality that can detect bot attacks and other adversaries before they breach an API and affect either its developer users or the end users consuming those developers’ apps.

Enterprise software products are typically afforded visualization tools, dashboards, reports, and self-service functionality to drive adoption — and APIs should be no different. Comprehensive portals that highlight API features (including knowledge centers, interactive documentation, blogs, and forums) should be crafted to promote developer consumption. Anything that is likely to magnetize collaborators and expedite registration should be provided for an API. A primary goal of API-first development is to increase velocity, so offering developers a self-service experience while maintaining visibility and control over API usage is crucial.

Manage with an “outside-in” perspective

Perhaps the most important role an API product owner must fulfill is maintaining a staunch outside-in approach.

In an inside-out perspective, enterprise leaders look internally for gaps and fill them with existing IT capabilities. Internal intuition untested by the market can define planning, and the resources that IT already has — rather than those that customers demand — typically restrict options. In contrast, an outside-in approach requires the company to listen to what the market is asking for and to respond appropriately. Outside-in thinkers start by asking what the customer needs, then build strategies from there. Because customer preferences are moving targets, an outside-in perspective is constantly evolving and seeking new data. In the case of API programs, product managers should find ways to align API user data with business KPIs, which can be essential to organizing stakeholders and achieving buy-in for the program throughout the organization.

Because both consumers and developers will abandon products that do not meet their needs, an outside-in perspective is increasingly non-negotiable. The product owner needs to analyze rapidly-changing market trends, understand the competitive landscape, keep a pulse on customer and stakeholder needs, and facilitate a backlog of changes that can help the company satisfy the market. Essentially, API product owners are the end-user advocate — and that’s for both for developers using the APIs and the people touching the applications powered by those APIs.

None of this means product owners need to be entirely risk averse, however. They should have the freedom to experiment with hypotheses and to make adjustments — but to make experimentation viable over the long run, they also need to have the foresight to kill a project immediately if the early end-user response is poor. If the product owner is not learning and iterating, they probably are not pushing the API program forward.

Calling all product professionals

If an enterprise plans to pursue an API-first mandate, it’s crucial that the API program is a well-funded, autonomous business unit. Without a visionary owner, APIs will not be able to usher in the transformation experienced by companies such as Pitney Bowes. The API-first philosophy requires that APIs are built prior to applications and that the API provide a value proposition of its own — which means that if an enterprise wants to accelerate innovation and take advantage of APIs, its first step should be to hire API product managers.

Founded in 2014, Swiggy started small, delivering food to a few neighborhoods in Bengaluru, India. As the company grew, the team wanted a mapping technology that could help expand the service throughout India.

Swiggy needed a scalable mapping platform that covered a wide geographic area and offered tools to help the company to build an efficient mobile app and website for customers and delivery staff.

Customers find restaurants and order from them using the Android app, iOS app, or the website. Swiggy worked with Google Maps Partner Media Agility and used a variety of Google Maps Platform APIs to develop web and mobile apps that incorporate relevant local restaurant details.

Google Maps Platform Results

• Built a hyper-local delivery service that is growing throughout India at a rate of 25 percent per month
• Deliveries are made quickly, resulting in higher customer satisfaction and retention—users have been so satisfied that nearly 80 percent of its orders are from repeat customers
• Drivers seamlessly handle tens of thousands of orders per day

In order to guarantee fast food delivery, Swiggy returns only restaurants within four to five kilometers of the customer’s location. The Directions API is used by drivers to easily route to restaurants and customers. The customer can track the progress of the delivery and estimated arrival time using a mobile app or the website.

“Google Maps provides the most accurate and reliable data, which is crucial for us because maps and location are central to our business. We also knew Google’s intuitive interface would provide a great customer experience with little to no learning curve… Google Maps’ ability to provide customer location and the distances of nearby restaurants is the backbone of our success, because it ensures a reliable, consistent customer experience,” said Aman Jain, Senior Product Manager, Swiggy.

It has been seven years since Marc Andreesen’s famous article “Why Software is Eating the World” was published in the Wall Street Journal, and given the slow pace of change in many companies, some executives still may not be taking the threat of being “eaten” seriously enough. 

Software, and platform business models based on software, have the potential to deliver powerful economic forces into virtually any company or industry. Every company has valuable assets—such as data, expertise or access to certain services or user bases—and most of these assets can be delivered via software. Once an asset is expressed as software in a modern way—that is, as an application programming interface (API)—it can be combined with other software to create new applications and digital experiences.

Benefits of this approach, just to name a few, include near-zero marginal cost to scale up APIs for new users or use cases; global reach for both partners using APIs and end users consuming the digital experiences those APIs power; and network effects triggered as more partners use a given company’s digital assets and spread its services into new markets and use cases.

Disruption by software-powered business models

In the last two decades we’ve seen individual companies and entire industries upended by these kinds of software-powered business models. Examples abound: Amazon and the retail industry, Netflix and movie rentals, Uber and ride hailing, Airbnb and hotels, etc. We’ve reached the point that these companies’ names have become verbs synonymous with being “eaten” by software (e.g., “Amazoned” or “Netflixed”).

The most famous examples of digital disruption involve digital natives, of course, but legacy businesses are leveraging software to evolve too. Brazilian retailer Magazine Luiza—a company I’ve worked with through my employer, Google Cloud’s Apigee team—has enjoyed enormous revenue growth and seen its stock soar, for example, as it has built out its digital platform capabilities and transitioned from a primarily brick-and-mortar model to an omnichannel one. The point is, whether a company has been in business five decades, five years or five months, software remains ravenous and is always looking for new companies and industries to “eat.”

Change in the face of serious threats

Facing this threat, how should corporate leadership respond? There are some excellent examples of CEOs who have galvanized their companies and led them through the massive, gut-wrenching change required to pivot in the face of a serious threat. A few of the biggest examples include: 

• In 1995, it became apparent to Microsoft co-founder and then-CEO Bill Gates that the internet was “the most important single development to come along since the IBM PC,” and, if not embraced in haste, a threat to many of Microsoft’s businesses. In May of that year he published the “The Internet Tidal Wave” memo and focused all of Microsoft on adopting and building for the internet. Almost 20 years later, current Microsoft CEO Satya Nadella similarly made the bold decision to redirect the company for a cloud-first world. 

• Facebook went public at $38 per share in May of 2012 but within months, stocks could be had for a little over half that. The concern? Facebook was a desktop-optimized website without a polished mobile presence, and by 2012, consumer attention had begun to accelerate towards mobile at a much higher rate than many initially predicted.  Facebook CEO Mark Zuckerberg reacted by not only proclaiming Facebook a mobile-first company, but also backing up that proclamation with action.  

• Turning to another company I’ve worked with via Apigee, T-Mobile launched its highly visible “Uncarrier” campaign—which offers streamlined, customer-friendly plans and services—while also investing in and executing a new IT vision dedicated to ongoing digital transformation. T-Mobile execs have credited the technology effort, spearheaded by CEO John Legere, with helping the company to introduce new services and better service customers. T-Mobile’s market cap has more than doubled since Legere took over in 2012.  

Keeping pace with changing customer needs

In the face of an existential threat, strong executive leadership is required to pivot the company to safety, as these examples attest. Digital transformationisn’t about deploying new technologies just to make an existing approach more efficient or to add a few new apps or features to the status quo; digital transformation is about keeping pace with changing customer needs by leveraging software platforms to continuously evolve how the business operates. This can be akin to turning an enormous ship—and a ship can’t turn very well without her captain, first mate, and other leaders showing the way.  

Research supports this. A recent Deloitte survey, for example, found that over “80 percent of respondents from digitally maturing organizations say their leaders have sufficient knowledge and ability to lead the company’s digital strategy,” compared to only “22 percent of early-stage business respondents [who] have the same belief.” Similarly, Gartner research finds that CEOs are seeking a “deeper understanding of digital business” as they shift their focus from growth in general to how technology helps them attain it.  

More recently, the onslaught of software devouring the world has been further accelerated by machine learning making everything smarter, voice interfaces changing how people interact with devices, and more. To keep pace, corporate leaders need to galvanize their companies to build and deploy software faster, make systems and data easily accessible inside and outside their companies, and improve digital experiences through not only machine learning but also constant data-driven iteration. 

Seven years after Andreesen’s editorial, the pace of digital disruption is still increasing, and so is the need for strong leadership to pivot fully into digital. Over half of the Fortune 500 has been acquired, merged or declared bankruptcy since 2000—and the companies that survive in coming years won’t be those whose leaders treat technology as an IT concern rather than a core part of the business.