How do you build an API strategy ?
API's are in fashion these days. So much so that even those who know very little about it, keep talking about it at every opportune moment.
For years, only nerdy developers would be stoked about an application programming interface, but with the boom in social, mobile and cloud technologies, APIs have transcended to become a new product channel for many organizations who are either delivering services or content as a product. It has also become a precursor, towards building a good brand mobile and social strategy.
Building a good website or a great mobile application is a good place to start. But it’s no longer a business differentiator. If the platform you create is really good and you can fork it’s API to be used by partners/ consumers for needs of their own, then demand for that API would be a better metric, than traffic which comes to this web platform.
Let’s elucidate with an example.
Imagine you are a brand and you have a website which you work hard at, to keep alive with fresh and relevant content. Now you can do a lot of banner/ display/ search to drive traffic and showcase engagement. You can also partner with third party sites and do content syndication.
But that is treating the internet in the way we looked at it in1990.
For the sake of argument, let’s now imagine that you work towards creating a custom API on the content platform of your website. It’s a simple query based API which allows partners ( based on tag words) to pull relevant content/ assets from your website into somebody else’s website/ portal who needs that kind of relevant content.
All of this in a frictionless manner and free of cost.
So imagine you have great content on Cloud Computing. Now imagine the millions of news sites, tech blogs, portals, expert sites, channel media sites which are creating endless content pieces on cloud, every single day. They are hungry for content. What if, they could use your API to align all your cloud content through a simple click of a button onto their site ?
You may think that you are loosing out on traffic, but in reality, what happens is that your brand and its idea’s get carried by other sites and shared across the world - all at a click of a button. It is far more valuable than traffic which can be very difficult to define in terms of relevancy.
Remember that small “Like” button on Facebook. That little blue button did more for Facebook’s brand marketing than billion’s of dollars in advertising and search could ever have done.
And all at no cost.
That then brings the next big question? Is API a fancy tactic to showcase on a best practice presentation deck on marketing? Or is it a larger strategy that the brand needs to undertake ?
The answer differs based on the business your brand is in. If your brand is in the realm of services and needs to appeal to the developer community who can use your backend to create custom applications aimed at delivering services from your portfolio, then yes you need to think of a API strategy.
To promote your own brand and service.
But if the business requirement is just to penetrate devices and mediums where one can experience your brand, then no- all you need is a tactical approach.
Let’s elucidate with another example:
“Brand A” decides to create it’s API as a product, designed to offer incentives to developers to motivate them to build applications around “Brand A” experience. These applications would hopefully reach new audiences to generate new subscribers and/or create new user experiences for existing subscribers that would increase their satisfaction with “Brand A” service.
This is an example of API as a strategy. The challenges though are enormous. The greatest one being - in this approach your end customer in many cases is the developer, not your brands end-user and that can be a tricky situation, if you cannot manage it well. Public and independent developers don’t always understand your brand and what it aims to achieve. They look at their own benefit. Also if your initial service or product on which the API is built is not good enough, then it’s a recipe for disaster.
Now let’s take “Brand B”. “Brand B” has a simple objective. To penetrate and seed it’s content experience on more than a 1,000 different device types. For Brand B content is its service. For this they need to understand all the devices and mediums which are relevant to them from an audience standpoint and create or use, tactical API’s which allow those devices to seamlessly stream “Brand B” content.
This is an example of API as a tactic. The challenges here are lesser and more diversified. To starts with, there are no allegiances and with changing business requirements, API calls can be changed on the go at almost no cost and no latency. In this approach “Brand B” is concerned only about two things. Building or using API’s to suit only its own benefits and looking at maximum device/ medium penetration for its content.
The Key to success in an API program is simple - KNOW YOUR AUDIENCE.
Your audience should define your API.
Not your agency.
Not your vendor.
Not your channel partner.
Not your developer.
At a tactical level the one thing to remember, is that those who are leasing out their content API’s to you are smart. They are promoting their brand at your expense with zero expense at their end. They are not bothered about your audience. They in many cases ( not all) also do not have a very clear idea on what they can customize to help you with your audience. They have only one objective.
Understand the devices and the mediums. Understand how your audience likes to consume content in those devices and mediums. Use the API and your platform UI to customize your content relevantly for that specific device or medium.
Create an orchestration layer ( OL) over a One Size Fits All ( OSFA Foundation) to specifically respond to Device Specific Wrappers, Query based APIs and Experience Based API’s.
The end-user is the king. The developer is just a conduit while the API is just a delivery mechanism.
And when it comes to the end-user, he engages with your brand either through devices ( hence Device Specific Wrappers), search ( hence Query Based API’s) and UX ( hence experience based API’s).
Otherwise it would be an exercise in vain with some vague engagement metrics and a power point presentation for internal congratulatory memos, but no real impact.