The API Product Imperative
Global Kinetic Discovery Team
APIs in banking. Less work for more money. Why wouldn’t you do it?
— Chris Skinner, speaking at Dot Finance Africa 2017
Banks and other service providers no longer develop open application programming interfaces (APIs) just for themselves; they’re making many of them available to external parties, driving revenue growth and spurring innovation through XaaS (anything-as-a-service) and other emerging delivery models.
The pluses to publishing open APIs will be familiar to readers of this blog. In short, public or partner APIs help businesses gain access to new and previously hard to reach markets; build partnerships to fill gaps in their existing offerings (while focusing on what they do best); unlock all-new revenue streams, including by monetizing assets like all the data they have squirreled away; consume a lot more data via third-party products and services, aiding decision making; and drive ecosystem-wide innovation and product development. And all of this new business potential can be gained remarkably quickly.
That’s why the C-suite is becoming so invested in something that was once the exclusive domain of the IT peeps many floors down from the boardroom: APIs are now big business.
“I don’t think you understand what API means”
In the API space, we build something on a machine for a machine to use and this is wrong because there are people on the other side of API clients.
— Ronnie Mitra, director of technology at Publicis Sapient
But old mindsets die hard, both on the top floor and below. Leadership may struggle to understand the business value, remaining attached to an idea of the enterprise as a monolith or hive, a proudly independent brand and developer of proprietary products and services – not a platform, not an embedded-as-a-service-thingamagig.
Some in the engineering department might, meanwhile, find it hard to look beyond the technology to the user or the consumer. Here’s an exchange we found on LinkedIn a short while back, purely by chance.
Even product owners and other internal API champions sometimes make the mistake of focusing on the features and functionality in their pitch to decision-makers, rather than on the real problems they could solve for real people.
Yes, an API is a conduit for data to be consumed by a machine, but in the API-powered worlds of finance and business services, the actual user is a developer working on a service or product targeted at an equally human agent.
If APIs are mirrors of the organizations that made them, what do yours say about you?
Developers are users too.
— Jeff Atwood, Coding Horror
Businesses – some of them very large – have launched APIs with much fanfare, only to end up perplexed when pickup has proved slow. It shouldn’t be that much of a mystery, though.
Rushing API development or discounting the importance of design thinking, organizations fall foul of Conway’s Law, encoding their present and past communication structures and ways of working in the software. For the outsider, decades of complexity are surfaced like layers of sedimentary rock. There’s little consistency, adherence to widely known standards, guidelines or documentation that actually describes the reality below the surface.
A fossil protrudes. A thigh bone, then a hip bone, perhaps a backbone… How’s it all fit together? Who knows! Inside the organization, initiates learned the arcane workings of the system at the feet of their elders – but, out in the world, users are left to figure it out on their own. (And if they can’t understand the API, they can’t assess product fit and make an informed buying decision. Who needs the stress; wouldn’t you just move on to testing another product, one with fewer skeletons?)
So much time, money, and creativity have been spent on the user experience of consumer-facing technologies, but the same cannot be said for the huge number of APIs out there. “User experience and product design frameworks are typically geared towards supporting graphical rather than application interfaces,” says Lorén Rose, Global Kinetic’s chief operations officer. “As a result, designers often default to an inside-out approach, resulting in APIs that mimic backend systems, rather than an outside-in approach that aims to meet the needs of the end user.”
APIs as products, not integration projects
You’ve got to start with the customer experience and work back toward the technology – not the other way around.
— Steve Jobs, speaking at the 1997 Worldwide Developer Conference
An outside-in approach – you could also call it a design-first API strategy – places the user and their experience at the center of everything the API product developer does. Working from the detailed user personas you develop as part of the process helps you pitch the product and market it effectively later. Most importantly, it ensures that the API is accessible, simple to use, and meets industry expectations around interoperability, so that it has a fighting chance in the burgeoning API market.
“Your API designer has to have a good understanding of user behavior to craft experiences that hasten adoption and to iterate on that foundation,” Lorén says. “A lot of businesses continue to regard APIs primarily from the point of view of integration, which will only ever end in tears.”
On the other hand, when you develop APIs as you would any other consumer-facing product, and you do it well, you position users – your customers – for success. And successful customers draw other customers, who bring in more business and more revenue for your organization.
Looking to build out your API strategy? Contact Global Kinetic – we can do this for you.