APIs as products

Apigee's Top API Editorials of 2018

Apigee experts published dozens of editorials in 2018 to help developers, IT architects, and business leaders understand how to maximize the value of APIs and keep pace with constant technological change.

With literally quadrillions of daily API calls connecting apps, data, and systems throughout the world, 2018 saw APIs reassert their position at the center of almost every digital use case. Though APIs are not a new concept, the ways in which organizations leverage them continue to expand, from APIs used within the enterprise to manage microservices and enable faster and more agile development methodologies to monetized APIs used to open new business models and expand an enterprise’s digital capabilities to new partners.

Here are some of our top articles from 2018, organized by some of the year’s biggest themes. Thank you to all of our readers, and stay tuned for more in 2019!


APIs are crucial to the automated connecting of data, applications, and systems—and when companies make automation easier for partners and customers, they often inadvertently make it easier for bad actors, too. Several organizations and their customers suffered through high-profile data breaches in 2018 thanks to API security lapses—which is why we dedicated several articles to helping enterprises make their APIs more secure. Some of our top security articles include:

Managing APIs as products

2018 saw more enterprise leaders recognize that APIs are not just an integration technology but also software products that help developers to more quickly and easily leverage and reuse digital assets. Enterprises should apply full lifecycle management and a customer-centric mindset to their API efforts. Some of the articles we wrote to help include:

Digital transformation, IT modernization, and digital ecosystem best practices

The digital economy moves faster than many legacy businesses are used to—and the constant change has meant that to compete, enterprises that lack API expertise have had to get up to speed quickly. From exploring why both external-facing and internal-facing APIs should be managed as products to detailing how to plan effective ecosystem participation and API monetization, we looked at many aspects of the digital transformation puzzle:


Because of the speed, scale, and agility they promise, microservices-based architectures continued in 2018 to be one of enterprise IT’s hottest topics. But despite the enthusiasm, microservices remain complicated to manage. To understand why APIs are an important part of the mix, check out Demystifying Microservices by Ruth Gantly in APIs and Digital Transformation.

APIs and banking

With new open banking requirements unrolling across many regions and fintech startups gaining traction around the world, 2018 was a disruptive year for bankers. From satisfying regulations to innovating faster and adding new ecosystem partners, APIs play vital roles in helping financial institutions to debut and iterate new services and helping legacy banks to compete in an increasingly fast-moving market. Some of our top banking articles from 2018 include:

API Team Best Practices: Championing Business Value

Previously in this series of blog posts, we discussed why the developer portal and analytics are important to the success of API teams and API programs. Here we’ll wrap up the series with a discussion of more key competencies of the API team, and what to keep in mind as your team matures.

KPIs, iteration, and monetization

An API’s first lifecycle ends with iteration and should be accompanied by a maturing ability to communicate the API’s business value and an API roadmap that evolves in response to developer feedback. This process involves several API team competencies:

  • Define the right KPIs To turn API consumption data into actionable insights or persuasive measures of the team’s value, the team must define KPIs that connect consumption to revenue, customer growth, or some other core business KPI.
  • Manage iteration Once an API has been in the wild with developers for a short period, the team should assess data to plan iterations. Is performance suffering because too many calls are involved? Do developers require additional features to make better use of the API product? If a team is managing its first API and funding has already been secured, the process of addressing these questions might be somewhat straightforward. For more mature programs juggling lifecycles for multiple API products, establishing the right feature backlog processes and development cadence may be crucial
  • Consider monetization Many organizations drive adoption by releasing APIs that give developers basic or full functionality at no cost. APIs that allow access to particularly valuable data or functions, however, may be good candidates for monetization.

What’s next

You might be assembling your organization’s first API team or working to optimize a team that already exists. Either way, a great way to move forward is to identify and scrutinize the characteristics of a project mindset, versus those of a product mindset (see the graphic below). Then, use your understanding of the product mindset to align collaborators, distribute responsibilities, and develop a culture of fast, customer-obsessed iteration.

