Recently, I heard about a requirement to launch a music service for an operator group. I checked internally on why we cannot help it launch first and then improvise as we go, instead of the normal tried and tested methods. There were justifiable resistances on why that would not work and knowing my place in the environment, I did not pursue this issue further.
However, what triggered me to step into this deliberation was a specific requirement pertaining to Compliance to J2ME client for streaming. This made me begin thinking about the unspoken debate about over-the-top (OTT) players versus operators or how operators can counter OTT threat. Quite frankly, a significant portion of operators across the world do not worry about the threat and continue laughing all the way to the bank, as OTT or the lack thereof, they are making their money. Whatever is being lost (apparently) in messaging is being well compensated in increase data usage.
Moving to a different viewpoint-i.e. execution-a bigger threat to operators or their vendors, but one that is rarely bought up. Take for instance, an operator launching a service, compared to that executed by an OTT player. While my work requires me to represent operators, I think we can benefit from taking a leaf or two out of the OTT players’ books. I would like to share some practices that we could imbibe from OTT players pertaining to taking the idea to the market or in more contemporary terms, realize the idea of delivering value to the consumer’ faster, better and continuously.
Also as a preamble, the word service here refers to a service consumed by the end consumer like photo sharing, music streaming, phone backup or equivalent services that can be launched by even small sized organizations. It does not refer to the core network or access infrastructure elements
I’d like to illustrate the process adopted by an operator or a vendor servicing an operator while launching a service. You could argue that I am exaggerating, but I shall leave that to you.
Meanwhile, take a look at how an OTT player launches a service. Again, you could argue that I am understating facts, but I shall leave that to you.
I am not questioning the merit of both the processes, but it is very clear on which process helps hit the rubber on the road faster and that precisely is the only challenge that operator or vendors like us has to address to remain relevant and significant.
I list certain factors that contribute to the success story of OTT players
- Focus on the one thing
- Start small, scale on demand
- Leverage existing assets
- Design for resilience
- Collect feedback and continuous improvement
- Continuous consumer engagement
- Value first , money later
- Closed to open
Focus on The one thing
I think being everything to everybody will end up being nothing to nobody. Some of the requirements I see are humanely impossible to achieve and some are downright atrocious. I fail to comprehend why someone launching a music service will need to have a J2ME client as a mandatory requirement. The point is here to focus on ‘The one thing’ that the consumer will get enticed to and do that very well. I feel if you do that one thing well for even one category of consumers, the rest will wait. They are not going to walk away or take up arms against you. They know that you shall serve them. If the service is good, the network spreads the word about the service and you would have created a sense of hunger around the service. In other words the assumptions you made about the success factors of the service shall be validated with the adoption of the service. Create the experience that creates the hunger
Start small, scale on demand
I feel that anybody sizing for a new service at 100 million subscribers for 1 million simultaneous sessions on day zero is either extremely optimistic or extremely indifferent. In this era, when I see particularly more services ending up as software inventory after few uses, it is impossible to predict the success of a service. What you can possibly do is design to scale rapidly based on reasonable extrapolations on observed traffic. Committing to infrastructure without empirical evidence is adding boxes to the data centre which never gets powered up.
Leverage Existing Assets
Do not reinvent the wheel. Amazingly wonderful systems are running on built on popular and extremely available open source stacks. The services are buzzword compliant from day one. They are built using IAAS, PAAS, SAAS or any combinations of these and are able to deliver value faster. Their focus moves purely to their application rather than the surrounding periphery. Also they take care to integrate Social, Mobile and Analytics into their service from start.
Design for resilience
Systems are designed in such a way where the philosophy is ‘I will fail. How fast I can recover’ and not around ‘I should not fail’. This philosophy could have an element of service bias to it, but for most services, consumers are tolerant to some amount of random failures.
Collect feedback, Continuous Engagement and Improvement
Services are built to collect feedback about usage and non-usage from day one. Also there is a sense of community created around the usage of service in popular social networks. This is a double edged sword since both good and bad news spread fast. I do notice that there are hooks into this networks and rapid action taken to recover from bad news. Also based on my usage with the service, continuous engagements through various channels are established by the service. There are non-intrusive notifications, information about my usage, information about how other people are using the service and many other things that are done to continue my engagement with the service.
Value first, money later
The services are built for delayed gratification for the people who are building it. The typical cycle seems to be, get the consumer in, make him experience the service, built a community around the service, gently nudge them about the benefits of a paid service. Truly successful services are built for the long haul. The monetization philosophy differs based on the service and it need not be free for eternity, but the models is deliver value and realize the monies.
Closed to Open
Any service that is built has a way to collaborate with other services already running. It is not built as a closed loop monolithic service. There are hooks for other services to interact with this service and build other interesting federated services.
Well if all the above sounds preposterous, naive and downright stupid, my only take is let us do one service launch the OTT way and see the evolution of it over a year, since anyway that is the time it will take to get the traditional service in.
I rest my case here. I do want to add that the traditional model has been robust and successful but I do end with a plea on there is merit in exploring ‘what works’ and be seen as agile to consumers in the areas of customer discovery , service adoption and continuous improvement. As someone recently published ‘Execution is Strategy’.
