This weblog has discussed previously the technology bias of the telecom industry given its history.  Building a reliable, cost-effective, national network requires significant focus on technology and architecture. However, people need a phone service, so selling isn’t required only marketing, the business side is relatively easy.  But when the objective is a service not the network, and a service where the customer can choose inaction, the focus unfortunately remains technology.  Well, to be frank its an obsession about technology and architecture to the detriment of business success.  I’m seeing this happen with the network API (Application Program Interface) initiatives.

Here are a few pointers on network APIs for operators:

• First and most importantly, APIs are simply a technology to deliver a service.  The API in itself has little value.  Look at the successful API initiatives on the web such as Netflix; it’s the Netflix service not the API that customers are paying for.
• Most APIs on the web are free, so operators are competing with free, which is not a good situation.  The business focus must be beyond the API, its the services enabled by the APIs that matter.
• APIs in operating systems (iOS, Android, Windows Phone, etc.) are not the same as APIs in network or on the web.  Don’t get confused between the app store and network APIs, the two are quite different though complementary.
• When an Aggregator delivers services to your customer using your APIs, the customer is no longer your customer, it’s the Aggregator’s customer.  Customers buy services not APIs.  And Aggregators will increasingly go over the top, you’ve got to make them vested in mutual success.  This means you have to get off your a^$* and actually sell the network API enabled services to your customers in co-operation with you partners.  APIs are not about sitting back on a state granted monopoly / duopoly / oligopoly and waiting for the money to start rolling in; do that and over the top will be the preferred option.  This is an example of why a business plan is essential as if forces operators to think through exactly these type of scenarios.
• What are you doing organizing developer conferences in Las Vegas?  Seriously, the Bay Area, London, Boston, New York, and Tel Aviv come a long way before Las Vegas.  It just reaffirms you’re out of touch with developers.
• There are many types of developer out there, they have a vast range of needs, problems, requirements, and relevance to network APIs.  You’ve got to segment and focus, I’ve seen only a couple of operators attempt to do this.
• Most developers have someone pay their salary, you need to focus on who’s paying the salary as well as the developers.  Don’t get me wrong, the unknown developer that creates something amazing with your API is out there, but they’re more likely to do it with Apple, Amazon and Google than you, so you need a real business plan not “wishful thinking”.
• Why the current obsession with opening innovation centers in the Bay Area?  You did this at the end of the ‘dot com’ boom and it didn’t work, what are you doing differently?  Who are you putting there?  Do they have any credibility?  Are they just telco middle managers with little experience of the outside world?  Just because they tweet doesn’t make them credible.  You’re wasting funding that should be pumped into making the API program a success.
• Focus, just offering APIs without a clear business plan is called “wishful thinking”, it is not how successful businesses are built.  Where’s the network API business plan?
• Partner, until operators get the internal people and processes right to enable service innovation, they’re set up to institutionally kill service innovation.  Just look at your track record over the past two decades.  People and Processes must change before technology.
• Expecting partners to work with you simply because you’re big is not a business plan.  There should be a policy that removes anyone from the network API project that uses such a statement as justification for why partners will work with them.  You’re both going to have to put ‘skin in the game’ around your specific co-operation.

There is another more insidious problem than technology bias in telcos, that is organizational politics.  As telco API’s start to show potential the institutional ‘anti-bodies’ are getting involved, that is middle managers adept at creating confusion to drive their specific agendas to get to the next rung on the corporate ladder. Telco boards need to realize they do not understand the API business.  A few board presentations cannot educate them, they got into their positions when it was about building a network and customers came running.  Telco boards need to put a leader in charge that understand the API business, has credibility with partners, is empowered to the same level as the CMO or CIO, and is completely vested in the project, that is if they miss their objectives they are fired not reassigned to another project.

There are glimmers of success in some of the API initiatives, and some of the smaller operators such as Telenor are building a solid API business through focusing on partnering and having a clear network API business plan.  But I’m seeing the glimmers of hope get squashed under the technology bias and organizational politics that plague our industry.  Let’s not kill the API business just as its about to getting going, we’ve still got much work to do to get the telco house in order to make this a success.