This week Verizon held its first developer conference in San Jose. See http://4g-wirelessevolution.tmcnet.com/topics/4g-wirelessevolution/articles/60887-verizons-lure-developers-the-speed-lte.htm
It has taken the success of an independent app distribution model (Apple AppStore) to have these initiatives move beyond the CTO Office where they have been studied for years (and the technology has long been available) to the go-to-market phase where the value proposition to developers is finally being seriously addressed.
Even though the intervening years have permitted some of the formerly golden carrier information assets - location, deck placement - to be eroded by over the top alternatives, there are still two key areas where carrier APIs will make a giant difference to developers.
The first of these is billing. For an app to be able to place a charge on the phone bill, and do so not only at initial purchase, but as a subscription or as part of a transaction enabled by the app, opens up a whole new monetization model for developers. In contrast to credit card billing, this can enable more impulse purchases, and eventually reach down to credit challenged and prepay users (as smart phones trickle down). In contrast to premium SMS models, the potential exists for more flexible billing and margin models that can return more to the developer.
Since the mobile advertising model hasn't yet evolved to be able to support a broad app ecosystem, and since charging only for the app one time at purchase is a very restricted model, the opening up of carrier billing has the potential to transform app economics.
The second of the key carrier APIs is call control. This is stickier ground, as the potential exists to substitute core carrier revenue services, and indeed, Verizon hasn't yet exposed call control in the first go-around). The call control API with the greatest potential to unleash new and stickier apps would be the ability to alert a server side app when an inbound call is being placed to the subscriber's existing mobile number and permit a dynamic call routing decision to be made. These capabilities have been part of IN (WIN/CAMEL) for years, but exposing them via web interfaces to external developers is a game changing event.
Consider all the controversy over Google Voice on the iPhone. Google is providing the customer with a new phone number identity, inserting their switch ahead of the carrier and taking control of the overall service logic. No wonder that strategically for AT&T (one assumes...) this is a no-no. It also limits adoption since the subscriber is forced to move to a new number and inform all their contacts. But instead if the existing number can be used and Google Voice can register with the carrier to receive the call under defined circumstances, and further, can return the call for onward processing at the carrier under other circumstances - then there are several advantages:
Consumer adoption is mightily advantaged due to use of the existing number. The carrier can control the economic terms under which they permit third parties to provide call handling capabilities, and can make these terms seem more attractive to the developer by virtue of carrier billing on the existing phone bill. If the service requires outbound calls, then these can be made under the same calling line identity as the subscribers original number - without contrived workarounds.
There are many other services that can take advantage of carrier provided in bound call control - virtual PBX services like RingCentral.com, VirtualPBX.com, phone.com etc. that target SMEs and RIM's Blackberry Mobile Voice services resulting from their acquisition of Ascendent come to mind. Others on the consumer side include mashups of voicemail and social networking. These have a realistic chance of actually growing the voice pie at the carrier - these apps need not only be about increased data revenues - and can have very robust business cases for the carrier under either rev share or wholesale minutes usage arrangments.
Orange and O2 are other leading carriers going down this path. Lets see how the fear/risk/innovation/openness balance evolves.
Wednesday, July 29, 2009
Thursday, July 10, 2008
Embracing applications from outside the operator - Business models
So where are all the mass market innovative applications that IMS was supposed to enable? The millions of customers using operator internally hosted SIP centric applications running on an IMS application server and interacting with the IMS core network components like the S-CSCF and the HSS etc.? We really don't see anything that reached scale out there.
Instead, within the lifecycle of a single large operator IMS RFI, lab trial and RFP, Youtube was founded (Feb 2005), reached 100 million videos being watched daily (July 2006) and was sold to Google for $1.65B (November 2006). Video sharing. Wasn't that one of the main exciting, change the world, IMS applications? Youtube is available on many 3G mobile phones now.
So how does an operator participate in the external speed of innovation and adoption without becoming a dumb bit pipe in the process? Web 2.0 applications are in perpetual beta, with releases every few weeks. The learning from actual usage is quickly captured and used to improve the service on a fast feedback loop. This is a far cry from the five nines methodical testing pursued by an operator, the 3 month lab trial and 6 month market trial and multi-million dollar systems integration project with Cap Gemini or IBM. Entire Web 2.0 startups can get to breakeven cashflow on less than the integration budget for a typical telecom operator internal application.
The technological answer is fairly well understood - exposing the key operator golden assets of call control, location, presence, messaging and billing securely to external applications using telecom web services, often using 3GPP standards like ParlayX. Vendors like Aepona, Nokia Siemens and BEA Systems provide Service Delivery Platforms that do this in a carrier class manner, and even help bridge the external applications to gradual use of IMS underpinnings inside the network, without requiring the Web 2.0 developer to understand IMS, let alone IN. There are deployments of note at leading operators, a good example being Sprint's Business Mobility Framework for exposing location which has 50 or more enterprise applications accessing location and messaging from the Sprint Network.
So that's the answer then, case closed?
No. The bigger problem is how do an operator and an application partner on the web do business together? One is used to free trials for months, slow testing and full control over every aspect of service pricing and branding. The other cycles every few weeks, gets users quickly, and revenue as much through advertising as subscriptions. Imagine both sides in the same room trying to work out a deal. They don't even talk the same language! The cultural distance is huge.
What's needed is a roadmap or guide to selecting a business model and a set of rules for how to pick the right model for the right situation that creates aligned timelines, financial incentives and risk tolerance for each. Whilst this seem like business development 101, its hard to do for an operator and a web 2.0 startup. Below is a framework for such an approach, that looks at application types based on their position on the demand curve or so called "long tail curve".
Instead, within the lifecycle of a single large operator IMS RFI, lab trial and RFP, Youtube was founded (Feb 2005), reached 100 million videos being watched daily (July 2006) and was sold to Google for $1.65B (November 2006). Video sharing. Wasn't that one of the main exciting, change the world, IMS applications? Youtube is available on many 3G mobile phones now.
So how does an operator participate in the external speed of innovation and adoption without becoming a dumb bit pipe in the process? Web 2.0 applications are in perpetual beta, with releases every few weeks. The learning from actual usage is quickly captured and used to improve the service on a fast feedback loop. This is a far cry from the five nines methodical testing pursued by an operator, the 3 month lab trial and 6 month market trial and multi-million dollar systems integration project with Cap Gemini or IBM. Entire Web 2.0 startups can get to breakeven cashflow on less than the integration budget for a typical telecom operator internal application.
The technological answer is fairly well understood - exposing the key operator golden assets of call control, location, presence, messaging and billing securely to external applications using telecom web services, often using 3GPP standards like ParlayX. Vendors like Aepona, Nokia Siemens and BEA Systems provide Service Delivery Platforms that do this in a carrier class manner, and even help bridge the external applications to gradual use of IMS underpinnings inside the network, without requiring the Web 2.0 developer to understand IMS, let alone IN. There are deployments of note at leading operators, a good example being Sprint's Business Mobility Framework for exposing location which has 50 or more enterprise applications accessing location and messaging from the Sprint Network.
So that's the answer then, case closed?
No. The bigger problem is how do an operator and an application partner on the web do business together? One is used to free trials for months, slow testing and full control over every aspect of service pricing and branding. The other cycles every few weeks, gets users quickly, and revenue as much through advertising as subscriptions. Imagine both sides in the same room trying to work out a deal. They don't even talk the same language! The cultural distance is huge.
What's needed is a roadmap or guide to selecting a business model and a set of rules for how to pick the right model for the right situation that creates aligned timelines, financial incentives and risk tolerance for each. Whilst this seem like business development 101, its hard to do for an operator and a web 2.0 startup. Below is a framework for such an approach, that looks at application types based on their position on the demand curve or so called "long tail curve".
Niche plays in the 1.2 billion unit handset industry
Something approaching 1.2B mobile handsets will be shipped this year, a market mostly dominated by Nokia, Samsung, SonyEricsson, Motorola and LG. Surely this business, with its highly competitive margins depending on huge economies of scale, its R&D investments that only a multi-billion dollar corporations can step up to and gigantic brand and distribution investments is no place for a startup, right?
Yet as in most gigantic markets, there are profitable underserved niches. The nature competing at titanic scale means that its very hard for Nokia and Samsung et al. to build a set of business processes that efficiently serve markets of 500k handsets annually, split over lets say 10-20 countries. Their supply chains are set up for super high volume. Nokia shipped 1.25 million handsets a day in 1Q08. Amortising tooling over say 100k handsets, or changing design to accommodate special materials bought in small quantities, or co-branding with lifestyle brands distributed in non-traditional outlets requires a set of business processes that the giant machine can't economically add for small volumes. They are too disruptive to business as usual to be worthwhile.
The key to finding profitable niches is to focus on underserved end user needs. One company doing just that is Sonim Technologies. The underserved users are those who work or play in extreme environments - like construction sites, open cast mines, ski slopes, sailing boats etc. The needs are for ruggedness (2 meter drop test, vibr
ation resistance), waterproofing, (including submersibility) and loud volume for the ringer. On a boat or ski slope, in case you get into trouble, extra long battery life is valuable. If you work with protective gloves, big buttons make a big difference and a phone thats not too small. Optimizing the design around ruggedness makes these phones look very different to the mainstream design trends of the rest of the market. Indeed for a large manufacturer it would risk confusing the brand identity.
Underserved needs are also solved with special services - like push-to-talk with dispatcher capability, or push-to-help with GPS tracking. Stuck on your windsurfer a mile from shore in sudden bad weather, with half a wet hand available and not exactly sure where you are? Fell off your mountain bike coming down a steep hill far from a road and broke your leg? Push one button to have them come get you. Recurring revenue services plus handsets can make for high valuation multiples - just look at RIM who makes $7 per handset per month in service fees collected by operators for them as part of the data or Blackberry plans they offer.
Finding the right niche needs highly targeted branding and distribution - e.g. distributing the waterproof help phone in the marine equipment store co-branded by a boat manfacturer. Done right this can create defensible businesses that can command a $100+ price premium over the equivalent non-niche phone for modest additional cost, and thus be very profitable, if not Nokia sized.
There are other underserved handset niches out there beyond rugged. We'd love to hear from entrepreneurs who think they've identified one.
Yet as in most gigantic markets, there are profitable underserved niches. The nature competing at titanic scale means that its very hard for Nokia and Samsung et al. to build a set of business processes that efficiently serve markets of 500k handsets annually, split over lets say 10-20 countries. Their supply chains are set up for super high volume. Nokia shipped 1.25 million handsets a day in 1Q08. Amortising tooling over say 100k handsets, or changing design to accommodate special materials bought in small quantities, or co-branding with lifestyle brands distributed in non-traditional outlets requires a set of business processes that the giant machine can't economically add for small volumes. They are too disruptive to business as usual to be worthwhile.
The key to finding profitable niches is to focus on underserved end user needs. One company doing just that is Sonim Technologies. The underserved users are those who work or play in extreme environments - like construction sites, open cast mines, ski slopes, sailing boats etc. The needs are for ruggedness (2 meter drop test, vibr
ation resistance), waterproofing, (including submersibility) and loud volume for the ringer. On a boat or ski slope, in case you get into trouble, extra long battery life is valuable. If you work with protective gloves, big buttons make a big difference and a phone thats not too small. Optimizing the design around ruggedness makes these phones look very different to the mainstream design trends of the rest of the market. Indeed for a large manufacturer it would risk confusing the brand identity.Underserved needs are also solved with special services - like push-to-talk with dispatcher capability, or push-to-help with GPS tracking. Stuck on your windsurfer a mile from shore in sudden bad weather, with half a wet hand available and not exactly sure where you are? Fell off your mountain bike coming down a steep hill far from a road and broke your leg? Push one button to have them come get you. Recurring revenue services plus handsets can make for high valuation multiples - just look at RIM who makes $7 per handset per month in service fees collected by operators for them as part of the data or Blackberry plans they offer.
Finding the right niche needs highly targeted branding and distribution - e.g. distributing the waterproof help phone in the marine equipment store co-branded by a boat manfacturer. Done right this can create defensible businesses that can command a $100+ price premium over the equivalent non-niche phone for modest additional cost, and thus be very profitable, if not Nokia sized.
There are other underserved handset niches out there beyond rugged. We'd love to hear from entrepreneurs who think they've identified one.
Subscribe to:
Posts (Atom)