If you thought Amazon’s Prime Instant Films is just an exception of Amazon trying to compete with its best customer then you are wrong. This is not an exception but a rule. Simon Wardley just explained why Amazon is fast following their best customers and why more companies should do it to, even in the physical world. The summary is:
If you don’t want to launch a 100 new services and assume failure on 90-95, then let others launch thousands and you commoditise the successful innovations.
So what does this mean?
It means that if you are a young startup that builds everything on AWS then they will just look at the traffic that goes through your servers. If all of a sudden they see that you are picking up more traffic then anybody else, then they will launch a competing solution shortly that commoditises your business. Since they have access to your solution they can actually look inside and see how it works and redesign a more optimised solution.
How to avoid your service to be commoditised by a fast follower?
First of all move faster than anybody else. Full automation is key. If you are faster to respond to customer’s needs then you will attract all customers in a winner takes it all market. Also follow lean startup and A/B testing. Do continuous experiments and only scale up engineering on a new feature after it was demonstrated to be successful with customers on a small scale test.
Second, don’t build for one cloud, build for multiple clouds. If you use cloud orchestration solutions that allow your solution to be moved from one cloud to another one then you are less likely to be trackable by one cloud provider. Treat the cloud providers like they are commodity and move your workloads where it makes more financial sense. Whatever you do, don’t get locked-in by some proprietary services because you will have a hard time moving out. Just ask Netflix how they feel about having their platform ran on top of their biggest competitor’s infrastructure without a chance of moving a way soon. Don’t want to be in their shoes? Use a cloud orchestration solution. Don’t know any open source? Check out Juju…
Third, assume you will have fast followers when you start so try to put barriers of entry in place. A good strategy would be to build a business on top of a network effect. Examples: Facebook has over 1 billion users. The more users the more synergies. Even if you would steal away all the code from Facebook and launch Headbook you would not be successful. Network effect businesses tend to be a winner takes it all markets as a consequence. The other counter intuitive strategy is to strategically open source parts of your solution. If you open source parts of your solution then there is nobody that can offer a “cheaper” solution then your freely available solution. So the incentive of building another solution to compete with a free solution is low. Additionally you will get contributions from others hence your team will be able to run faster than anybody else. Finally open source does not mean zero revenue. Netflix has open sourced their architecture. This means they lower their cost and higher their innovation speed but since you don’t have access to their content library and the multiple content they create themselves, it is extremely hard to compete with them. So open source those parts that help your strategy…
We all have “enjoyed” working with some software that was purchased because “You can’t get fired because you bought…”. This software is known for being the industry leader. Not because it is easy to use, easy to integrate, easy to scale, easy to do anything with,… It often is quite the opposite.
So why do people buy it? First of all it is easy to find experts. There are people out there that have been “enjoying” working with this solution for the last 10 years. It is relatively stable and reliable. There is a complete solution for it with hundreds or thousands of partner solutions. People have just given up on trying to convince their bosses on trying something different.
5 steps to disrupt the Dinosaur
Step 1: the basic use cases
The Pareto rule. What are the 80% of the use cases that only reflect 20% of the functionality.
Step 2: the easy & beautiful & horizontally scalable & multi-tenant clone
Make a solution that reflects 80% of these use cases but make it beautiful and incredibly easy to use. Use the latest horizontally scalable backends, e.g. Cassandra. Build multi-tenancy into the software from day 1.
Step 3: make it open source
Release the “improved clone” as an open source product.
Step 4: the plugin economy
Add a plugin mechanism that allows others to create plugins to fill in the 20% use case gap. Create a marketplace hence others can make money with their plugins. Make money by being the broker. Think App Store but ideally improve the model.
Step 5: the SaaS version
Create a SaaS version and attack the bottom part of the market. Focus on the enterprises that could never afford the original product. Slowly move upwards towards the top segment.
The expected result
You will make have a startup or a new business unit that will make money pretty quickly and will soon be the target of a big purchase offer from the Dinosaur or one of its competitors. You will spend a lot less sleepless nights trying to make money this way then via the creation of the next Angry Bird, Uber 0r Facebook clone.
Why can Facebook, Google, Salesforce and Twitter role out new features every day and regular telecom operators only every 6 months? Although they are dotcoms, they have thousands of employees and a lot of legacy systems as well. However they are able to roll out a new feature every day, if not every hour or minute and large new systems every so many months, weeks or even days.
How do they do it and how can the telecom industry learn from it?
On highscalability, you will find a lot of information on the architectures of large dotcoms. However if you look at different articles you see that each of the larger dotcoms has an architecture that is shared among different products and services, e.g. scaling messages at facebook.
This is the secret sause of the dotcoms. They have built and continuously improved a highly distributed architecture that can handle millions of users and peta bytes of information. On top of this “shared architecture” go the services. New employees are able to quickly create new services because they do not have to worry about scaling data, monitoring the service, deploying/upgrading versions, backing up data, versioning code, etc.
On the other hands operators have no standardized shared architecture. Instead there is a puzzle of different solutions that often use totally different technologies, hardware, etc. Maintenance and upgrades are a nightmare.
Trying to launch any new service requires a massive amount of planning, lots of different skills, expensive investments in third-party licenses and hardware, etc.
How can you do it differently?
Building a private cloud with virtual servers and storage will not resolve operator’s problems. Just virtualizing the puzzle of solutions is not going to do away with complex integrations.
Operators need to make a more bolt move. They need to separate the new from the old. Legacy systems should be kept and isolated. However a new architecture should be built that works in parallel with the legacy systems. This new architecture should focus on launching new services and partner services at dotcom speeds. Everything should be handled as an independent service. Each service should get its own API. A storage services, a billing service, a monitoring service, a provisioning service, an identity service, a datawarehouse service, a deployment service, a mobile shop service, an inventory service, a support service, etc.
All APIs should use a common technology. APIs for third-parties could use REST. APIs for internal high-load usage could use Thrift or Protobuffers. Each API should have two versions, the easy and the low-level version. The easy API offers the most used but in general basic functionality, e.g. sendSMS(from, to, message). The low-level API offers a complete feature set, e.g. sendBinarySMS, sendSMSWithDeliveryConfirmation, etc. This will allow most services to use the easy API but to have access to the advanced functionality when needed.
Loadbalancing when using the services is key. The loadbalancer is the secret for many rolling upgrades in the dotcom world. An application that uses a certain service will use client-based loadbalancing. By having the loadbalancing be able to receive events, it is possible to dynamically add/remove instances of an API, gradually move requests to a new version of the API, etc.
New service developers will now have to focus on building the business logic for the new service and not on data migrations, scaling, monitoring, backups, etc. The service can have completely new ways of billing and charging, a complex deployment workflow, advanced monitoring requirements, large data storage requirements, etc. However it is not the billing or charging system that has to be extended. Neither a centralized EAI. Nor the monitoring system. Instead it is the service that decides what is best for the service via the use of the easy or low-level APIs. By moving the peculiarities of every service into the service and not into generic OSS and BSS systems, these support systems can be drastically simplified.
Operators should try to focus on launching a lot more niche services and opening up their infrastructure to a long-tail of service suppliers. Instead of general services like PBX for SME, operators should think about hotel reservation services, doctor scheduling services, etc. The value of the operator should be in offering a reliable back-office architecture, assuring service quality and managing the support eco-system. The long-tail of service suppliers should be put to work to launch competing niche offerings and let customers decide which one will survive or not.
Innovation used to be something related to an R&D department that would experiment with new technologies and a marketing department or product management that would ask customers what new features they required. The business team would be killing any innovation that did not present a business case which complied with company rules: e.g. x% margin, €yM revenue in two years, etc.
Why is traditional innovation no longer good enough?
The cost of launching a disruptive innovation that changes a complete industry has come down dramatically. There are many examples: Skype and roaming, Amazon’s Kindle and paper books, P2P and network bandwidth / media revenue, Salesforce and shrink-wrapped software, iPad and Windows PC, iPhone and Nokia, etc.
Disruptive innovations are more frequent than ever and enablers like Cloud Computing, Open Source, Off-shoring, 3D Printing, etc. allow innovators to launch big solutions on a modest budget.
Most traditional innovation is about evolving a current product by adding new features and improving current functionality. Traditional innovation focuses on prototyping new features and products and showing them to potential customers. However process innovations (e.g. Toyota Production System), business innovations (e.g. freemium), marketing innovations (e.g. Intel Inside), disruptive innovation, etc. are often overlooked.
Every one should innovate
More and more companies are convinced that every one in the organization should innovate and not only R&D and product marketing. By putting special innovation processes in place in which employees can share innovation ideas and use collective knowledge to improve them and get funding, innovation becomes more democratic and often more successful. Companies like Google allow employees to focus one day a week on innovation that can be totally unrelated to their day jobs. People vote with their time which project is worth it. Ideas are shared hence collectively the services get better.
Also upper management is no longer looking from above but should innovate by example. Name all big innovative companies and you see that founders are a big part of innovation and participate in it every week: Google (Larry Page and Sergey Brin), Amazon (Jeff Bezos), Apple (former Steve Jobs), Facebook (Mark Zuckerberg), Salesforce (Marc Benoiff), etc.
Daily Innovations instead of Product Releases
The large dotcoms (Google, Facebook, Amazon, etc.) no longer do market research in the traditional way to find out if users like a feature or not. They also no longer focus on major product releases. Instead they focus on incremental innovations on a daily basis. Users request new features via social CRMs and the most voted features get implemented. Often a feature can have multiple implementations. Users are divided into different groups and new features get enabled for subgroups. If a new feature has a positive effect then it survives and gets rolled out to the rest, if not it gets killed or adjusted.
New products no longer get productized from an idea and afterwards customers are searched for it. Instead customer’s pain points result in paper prototypes that get validated and redrawn until they solve the problem. Afterwards real prototypes are made that get launched in beta or even alpha shape towards real users. Beta can already mean that users are paying for it.
Discovering New Innovations
Discovering new innovations is done by combining groups of people with different expertise (marketing, psychology, arts, technical, business, etc.), to understand a new domain and to question a status quo. Most of the time the best innovations are those that remove a status quo and make a painful activity into a joyful activity, e.g. LinkedIn: networking with people and keeping up to date your business network.
After questioning experts and novice users, innovative companies also observe how users use their products. Often heavy users or first-time users are unsatisfied with current products. New ideas are shared inside but also outside of the company with a network of experts as well as people with completely different skills. Afterwards solutions are built based on experimentation. A very important aspect is also being able to transport solutions from other industries. Making associations between unrelated topics and understanding how things are done in a completely different environment can bring new inside…
It is very important that different departments (business, marketing, operations, maintenance, etc.) all work towards launching new innovations and removing obstacles because killing innovation is very easy, making it succeed is not.
Let’s assume a new telecom competitor is entering the European market: RyanCom. Similarities to RyanAir are purely fictual
1) The Network
Instead of building expensive antenna networks RyanCom would make deals with Cable operators to put Femtocell equipment in cable modems and as such cheaply get coverage in major cities. Everybody that would switch to a Femtocell modem in their home or office would get 6 months of mobile usage for free.
Ryancom would have an agreement with the smallest operator in every country to sublease capacity if a Femtocell is not available.
2) Target User
iPad, Tablet owners, Websurfers, Roamers, etc. Ryancom would allow one data plan for the whole of Europe. Since the bulk of the traffic would go via Femtocell, better access costs could be provided. €5-10-15/month to have €5-10-15 Gigabyte/month.
3) Backoffice systems
All backoffice operating and business systems would be running in a cloud and open source is heavily used. Since there are only a limit number of data plans, there is no need for a billing system. SaaS like Zuora are enough. Google Apps and Salesforce would also be heavily used.
4) Social aspects
Social aspects would be very important. There would be competitions going on for which subscriber can convince more friends to join RyanCom. There is no helpdesk in the traditional manner. There is community support just like GiffGaff.
The End Result
RyanCom would be able to gain young data-intensive and roaming subscribers. They will see RyanCom initially as a second provider for their tablets. Little by little RyanCom could become their first provider when Skype and other applications become common use to make mobile calls.
RyanCom might be a fictional company but operators should be warned that fiction and reality might be just a matter of time…