I’d like to share some of the myths and misconceptions I come across in my travels on telco APIs and more generally service innovation.

1) Twilio and Apigee are used in the same breath, as if they’re the same proposition.

Twilio is an API publisher, this article from 2012 explains the difference. There’s a strong Twilio community focused on the use of their platform, almost a cult of the red hoody jacket, ahoy 😉 Apigee is API management, its a layer of functionality within API publishing, its Apigee’s customers who are the API publishers. Apigee sells software (as a service) with lots of professional services thrown in for the telcos.

2) “We want to Monetize our APIs!”

An API is just a small piece of technology, its what is exposed through the API that matters more, whether it be a service like ‘pay by mobile’ or ‘profile information’. You can put an API on most services and information.  The key is to focus on the customer value and business generated from using that service or information. APIs are simply a lubricant to aiding business relationships; it removes an integration barrier so we can experiment faster and at much lower cost.

For most relevant-to-telco developers, the channel to market provided by a telco matters more than a particular API. The bottom line is its all about the services (customer value) and bundles a telco can make possible.  In being a channel to market the services could be telco-branded, co-branded, or third-party branded.  There is no pre-defined one size fits all.  For example, with Dialog the services in Idea Mart are third party branded, while we’re seeing communication services like click to call being telco branded.

A challenge in focusing on specific opportunities rather than a generic API platform capability is the revenues get much smaller. But its better we invest appropriately for a few smaller yet realizable revenues, than invest large sums in the hope “build it and they will come” as one thing we’ve learned is “they will not.”

3) “We need developers to tell us their requirements for our APIs.”

Firstly, for most relevant independent developers its not your APIs they are interested in, its your channel to market. Secondly, just copy those APIs already working. Thirdly, focus on what you in your market can do that has value for your customers. Fourthly, for your business customers its not about the APIs, its the services or enhancements to their business processes made possible. Focus on the services (end customer value), not some wishful-thinking platform-play that a MBA graduate with no relevant business experience produced as part of an over-priced management consultancy project.

4) OneAPI and OneAPI Exchange

At least the GSMA is no longer telling telcos to offer OneAPI to third parties, rather, just use it for internal innovation, which is usual dumbass compromise to save GSMA face. Telcos must eat their own dog food and use modern well-written APIs that are evolving (APIs evolve in internet time); not some telco dinosaur API written over a decade ago.

OneAPI Exchange perpetuates the myth that its all about the APIs. Its about the services and channel to market, with APIs simply being one of a number of technologies making new business relationships and services possible. There are lots of global Telco APIs available, its going to be tough for telcos to compete with Nexmo, Tropo, Tyntec, Twilio, etc. who deliver Telco APIs that are easy to consume, global, and with great support.

5) “Why are developers in the Apple and Android app stores going to use Telco APIs?”

Put simply, they are not.  The game is over with that segment of developers, don’t go there.  They have direct access to a large (coming up to 2B devices) engaged user base. Focus elsewhere, look at all the innovations presented in the TADHack YouTube channel for inspiration.

6) “But why don’t they just go direct, why do they need us?”

Winning potential customer attention, then winning their business, and then keeping that business is expensive and time consuming, especially for business customers in other countries. Telcos have unprecedented access to all types of potential customers within their countries of operation.

This is the hardest point I find to explain, and generally prompts the litany of excuses discussed back in 2010.  More effort is required by telcos around their ability to be a channel to market for a range of ICT services across all the different types of customers they serve.  I am seeing companies emerging that are focused on solving this problem, we’ll discuss it in more depth at TADSummit.

7) “Its all a waste of time, this service innovation stuff, Apps stores have won.”

A smartphone app is generally either a game or mobile (handheld computer form factor) access to a service on the web. The app store is simply one of many possible channels to market.  They are generally a channel to the consumer market, though the enterprise segment is growing through partnerships, e.g. Apple and IBM. A service provider can sell through their web sites, direct and indirect sales forces, any app store, in high street stores, social networks, anywhere there is a relevant platform that reaches an addressable customer segment.  App stores have not won, they are simply a channel, its all about the services, this is where we need to focus.

Telcos were in the consumer app store business over a decade ago with ringtones, games (generally J2ME, Java 2 Micro Edition), and wallpapers. But that business is now lost, only CRBT (Caller Ring Back Tone) and markets where feature phones are still significant percentage have relevance. Don’t focus on lost business, focus on where new business can be created.  Yes, it is hard work to build new business, but that is where the margin resides.

8) “Why will developers use our APIs which are just for our network / customers?”

Generally, they will not. If a developer wants global or country-wide messaging or voice capabilities or bill to mobile, there are existing global providers with easy to use APIs and good customer support. The limitations of APIs offered by telcos limits the addressable markets. The key is to focus on the unique value, and build businesses around that, rather than trying to copy Nexmo or Twilio’s business.

9) Using examples in one market as a global proof-point

When someone quotes DoCoMo or AT&T as justification for a particular business model, we can no longer take that as proof absolute of its relevance.  DoCoMo’s i-mode taught us that, but its worth the reminder. New services and business models do not have global ubiquity like telephony, messaging, and internet access.  This is a great situation for telcos, as they can thrive far better in this diversity than a web-based company that focuses on global dominance with a small team in the Bay Area.

For example, Dialog in Sri Lanka have created something that works in their market, and likely will work in many emerging markets in Asia and Africa. Its not necessarily what AT&T should do, and similarly what AT&T does is not necessarily the right thing for many other operators. As we look beyond telephony, messaging, and internet access its not one size fits all, we need to focus on our specific markets, test fast, get the local recipe right, win local market share dominance, then enhance the service, bundle, and discover other winning new services. We’ve said it for many decades now, its about continuous innovation.

 

In the limit Telco APIs are just a lubricant to business relationships. The telecom application developer ecosystem matters in priming the pump of innovations that Telcos bring to their specific markets.  TADSummit will cut through the myths, misunderstandings, and help people focus on where business makes sense for them.  You can see more about TADSummit in this weblog. TADSummit brings an all-star line-up to share their experiences, interactive workshops to all attendees get involved in the discussion, and build the telecom application developer ecosystem from the grass roots.