At many of the most successful companies, leaders throughout the business (and not just technical leaders) understand the value proposition of APIs. However, the API team might struggle to garner the resources it needs, let alone to drive API adoption, if leaders don’t understand and throw strong support behind the team’s efforts. To increase support among leaders, remember the power of KPIs that show how API consumption has impacted customer satisfaction, revenue, or growth.

As your team matures, consider broadening its horizons to new use cases that can unlock new business opportunities. If you’ve been focused on internal APIs that accelerate development of new products, you might expose an API to harness innovation by external developers. Some teams might consider turning API products into a revenue stream and packaging them into monetizable bundles that serve particular developer needs. Virtually all businesses want to move faster.

Most have systems and functions they want to use more efficiently. Many have data full of value just waiting to be unlocked. The vast majority want to accelerate partner participation so they can focus on what they do best while relying on others to help fill go-to-market gaps and provide scale—and so they can better serve their customers. APIs designed, delivered, and managed as products can help with all of these things.

They can make a company’s valuable assets and capabilities available for developer creativity. They can eliminate redundancies and accelerate development. API products can open an organization to new partners and ecosystems. And they can do all of these things fast. The journey starts with getting the first API product on the roadmap.

Whatever path an organization’s APIs take, the point is this: because APIs are increasingly how business gets done, they’ve become a fixture not only in IT conversations, but also in the boardroom. Enterprises that approach APIs strategically—with a product mindset—are poised to thrive in today’s economy.

Thanks for reading this blog series. To learn more, read the eBook, “The API Product Mindset.”


API Team Best Practices: Curating a World-class Developer Experience

In this blog series, we’ve discussed key personas on the API team and the importance of designing and releasing quality minimum viable product APIs.

Next, API teams can prime themselves for success across the API lifecycle by focusing on three important areas: the developer portal, monitoring and analyzing performance and consumption patterns, and promoting API evangelism.

Establish a developer portal to drive adoption

The faster a developer can go from accessing an API to creating a new experience or service, the more information an API team can gain about its customers and new business opportunities.

Businesses can significantly improve time to market by investing in a developer portal that facilitates easy access to well-documented APIs, testing tools, blog posts, forums, and other features to encourage easy consumption.

Thomas Squeo, senior vice president at Google customer West Corp., recently described the developer portal as “the primary interaction point where somebody can go from awareness to activation to acquisition for an API and be able to bring it up to a ‘hello world’ within maybe 30 minutes.”

Monitor performance

Developers’ apps and services only work if the underlying APIs do— so it’s vital to monitor performance, ensure that SLAs are being maintained, and protect against abuse.

Proactive monitoring of API traffic also conditions the team to focus on measures of consumption rather than measures of completion—and to start identifying problems and wins and charting possible paths for the API’s iteration.

Invest in API evangelism

In the world of API products, there is no “if you build it, they will come.”

For external APIs, the API team needs to establish a presence in the communities where developers already congregate, whether that’s forums, meetup groups, or conferences. The team should support its APIs with marketing and promotion, whether it’s targeted ads buys or webinars with influencers or thought leadership content.

For all APIs, including internal releases, the team needs to sell developers on adoption, which means making the value proposition clear, providing tools that make the API easy to use and experiment with, and creating feedback loops with API consumers. Developers are the API team’s direct customer, so the team should expend significant effort understanding developer needs and catering to their preferences.

Coming up next, we’ll wrap up this series by exploring the importance of championing the business value of APIs.

To learn more about API teams and managing APIs as products, download the eBook, The API Product Mindset.


API Team Best Practices: Building a Minimum Viable Product

In previous posts in this series, we discussed the key personas that make up an API team. Here, we look at at building a minimum viable product—a key objective the team should target in order to build an effective digital value chain, and one that brings uniformity to the API creation process.

The digital value chain

One of an API team’s first steps should be to ensure that APIs are designed and created for consumption, and that access to systems of record and other back-end data is provided in a consistent way.

