A previous article set out the litany of excuses given as to why communication innovation has stopped in operators; and we’re working through how those excuses can be solved, avoided, or ignored.  This article expands a little more on the excuse: “We can only focus on 4 service launches per year (because we only back major successes like Video Telephony, Mobile TV, Push To Talk, See What I See, Mobile IM, etc..)”

There’s two parts to this excuse: the first is the lack of market research done in service selection, not design.  What I mean by that is the reasons for operators implementing some services and not others is generally NOT linked to specific market research rather product manager or executive management preferences.  From a global VAS (Value Added Service) survey I completed recently; market research is performed on services an operator plans to launch, not as part of a service selection process – though such investigations do happen ‘executive pre-selection’ appears more common.  Similarly across an operator group variations in implementations of services between countries is again down to local product manager / or execs’ preferences rather than a fundamental economic of socio-demographic difference between countries.

So we have 50 year old execs making determinations on what their customers would like rather than letting the customer decide.  Let’s face it, the nearly 300,000 apps in the Apple App Store do not appear to be a major obstacle to customers, just like the hundreds of millions of web pages are not a barrier to people quite successfully using the web.  I’ve discussed many times the need for and ways to speed up innovation in articles such as business case for opening the network, or where next for operator service innovation, or avoid becoming a vassal of the Mongolian State (cloud based service providers.)

The second part of tackling the excuse is the often quoted inability of the operators’ IT systems to support the necessary rate of innovation.  Here Amazon provides a great case study in how to make it happen with a loosely coupled service oriented architecture.  Below is the essence of Amazon’s approach: loosely-coupled, accountable small teams, working together over an internet-like system within Amazon.  Rather than the usual ‘boil the ocean’ transformation project with 1000 unaccountable consultants from Accenture, which generally creates no discernible difference in customer experience.  Such a change is not as difficult as it first appears, many operators have implemented SOA (Service Oriented Architecture) several years ago, rather it’s a change in organization, enabling the IT organization to do what they like to do – “code and deliver” in small accountable teams rather than RFP adjudication, managing external consultants and writing internal memos.