Try often, kill quickly
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…