The API team should think of itself as a refinery that sits between the raw materials housed in back-end systems and the API products that present those raw materials as polished interfaces that developers can easily use. When you layer a mature API product mindset on top of the API team’s core responsibilities, the graphic above grows into the full “digital value chain” represented below.  

The chain emphasizes the two key customers whose experiences the API team directly impacts and who should form the focus of the API team’s obsession with customers: developers and the end users for whom developers create apps and experiences.

To create an effective value chain, the API team should focus on three practical objectives: building a minimum viable product, curating a world-class developer experience, and championing the business value of APIs (we'll look at the latter two objectives in an upcoming post).

Building an MVP

Full lifecycle API management involves all of the things it takes to get an API up and running and into the hands of developers, so that they can both begin innovating and start providing feedback to inform how the API is iterated upon over time. Though the numerous stages of the lifecycle may suggest a lengthy process, remember: speed is the goal. The lifecycle should focus on releasing MVPs that present the core value proposition to developers and can be rapidly scaled or improved based on user feedback.

API teams should not expect all MVPs to succeed. The point is to launch more releases than would have been possible using legacy approaches and to quickly realize which ones are gaining adoption and which experiments justify additional investment. Some experiments will fail, but those that succeed may represent not only new products but gateways to entirely new business models.

When managing the lifecycle of these MVPs, keep these principles in mind:

  • Build APIs developers love and that are easy to use Design according to RESTful best practices, focused on consumption and consistency, and provide a clear statement of the value proposition the API represents to developers. Avoid premature optimization and hide unnecessary complexity from developers. Remember, developers likely do not have time to learn the inner workings of your system and should not need to: they simply want the data they need to enrich their application.
  • Protect your APIs Enforce a consistent set of security policies and protocols across all APIs—private and public. Employ authentication like OAuth/OpenID Connect in conjunction with transport layer encryption (TLS) to protect data and control who accesses it, and consider spike arrests and per-app usage quotas to help maintain API performance.
  • Test and deploy APIs Synchronize the API lifecycle with a modern, agile, iterative software development lifecycle (SDLC) and automate API testing and deployment.

Coming up next, we’ll discuss two other key objectives of the API team: creating an excellent developer experience and championing business value.

To learn more about API teams and managing APIs as products, download the eBook, The API Product Mindset.


API Team Best Practices: Developers, Evangelists, and Champions

In the previous post in this series about API teams, we explored the API product manager and API architect roles. Here, we’ll describe characteristics of three other key personas on the team: the API developer, the API evangelist, and the API champion.

The API developer

If the architect creates the plans and drafts for the construction of the API, the API developer is the actual builder—the person who brings the wants and needs of the API consumer or application developer to fruition. Their goal is to produce intuitive and highly consumable APIs. They fulfill this goal not only by building the API itself but also by contributing to resources that will help developers most effectively leverage the API, such as documentation.

The API developer should be an expert web developer, well-versed in both consumption- and exposure-oriented API development. They should have a strong understanding of the ins and outs of the API management platform to implement security policies, traffic management, and other protocols that support the scaling of APIs per standards consistent across the organization.

The API evangelist

Like any product evangelist, the API evangelist is the voice of API consumers. The evangelist should deeply understand developers and ensure they have all the things they need to be successful. This role is responsible for the vital task of managing the developer portal and ensuring developers have access to detailed information on the product offering, including documentation and software development kits (SDKs).

They are responsible for internal and external developer outreach. This outreach might include not only answering questions, running hackathons, and bringing developer feedback to the API team to inform and support product roadmap discussions, but also marketing the APIs via SEO, targeted ads, and other methods.

Evangelists can play a crucial role in attracting partners to the company’s APIs and thus in expanding the ecosystem of participants leveraging the company’s offering. Great API evangelists have a passion for seeing their team’s work blossom into the applications that serve the end user.

Walgreens developer evangelist Drew Schweinfurth describes how API management helps him do his job

The API champion

The API champion is to the executive boardroom or the lines of business what the API evangelist is to developers. They connect an organization’s API programs to the business value they provide by translating data points that may only make sense to technical leaders into metrics that track directly to important company goals—like increasing customer satisfaction.

They enlist strong support from executive sponsors who have the ability to provide the funding and resources API teams need to be successful. They should be analytical thinkers and powerful influencers that can develop strategic business goals while paying attention to the technical capabilities of an API product offering.

They should always understand how the business benefits of API products apply to app developers and customers as well. They should ensure the team continues to move in an agile fashion, so the organization can get more MVPs to market and open the door to possible new lines of business.

Though described here (and in the previous post) as discrete roles, each of the API team personas might not manifest in just one person. For example, at some organizations, the duties of the API product manager also encompass the responsibilities of the API champion. At other companies, it’s better for the product manager to focus on the technical aspect of API products while the API champion focuses on communicating business value.

Coming up next, we’ll discuss three important objectives of the API team.

Learn more about managing APIs as products. Download our eBook, The API Product Mindset


API Team Best Practices: The API Product Manager & the API Architect

How do you help instill a customer-centric way of thinking for building and managing APIs? How do you operationalize rapid delivery of APIs that empower developers? How do you create an API program that evolves to meet customer needs and holds strong in a world with ever-changing innovations and fierce competition?

Answering these questions starts with the API team. Every organization’s team looks a little different, but in working with hundreds of customers, we’ve found a set of roles that are common to many. In this first post in a short series about the characteristics and best practices of API teams, we’ll describe two key members of the team: the API product manager and the API architect.

Why build an API team?

Many enterprises might not have an established API team or even an API product manager—even if they are already developing APIs. At some organizations, it might not make sense to have a centralized team. In some enterprises, the makeup of the API team and the enumeration of responsibilities may change as the business evolves, starting with less centralization and gradually shifting into a dedicated unit with more precisely defined roles.

For some, this might be the first time they’ve heard the concept of an API team and the role of the API product manager. No matter where you stand, it’s critical to find and organize the resources needed to execute on the roles and responsibilities that live within the API team.

Whether that manifests as an organizational unit or a loosely coupled group of people from across different teams, the team is responsible for understanding the needs of customers—and helping the enterprise deliver on the promise of managing APIs as products that will provide developers with the tools they need to create breakthrough experiences for end users.

The API team manages APIs across their entire API lifecycle, including productization and, in some cases, monetization. API product managers are at the heart of managing, supporting, and optimizing the team’s workflows—they are the engine that keeps the process of new releases, iteration, and customer obsession running. This requires understanding and implementing best practices and recommendations across each stage of the API lifecycle.

API Product Manager

The API product manager

The API product manager is responsible for putting the cross-functional conversations and activities in place to help an organization develop its vision for API products. The manager turns this vision into action by managing each stage of the API product lifecycle, prioritized by API consumption data and other feedback from API consumers and customers.

The product manager is the subject matter expert of the API product, deeply understands its technical specifications and benefits, and can effectively communicate those benefits to others—including colleagues and executives on the business side of the enterprise. Depending on the organization, their responsibilities may include running scrum meetings, prioritizing a features backlog, defining the right KPIs, preparing partner presentations, or helping launch the API into wider ecosystems.

Api Team Architect

The API architect

Like the architect that drafts the plans for a house, the API architect is responsible for planning, designing, and reviewing the construction of APIs. They guide the creation of APIs and the development and testing required to meet the highest standards in API design. Architects should clearly understand the difference between API products designed for consumption and API products designed for exposure. They might be responsible for understanding the details of underlying systems or liaising with back-end teams that do. Their work should reflect an understanding for how it affects other members of the API management team as well as the developers consuming the API.

Coming up next, we’ll explore three more key roles on the API team: the API developer, the API evangelist, and the API champion.

Want to learn more about managing APIs as products? Download our eBook, The API Product Mindset

Moving Faster with a Product Mindset

In 2007, the movie I Am Legend featured a memorable scene in which Will Smith’s character, the only human in a post-apocalyptic Manhattan populated by vampires, pretends to rent a movie from an abandoned video store, attempting to inject some normalcy into the wasteland he now call home.

Today, just over a decade later, the scene feels a bit like an artefact. Smith is still fighting monsters but on smaller screens, and far from being the quintessence of normal life, video stores are almost extinct, replaced by streaming services and mobile downloads. We’re willing to bet that few people settling into theaters back then would have guessed so much would change so quickly — not just in entertainment but across most of society:

  • As shopping and social activities have moved online, malls (many of which housed the theaters with those I Am Legend screenings) are closing in large numbers.
  • Car ownership has grown increasingly optional due not only to ride-sharing but also an app economy that’s made existing public transportation infrastructure more convenient and usable.
  • Financial management is becoming more likely to occur on a device than in a bank branch.
  • We went from typing at our devices to swiping and touching their screens — and now, we’re increasingly talking to them too.
  • Rather than setting alarms or straining to finish the millionth email of the day, some of us have begun to rely on machine intelligence to remind us when to leave or to suggest the right phrase.

The examples could go on, but they all add up to the same idea: today’s economy is being impacted by several large-scale tech disruptions simultaneously, which means it’s moving and evolving faster than ever.Businesses that want to survive, let alone compete, have to do the same.

Obviously, accelerating a business is easier said than done. Many enterprises have spent mightily on digital transformation initiatives in recent years, and not all of them have seen the results they’ve wanted.

In our experience working with large enterprises on their digital transformation initiatives, we’ve seen that the companies that move fastest typically don’t just invest in technology projects—they leverage technology with a product mindset.

What is the IT product mindset?

To understand the IT product mindset, it’s useful to start with its opposite — the project mindset.

The project mindset is present in some form or another at most businesses. Enterprises will always embark on projects, but the potential problem with a dominant project mindset is that projects start and stop. They are discrete, and if they evolve, those evolutions arrive in big, monolithic chunks. Projects are fine — but if the project mindset rules over software development, the business might not be.

In this way of operating, project managers generally move on when the project is over. They often work under governance models that make project requirements difficult to change once they’ve been collected. Their work is often judged by completion, and if there is a post-mortem to discuss how the project was received, it’s often to inform future work, not to update the original project.

This IT mindset was tenable when enterprises had the luxury of moving relatively cautiously and deliberately, but it can’t keep pace with today’s economy. Companies that want to move faster will find it increasingly difficult to bolt a bunch of small, discrete technology projects onto the existing business and create a whole greater than the sum of the parts.

Evolution didn’t just sew wings onto dinosaurs — it evolved some of them into birds in a continuous feedback cycle. Businesses must evolve similarly — but much, much faster. Nature’s feedback loops can span millennia, but those in today’s digital economies are measured in hours, minutes, and even fractions of a second.

All of this is to say, real digital transformation isn’t about the number of projects a company completes. Rather, it’s about whether an enterprise harnesses technology to continuously and iteratively evolve how the business operates and how it delivers value to customers and partners. It’s not about an app or a new digital channel — it’s about technology becoming indistinguishable from the business because technology continually enables different ways of operating.

Compared to legacy project-minded approaches, this idea of perpetual agility and evolution is a fundamentally different mindset — a product mindset.

Yes, product-minded businesses still complete IT projects, but rather than moving in large, centrally-managed teams, they rely more on smaller “two pizza” teams. Each of these teams is continuously responsible for something crucial to the business, granted the governance autonomy to move quickly and independently, and able collaborate with other teams’ work via application programming interfaces, or APIs.

Among many impacts, having these smaller, more agile teams can mean that many things that might have once been neglected projects within a huge, lumbering legacy application are now products continually managed, maintained, and improved by small, nimble groups. The perspective within these teams isn’t driven by completing projects and moving on to new ones — it’s driven by collecting data about releases, then iterating on them or scaling them down as appropriate.

In the past, for example, creating an API would have been a project that connected systems within a single application. Today, that API should bemaintained by a product team focused on making that API easy for developers to use, opening it up to be leveraged in many apps.

The product mindset, in other words, turns the API from a systems integration project to a digital asset that can provide ongoing value. It’s the difference between end users having navigational capabilities in a few applications and end users having navigational capabilities in many apps plus new industries, such as ridesharing, that were nurtured on publicly available mapping API products.

Tips to move faster and instill an IT product mindset

Businesses looking to implement an IT product mindset and begin evolving faster should focus on three core tenets:

  • Outside-in thinking: The product mindset is customer-driven and obsessed with improving the customer experience. Inside-out thinkers derive strategies largely from internal intuition and the resources that IT says are already available. Outside-in thinkers starts by asking what the customer needs, then building strategies from there. Because customer preference never stands still, an outside-in perspective is constantly evolving and hungry for new data.
  • Minimum viable products: Project-minded companies often over-optimize their releases, potentially wasting time and resources on edge use cases before testing whether the core idea is even viable. Product-minded companies emphasize minimum viable products (MVPs) so they can get an idea to market quickly, begin understanding how users are interacting with releases, then use this understanding to make improvements.
  • Iteration: As the above tenets note, the IT product mindset is focused on improving customer experiences through iteration. This requires increasingly diverse forms of intelligence, from “soft” data collected via direct interaction with customers to “hard” data collected at the API layer to machine learning algorithms that help automate the improvement of products. In today’s economy, companies must be data-driven to move fast with confidence.

Remember: it’s not just about the technology

When we talk about technology evolving the business, we mean the whole business.

Think about the ripple effect from those small teams wementioned. These teams are generally necessary if a business wants to move fast, but to support them, the company may have to change its governance and operational processes, decentralizing them so that data is still protected but more autonomy exists within individual teams. It may need to change its technology infrastructure to ensure these teams can move independent of one another, without one team’s work creating dependencies that slow down another’s. And it may need to change metrics and incentives processes that were focused on completion to those that encourage analysis and iteration.

Moving fast is inextricable from digital transformation, and “digital” is inextricable from the entire business. It’s all connected — and in many ways, it starts by shifting from a project-minded approach to a product-minded one.

Why APIs Are Products—Not One-off Projects

Webcast replay

While it’s tempting to deploy an API as a one-time fix, leading companies have stopped thinking of APIs as special projects with limited extensibility. There’s been a dramatic shift: APIs are now seen as strategic products for developers, with full lifecycles and long-term roadmaps that evolve to meet business needs.

In this webcast replay, learn how companies are creating specialized teams to design, deliver, and manage API products. We explore why APIs are a hot topic not only in IT conversations, but also in the boardroom.

We also discuss:  

  • How to avoid big mistakes that limit success in the experience-driven economy
  • Why customer obsession is essential to building APIs that evolve
  • Why growth starts with APIs that are easy for developers to consume
  • How to move fast and build your first minimum viable API product
  • Why your API team should bring together business and IT stakeholders

To learn more about how to design and manage APIs as full lifecycle products that empower developers, download the new eBook The API Product Mindset.

The Not-So-Secret Strategy Behind Walgreens’ Ecosystem Advantage

Sometimes, strategic advantage relies on concealment. The formula for Coca-Cola, for example, is a famously well-kept secret.

In other cases, a company's secret advantage is as plain as day, and their success is premised on focused execution (as well as, perhaps, competitors hesitating to pick up the gauntlet and raise their game to the same level).

Consider Amazon’s emphasis on its third-party retail marketplace—a not-so-concealed strategy. In his 2014 shareholder letter, Amazon CEO Jeff Bezos made no bones about the scope and scale of the company’s third-party marketplace and the importance of the positive network effects it generates (the “Amazon flywheel,” as he calls them) to the company’s overall strategy.

Fast forward to 2016. Traditional retail giant Walmart now has a third-party marketplace of its own. Touting more than 20 million items (and even making the CEO’s latest earnings call highlight reel), the brick-and-mortar juggernaut’s third-party marketplace is certainly making progress—but it still pales in comparison to Amazon’s 365 million.

Turning digital into strategic advantage

For businesses with roots in brick and mortar, the Amazon versus Walmart story should serve as a cautionary tale. The lesson is simple: when it comes to digital, playing catch-up is often a lost cause. The key to digital isn’t replicating what your competitors are doing—it’s expanding into new lines of digital business by leveraging digital assets in unique and innovative ways.

Those looking for inspiration should consider looking to Walgreens as a company to study alongside Amazon for tips on turning digital into a strategic advantage.

Like me, you may already have a sense of the Walgreens physical-world strategy from simply walking around your neighborhood or visiting different cities: the company’s stores are located within five minutes of a staggering 76 percent of the U.S. population. Walgreens’ digital strategy complements it well: my favorite pithy (but accurate) articulation highlighting a key component of their digital strategy is “putting an API around the stores.”

It's not rocket science

They have a clear vision for making digital and physical experiences “better together.” But the beauty of Walgreens as a case study is that the “secret sauce” to their success isn’t Silicon Valley voodoo or the stuff of science fiction. It comes from focused execution that is within the reach of any enterprise.

I wanted to understand Walgreens’ approach in greater detail, so I spoke with Drew Schweinfurth, developer evangelist at Walgreens and one of the key people behind the company’s successful and growing developer ecosystem—now well into the hundreds.

Drew spends many of his days having conversations with different lines of Walgreens business to identify high-impact products to take to market. However, in this case the products are digital services and the market being served consists of potential consumers of the APIs with which they’re implemented.

Finding the sweet spot

What struck me about Drew is that he’s not a geek — he’s a brilliant, good-old-fashioned product manager (although, to be sure, he does have some serious “geek cred”). Now, while being a geek may help a great deal when it comes to attracting developers, for Drew, it’s all about finding the sweet spot across value to the business, feasibility, and marketability—classic product management.

Finding these digital sweet spots isn’t an exact science for Drew—not all bets have paid off big—but the trajectory is impressive. It’s also all out in the open on the Walgreens developer blog.

Consider the Heart Partner app from Novartis, which helps heart failure patients coordinate care and monitor vital signs, medication compliance, and activity—with the added incentive and reward of loyalty points from Walgreens' loyalty program, of course, thanks to the Balance Rewards API.

Novartis is one of 50 fitness and health partners tapping this API. Similarly, more than 100 partners are printing photos in Walgreens stores via the Photo Prints API.

Building for externalization and scale

So where did this supply of digital services come from? Did Walgreens have to hire hundreds or thousands of developer evangelists to roam the halls of its corporate offices, infusing thousands of employees with Silicon Valley mojo? Nope.

To the contrary, filling the pipeline took only a strong will and few words. Walgreens leadership told every technology team at the company to build for "web scale"—that is, to build the internal services they felt were needed, and to build them to scale across an external ecosystem.

The internal teams were not required to know anything about developer evangelism or digital service product management. They simply needed direction to build digital products with the potential for externalization—which, in our cloud- and microservices-centric world, is simply good practice anyway!

As Drew describes it, “Our team is the toaster. We ask other teams to give us bread, and then we make toast. We just need the power supply to keep delivering.”

Walgreens’ success highlights the path every leadership team can follow to achieve focused digital execution:

  • Every enterprise knows how to set standards
  • Every enterprise knows how to do product management
  • Every enterprise has the wherewithal to hire a few strategically placed and empowered geeks

It follows from these three premises that most enterprises have the power to use APIs that deliver digital services that move the needle on revenue and brand equity—which means that winning scores of third-party partners ought to be within their grasps too. 

Unless, that is, there’s a barrier concealed within the organization: something like a hidden strategic disadvantage. If that’s the case, now might be a good time to identify it, root it out, and raise your digital ecosystem game.

This post originally appeared in CIO.com.

Image credit: Walgreens

API Product Management: Driving Success through the Value Chain (slides & video)

Thanks to all who attended the API Product Management: Driving Success through the Value Chain Webinar.

Video and slides are here. Thanks to @jenmazzon, @sramji and a big thanks to our special guest host, Michael Hart @michaelhart. As always, we'd love more of your thoughts, insights, or questions on the api-craft forum.