Large operators are focusing on building the fastest and most reliable networks; increasing call and SMS traffic; offering the best data plans for surfing; offering excellent business communication services; building a machine to machine business; offering impressive IPTV; etc. Management effort has to be divided between all these and other businesses. The quest to get departmental budget is long and hard.
So if you are a telecom CxO and you get three business cases, which one do you choose?
1) LTE business case – heavy investment but strategically key and very good ROI
2) IP PBX vs on-site equipment business case – low initial investment and clear business model
3) Telco PaaS business case – low initial investment but unclear business model
Any business leader would say 1 is best, then 2 and do not invest in 3. However there is something called “The Innovator Dilemma“. LTE will make it easier for dotcoms to offer IP PBX as well as cannibalize voice and SMS revenues because over-the-top players will be able to offer mobile VoIP and IM. Even if a CxO would invest outside of LTE in disruptive technologies then it is still very likely that the best people will want to work in the LTE project and not in a disruptive technologies project.Note: An operator that does not invest in LTE will be dead in 2 years so investment in new network technologies is crucial for operators to survive in the short-term. So the solution is not to invest only in disruptive technologies.
So what should operators do?
Create a holding company and three independent sub-companies:
- The bit-pipe
- The cash-cow manager
- The future
The bit-pipe company is focusing on the network and its operations. Cost reductions, stability, network quality and new network technologies, e.g. LTE, are key for this company. This company should be able to work on low margins and even work together with competitors if it makes financial sense, e.g. share network resources or resell capacity to competitors.
The cash-cow manager should also be a company focused on maximizing profits and minimizing costs. The cash-cow manager gets to manage the circuits and deliver voice, SMS and traditional telco services. They have the liberty to provide these services on top of other networks if it makes financial sense.
The future is a company that will have the bulk of the people and some seed capital that will pay salaries for the next 18-24 months. The mission should be clear: “Focus on new revenues coming from data”. There will be no cross-charging between the other two companies. Either you get new revenues or your future is looking very bad. Why would you be so extreme? Look at McKinsey, Telco2Research, etc. they all say the same. Key telco assets will loose their value in the coming 2-3 years as has happened with location. Or operators start to work on new data revenues NOW or they will have to fire tens or hundreds of thousands of employees in 2-3 years. Telefonica already started a process to fire 20% of the workforce. Separating employees into a new company and giving them one mission will make everybody focus on success. Innovative revenue-generating data services is what the telecom industry needs. Without it everybody will start feeling the pain very soon…
The last player to join the attack on the telecom operator’s business is Apple: How to bypass carriers, Apple-style? (Special thanks to Dinesh Vadhia).
Apple never played according to the telecom rules in the first place. They have been the only mobile hardware vendor that could set the rules instead of negotiate them.
Who is attacking my assets?
So which telecom assets are currently under threat:
- SMS – instant messaging has been attacking SMS for years but now with the next generation of smart phones the number of SMS killer apps has exploded.
- Voice – Skype and VoIP providers have been attacking voice calls for years. However also here smart phones are accelerating decline.
- Roaming – Apple’s independent SIMs could easily attack the roaming segment. Also VoIP on Smart Phones will.
- Billing – Micropayment solutions from Paypal and Google Checkout are trying to enter this domain. Squared from a former Twitter-employee is attacking the mobile payment terminals in shops.
- Spectrum – Google’s CEO is the chairman of the New American Foundation that is trying to convince the American government to open medium-distance spectrum for free. Sort of WiFi but with kilometers reach.
- High-speed interconnect networks – Google is paying part of some of the under-sea links that connect multiple Asian countries.
- Fiber to the home – Google is rolling out fiber to the home.
- VAS – mobile apps are taking over from the value-added services.
- PBX like Business solutions – on-site premise equipment is being substituted by virtualized Cloud-based solutions.
- The telecom network – telecom operators are becoming bit pipes. New bit-pipe-only companies however are trying to specialize in this domain, making it hard for communication service-oriented operators to keep on making the same profits.
What should operators do?
If there was one simple answer, I would not be writing this post but living on my own private island 😉
However if history can be a teacher, let us look at an industry that has been facing similar threats: Hollywood. Prices of distributing digital content have fallen close to zero. However the industry has been trying to keep on charging €12-€30 for CDs and DVDs. They have hardly embraced digital distribution and are now in a negative spiral of demise.
Telecom operators can easily get stuck in this same vicious circle. History has been cruel in the past: extremely lucrative postal monopolies were destroyed by email. There is no rule that states that economic wealth from one business model is substituted by a similar lucrative business model afterwards. Often analogue dollars are traded for digital pennies.
Accept digital pennies but collect them all
The first survival strategy is to embrace change and to go for digital pennies. This is often hard to do within existing companies. As such the proposed strategy is to set-up a parallel organization whose objective is to focus on these new business models and how to make money with them. Let the main company focus on the telecom hits (Voice, SMS, etc.) and the other company on the long-tail telco services.
Long-tail telco services are all about enabling communities of developers and companies to create new and innovative telecom solutions that they can sell to others. The focus should be on enabling others. Not on building them yourself. Being an App Store for telecom network-assets-based applications and not a builder of telecom services.
This parallel organization should be in close collaboration with partners and even dotcoms. If you can´t beat them, join them. Find ways of enabling startups to become successful with your network and other assets, not on building a parallel solution around your assets.
The music industry never understood this message but hopefully the telecom industry does.
Go IP and forget Circuit
Accelerate IP solutions and forget about circuit networks. The speeds at which services are rolled out in a circuit-based network are too slow to fight off competition. Isolate the circuit-based network elements and put an IP-based front-end.
Use the Cloud to quickly launch beta services.
Avoid building infrastructure and use the Cloud to innovate. In the telecom world services are often not launched until they are perfect. But perfect for who? It is better to launch beta services quickly and get real customer feedback instead of marketing-surrogate feedback. Launch multiple services. Check which are the successful ones. Kill the others and heavily invest in the successful ones. Cloud computing and open source can dramatically reduce innovation costs.
Build long-tail services and a common innovation-ready architecture
If you are going to work with hundreds of partners to quickly innovate then the way to interact with them is via self-provisioning. Build billing, telco network app stores, customer care, monitoring, etc. solutions that allow a third-party to automatically provision and test their solutions. Be open with interfaces and light on approval. Let them approve a web-based contract instead of sign a physical paper.
Also enable innovation via the right infrastructure. Let teams focus on the business and services. Not on storing data, managing users, billing, monitoring, etc. Common service APIs to interact with assets and common ways of building new services should accelerate time to market and avoid reinventing the wheel.
This is a time for innovation together with smart partners. Not a time to focus only on CAPEX reduction. Too many effort is spend on operating as cheap as possible and not on generating new revenues. At the end the best CAPEX reduction is to shutdown a telecom company that does not innovate at market speed and became obsolete 😦
When the words “technology and innovation” come to mind, most people think about Google, Apple, Amazon, Facebook, Salesforce, etc. Just a few think about telecom operators. The biggest telecom innovation has been mobile voice. SMS was never a technological innovation but an unplanned surprise success. MMS never got close to SMS. The iPhone and Android did not come from any telecom operator or provider.
Why is it that five people with a limited budget in months are able to stun the world whereas massive multinationals with deep pockets are not?
The reason is simple: “To innovate you have to try often and kill quickly”.
Google launched Wave in the beginning of this year. Google “killed” Wave about 6 months later. Every day Google makes a change to their search algorithm.
The current process
The cost for a telecom operator to innovate is massive. A simplified process would be the following:
- The marketing department receives calls and visits from every possible telecom provider on a daily basis. New ideas are thrown on the table to see if they stick.
- The marketing department selects the best ideas.
- These ideas are scanned by the different other departments, e.g. operations, finance, legal, IT, etc.
- A multi-disciplinary team is assembled to write the requirements for the new service, a.k.a. RFI.
- Several possible telecom providers receive the RFI and provide a response.
- A budget is allocated based on the responses and an RFQ, request for quotation, is organized.
- Several telecom providers respond to the RFQ.
- A bidding war is started and one or two winners are selected. If there are no clear winners then a proof of concept is requested.
- The winner develops the solution. Operations, IT, marketing, legal, accounting, etc. all work together to launch the new service.
- The service is launched.
The whole process easily can take a year or more and costs multiple millions. If this would be your money, you would be very careful how you would spend it as well. The end result is that only a handful of new services are launched. Only those that are expected to be immediate successes.
This process is a very “useful” process for driving down large integration and network equipment costs. However it is not an innovation stimulating process.
How can you bring innovation back to telecom?
The first step is to avoid a small set of marketing people to take decisions on what is a good service or not. The only person that can legitimately decide if a service is good is the end-user.
The dotcoms therefore launch very often incremental and new services. They monitor in detail which ones, users like. It is even possible that different alternatives are launched in parallel to see which of them the users prefer. Direct feedback is critical. If a service is not picking up or users complain about it, it gets killed quickly. Services that get good feedback are continuously improved, based on user´s feedback.
How to apply “try often, kill quickly” to the telecom world?
The major show-stopper is the telecom architectural complexity. Although a marketing person has a good idea, it often takes months to update all the systems. The reason is that network operations, business logic and user data are scattered over multiple systems and departments.
To solve this problem, services and data should be separated from the network. Google´s technological differentiator is their generic data store a.k.a. Bigtable. Bigtable is an in-house developed generic high-volume, always-available data store. More than 60 services are reported to be using this common data store. Services as different as docs, maps, app engine, etc.
Google has over a million servers. Maintenance and operations are fully automated. Software is written in such a way that failure of hardware is assumed. Hardware are not top-end but instead commodity rather low-end servers. Software can easily extend over hundreds of servers.
Applications are isolated and use the servers and data through standard interfaces.
I can´t throw away my legacy
Of course an established operator can not throw away their legacy systems. So until we have a common data store and isolation between software and hardware what can we do?
The trick is to start small, move quickly and use asset exposure. Isolate the legacy systems and expose simple APIs to the telecom assets. Via asset exposure a lot of the “hard-coded” SS7 services can be substituted with network intelligence in the cloud. Mini applications can be written by anybody from a large multinational to an individual developer. As long as users can pick their preferred services and applications from the “net app store”.
Data should also be transitioned to a common data store. In the beginning this might mean nightly synchronization of different silos. However little by little the common data store should become the master of the data. Dotcoms are no longer using sql database as a one-size fits all solution. Google, Yahoo, Facebook, Twitter, etc. all developed their in-house solutions and some even open sourced them.
Applications should be running on public or private clouds hence scaling up demand for the top applications during the day and well as scaling down during the night. This should control CAPEX of the hardware. Too much logic is packed into proprietary hardware. Software should be separated from hardware and written in such a way that it can scale to hundreds of servers.
Development teams should not have a contract of 12 months with a waterfall of requirements. Teams should be small (5-6) and have short iterations to deliver small incremental innovations. The dotcoms have a tendency to release new features multiple times a week. Even some multiple times a day. Get immediate feedback and kill if not successful. For telecom innovation teams to do the same, they should be multi-disciplinary. Ideally a mix of people from the operator and strategic partners. It pays off to have a common architecture to deploy the individual services quickly. It pays off even better to have an open API so the innovation team works on the infrastructure for others to innovate.
The small teams should have at least one person that is business and marketing focused and that has the commercial responsibility to make the service a success. Different small teams that have high pressure of time, innovate quickly. Pressure of time is also important. If there is no external pressure of time, then it has to be build internal. A simple technique is to allow people from all over the organization to take a break of their day job and to take part in an innovation team. They should have clear milestones. One month to come up with an idea. Two months for a prototype. Three months to launch the first beta. Two months to get user traction. Any milestone missed means the project is stopped or at least potentially stopped. Failure is not a shame. Quite the opposite. People will go back to their day to their day to day job with new ideas and new energy. After a while they might try again and have success. Innovation and failure go hand in hand. If you can not afford failure, you can not get innovation…
Asset exposure is a hot topic in the telecom industry. Everybody is talking about opening up telecom assets for others to create new services. However I haven´t seen any successful asset exposure by the established operators yet. Why is this? Let´s look at the four major European players.
Vodafone calls network asset APIs,” enablers” and is offering mobile payment and location services. More is announced. Then again there is also betavine, oneapi and vodafone network apis. And we are not talking yet about widgets and mashups.
Telefonica has the movilforum, O2 litmus and the movistar developers platform. A list of separate APIs is available with exotic names like “Manage Post Pay Bolt On’s API”.
“Orange developer” gets you in Google to all you need to develop. Unlike Vodafone and Telefonica. A long list of APIs is available, including the personal profile api and the personal richprofile api.
“T-Mobile developer” also worked. Unfortunately there was no information for network assets API only mobile apps development.
There is one red line in this short test: “being a telecom developer is a hard job”.
Finding the sites with development information is hard. You would think that “operatorname +developer” should be enough to Google you there.
Understanding which API to take is even harder. I don´t want to imagine writing an application with the APIs.
It is clear that European telecom operators would like to have an active developers community but they would need to understand some basic principles:
- out of sight, out of mind
- eat your own dog food
- make one millionaire
- compete against the dots
Out of sight, out of mind
If I can´t find your API in the first 5 Google items when I look for developer and your company name, then I will probably never write an application for you. SEO, search engine optimization, is the first mandatory step when a developer portal is launched. Your portal can be the best in the world but if I can´t find it then I can´t use it.
80% and even 95% of all applications only need 10% to 20% of the functionality. The telecom industry has made a habit of “over-standardizing” APIs. A simple example: sending an SMS. What does an application developer wants to do in 95% of the cases? Send “text A” to “number B”. Only 5% of the applications need a receipt that you actually read the SMS. Even below 0,01% would like the operator logo, the internal port for message delivery in the device, etc. to be available. So the trick is to have a very basic high-level API and if required a more detailed low-level API.
Why use “simplificationality” if you can use “simple”? Developers want to keep things simple. Programming is already hard enough. Standards bodies in the IT industry have designed the XML and SOAP standard to share unstructured data between as many systems as possible. Developers are neglecting both and are migrating to JSON and REST. A JSON document is a lot shorter and holds the same info. A REST API you can call from the command line. There is an interesting startup that has taken this simple principal and applied it correctly:
Eat your own dog food
A lot of startups are using the slogan: “eat your own dog food”. If you create something for others to use, then the first user should be you. Amazon created their web services stack for internal use and afterwards opened it up to the world. Until your services are not written with your API, then you should not open it up for others. After writing some services with your own API, you can be sure that it is fully functional, well documented and no longer has awkward glitches.
Make one millionaire
The economy is moved by the invisible hand which in human language means: “people are selfish”. I am prepared to suffer and write an application with your API as long as I have a change to become an overnight millionaire. Apple´s App Store has made for sure somebody a millionaire. As soon as there is one, there will be a million others trying. Make sure you share your revenue is based on the value contribution (Apple sells => 30%, developers invents and writes => 70%). If people feel they have an honest chance of becoming rich, then they will go the extra mile.
99.99% of all the apps that developers will write with your APIs will be rubbish. However as long as users are able to easily find the other 0.01%, the operator will make money will all 100%. For users to be able to find a needle in a haystack, you need collective intelligence. People need to be able to benefit from viral marketing, recommendation engines, top 25, etc. in order for them not to have to waste their time. Early adopters will try out the bulk of the apps but they are only a minority. The rest of the mortals need to be helped. If I am looking for the coolest game, then it should be first in the list of games. Apps needs to be automatically clustered, categorized, recommended, etc.
Compete against the dots
An operator´s competition for asset exposure is not your-next-door-operator but a dotcom that offers a way around your assets. For years operators sat on their location assets without exploiting them. Google came and wiped most of the value out with its Latitude, Maps and Goggles. Copy the dotcom technology and ways of doing things.