Five upsell strategies for mobile ISVs

Mobile software vendors (ISVs) who develop software for mobile handsets are competing in an increasingly crowded market; on-device software is being increasingly commoditised, channels to market and mobile operators are a challenge to deal with, and middlemen are always there to take a respectable revenue share. So what are the options for a mobile ISV who’s keen to upsell the value of their software assets ? Here I present a framework of five strategies that mobile ISVs can use. Each strategy is presented in one slide, from one to five. You can download the entire presentation here.

Five upsell strategies

Strategy 1

Strategy 2

Strategy 3

Strategy 4

Strategy 5

Thoughts, comments or suggestions are welcome as always.


Activating the Idle Screen

We recently researched and authored an extensive research paper on the subject of active idle screens; that is, the technology that turns the ‘front page’ of the phone into an ‘active’ real-estate for discovering, searching, promoting and advertising services. I expect the market value of this real-estate to rise very quickly. Why ? Put simply, the idle screen is the start and end of each and every user journey and as such is the prime inventory in the phone. This is uncharted and relatively virgin territory for mobile operators, manufacturers, content providers and newcomer advertisers who are keen to exploit the 1-billion-a-year piece of a real-estate that is more personal than most other consumer electronics toys. Active idle screens (AIS) is a busy market, too. Some 15 vendors are now offering AIS solutions, deployed by over 10 mobile operators to date, with Alltel, Orange, T-Mobile US and Vimpelcom being behind the most innovative and aggressive deployments.

The research paper, Activating the Idle Screen: Uncharted Territory was commissioned and published by Informa Telecoms & Media at last month’s Handsets World conference. Before I dig into the findings of the research, here’s some more teasers. Over 1.5 months, George Voulgaris and I interviewed nearly 20 companies: Abaxia, Acrodea, Aditon, Adobe, Amobee, Celltick, Ikivo, IntroMobile, Motorola, Nokia, Onskreen, Openwave, Orange, Qualcomm, Tegic, Webwag, and Zi Corp. Our favourites? Finding out about Nokia’s Ad Connector (Nokia’s big push into advertising) as well as Alltel’s Celltop, and T-Mobile’s MyFaves (the most innovative uses of handset customisation by operators today). Next are some excerpts from this research paper – you can download the full paper here.

Why the Idle Screen ?
“The idle screen is the starting and finishing point for all tasks associated with a mobile phone; whether making a call, sending a text, checking to see if a voicemail has arrived or downloading a ringtone, the idle screen precedes and concludes the user journey involved in performing each task. As a result, the idle screen has two important properties. Firstly, it is the application within the handset that is visible most often or that is active for the vast majority of the handset s lifetime. Secondly, the idle screen is the least intrusive medium on the handset for presenting informational or promotional messages. As a result, the idle screen has been widely used by mobile operators and handset manufacturers to provide branding elements and static links to mobile services, such as a WAP portal.

However, the idle screen need not necessarily be static; In fact, adding interactivity elements into idle screen makes it anything but idle. Indeed, active idle screen solutions can address three real challenges that mobile services and handsets are currently facing, namely:
– Handset complexity and featuritis which impacts the ease of use of handsets
– Poor access and discovery of mobile services, due to the long click-distances associated with the location of these services.
– Inadequate means for service promotion and advertisement”

Some history: the idle screen past and present
“The active idle screen market has come a long way in the last few years. The market has been led by Abaxia in 2002 and IntroMobile in 2004 who deployed handset-based AIS with operators Orange and SKT respectively. Zi s Qix and Qualcomm s uiOne products were announced in 2005, but only achieved customer wins with idle screen products in 2007. In early 2006, SCREEN3 was first shipped as part of Motorola handsets and later in the year Onskreen secured a deployment with operator Airtel in India. In the SIM-based active idle screen market, Celltick first launched its LiveScreen Media solution with Hutch India in 2002.

2007 is clearly the year when a wave of vendor announcements have hallmarked the establishment of the active idle screen market. Aditon U-Daily, Adobe Flash Home, Nokia Advertising Connector, MobiComp s ActiveTicker, Openwave Mobile Widgets, Tegic T9 Discovery Tool and Webwag s Mobifindit and Mobidgets were all announced in early 2007.”

The vendor shoot-out
“There are nearly 15 software vendors today who specialise in active idle screen solutions; Abaxia Mobile Desktop, Aditon U-Daily, Adobe Flash Home, Celltick LiveScreen Media, IntroMobile IntroPad, Nokia Ad Connector, Onskreen Fusion, Openwave Mobile Widgets, Qualcomm uiOne (on idle screen), Tegic T9 Discovery Tool, Webwag Mobifindit / Mobidgets and Zi Qix. Access Netfront Dynamic Menu and MobiComp s Active Ticker are further AIS solutions. Last but not least, Amobee produces the Handset API (HAPI) SDK for insertion of interstitial and banner advertisements into handset applications, including the idle screen.”

The next table taken from the report compares AIS solutions in terms of deployment track record and features (platform, access method, and promotion capabilities). Each one of these vendors is reviewed in detail in the paper. In this environment it is important to understand the boundaries of the AIS solution space, i.e. which purposes it is best suited for and which it does not address. To accomplish this, it is important to establish a frame of reference across other customisation solutions, namely on-device portals, AIS and skinning solutions, and ascertain what are the defining traits and distinguishing characteristics of each solution space, and last but not least, the points of parity between them.Very few software vendors cover more than one solution space. For example, uiOne can be used to implement deep skinning, on-device store-fronts or idle screen-based promotion solutions. A few on-device portal vendors offer idle screen replacement capabilities, most notably mPortal, whose Springboard ODP client sits on the idle screen of Disney Mobile handsets and Cibenix who had launched an idle screen-based dashboard on some handsets launched by operator ONE in Austria.”

The next table compares and contrasts the use cases, revenue sources, technology and other distinguishing characteristics of three approaches: Active Idle Screens vs On-Device Portals vs Themes & Skins.

Technology use cases

The deployments
“To date, Alltel, Vodafone Germany, Orange UK, SKT, T-Mobile US, TMN Portugal and Vimpelcom have deployed some form of AIS products. Of these deployments, it is worth crediting Orange with the highest number of handset shipments with embedded clients, Vimpelcom with the highest number of deployed on-SIM clients, Alltel with the most personalisable active idle screen product and T-Mobile US with the first AIS product designed to boost voice ARPU.”

See the research paper for case studies of seven active idle screen product deployments, namely Alltel Celltop, Motorola SCREEN3, Orange Homescreen, S60 Active Idle, SKT 1mm, T-Mobile MyFaves and Vodafone Live! Cast. These case studies cover both manufacturer and operator led AIS deployments, spanning North American, European and Korean markets.

The challenges ahead
“Despite the flurry of announcements, AIS products are still part of a nascent market, both in terms of technology maturity and the commercial route to market. There are four fundamental challenges all AIS products will have to address:

– Idle screen replacement requires integration of the AIS software with tens of relatively inaccessible APIs (application programming interfaces) which are only available to third parties subject to manufacturer approval. This implies that the AIS technology is mostly accessible to companies with strong relationships with handset and operating system vendors.
– Deployment remains a challenge for all handset applications. As such AIS solutions will rely on operator backing or manufacturer consent in order to secure distribution volumes.
– Any form of pre-sales handset customisation can easily impact the time-to-market. Since active idle screen products imply significant modifications to handset software, AIS solutions have to constantly trade-off the scope of customisation against the time-to-customise.
– The idle screen represents the cardinal touch point of the end user with the handset manufacturer brand. As such, handset OEMs are particularly wary of the risk of brand dilution and third party control points that can devalue their business proposition.”

“As for the future, there is no doubt that the idle screen represents the primary real-estate for service search and promotion. It lies at the confluence of mobile operators, handset manufacturers and media publishers. Within such highly prized territory, it is clear that plenty of opportunities exist, but execution will be challenged by many turf wars. The commercial solutions that will be most successful will be those that reconcile manufacturer interests with those of operators and extend into service providers and media publishers for lucrative revenue share agreements. Moreover, unlike on-device portals, the idle screen will also be used to increase voice ARPU, rather than pure data or advertising revenue.”

Container projects: The next chapter in handset customisation

The history book of the mobile handset industry has gone through two turbulent chapters to date; the first na ve years of manufacturer rule ended abruptly in late 2002 with the launch on Vodafone Live! and the Orange SPV. In the second chapter, mobile operators in Europe and later in the US seized the upped hand in their dealings with handset suppliers. Without exception, OEMs and ODMs have been willing to produce customised handsets given a minimum purchase volume commitment. Operators had to develop new skills, adapt their organizations, foster multi-year relationships with OEMs and master complex processes of 6-month handset development. To overcome the many challenges existing today, the history book is entering a new chapter; that of container projects.

The status quo
To date, tier-1 operators have been issuing handset manufacturers with long lists of requirements specifying not only the branding and device settings, but also custom applications that ship with each handset model. For example Vodafone group have been issuing terminal requirements every six months that comprise 4,000+ lines of requirements. The operators motivation for handset customisation has been threefold:
– brand devices with the operators’ favourite red, orange, yellow, blue or magenta to (hopefully) increase customer loyalty.
– build-in support for operator services such as T-Mobile’s Web ‘n Walk or Verizon’s Get It Now to increase ARPU.
– bring services to the ‘front page’ of the user’s attention as with Orange’s Home Screen or Alltel’s Celltop, in order to increase discoverability and accessibility of services, and thereby ARPU.

So how has handset customisation been achieved ? Operators have been using three approaches to specifying the handset features and behaviour to handset manufacturers:
– use-case-based specification, as with T-Mobile UK’s list of websites that must be rendered and the time-to-render, for compliance with the operator’s Web-n-Walk service.
– technology-based specification, as with T-Mobile US’s MyFaves list of technical feature specs that have been reportedly passed to manufacturers for creating the MyFaves experience
– vendor-based specification, as with Orange’s preference of the Abaxia Mobile Portal client software on all of its Signature handsets based on Windows and Symbian.

Application-based customisation has been becoming a popular among operators – at the Handsets World conference in May Vodafone’s Patrick Chomet presented Vodafone’s new strategy for handset customisation, which includes provisioning four types of applications on handsets: a) a small number of core applications with a ‘deeper’ user experience, b) a full internet browser, c) an on-device portal for browsing and buying content and d) an application launcher and store-front for service discovery.

These methodologies have been practiced by tier-1 operators who have had the purchasing power to commit to handset volumes required by handset OEMs in turn for the copious efforts needed to implement the hefty operator specifications. Tier-1 manufacturers have typically demanded 100,000+ volume commitments which are achievable for operators with $7B handset investments per year like Vodafone, but not so for tier-2 operators with one or two millions subscribers. Consider the following two examples: Orange in early 2006 reported that it had convinced five out of its top-10 handset suppliers to support a controversial high-capacity SIM feature, leading the market one year before a similar standard was even adopted in the market, and four years before the (USB) standard is expected to reach mass-market penetration. On the other hand consider the example of a tier-2 Austrian operator who in early 2006 had to discontinue the on-device portal application which had been featuring on the operator’s open OS handsets for almost a year, because of the 4-6 weeks time-to-market delay that was caused by the acceptance testing for each new handset model featuring the software client.

This approach to handset specification has been partially succesful. It has taken tier-1 operators 5 years to develop the manufacturer relationships, the technology know-how, the organisational maturity and to master the process that allows them to bundle all their product and service wish-lists into a list of several thousand lines of requirements which is updated every six months. The challenges and the stories of trial and error have been so many that are impossible to list in a single post. We can however summarise the four key issues that are leading to a change of operator strategy:
1. Ensuring that the the time to market remains unchanged for operator-specified handsets vs those that are distributed via independent distributors and retailers (e.g. Carphone Warehouse). According to a Vodafone presentation at Handsets World, it used to take us two years to move from concept to mass-market availability for a Live service .
2. Limiting the costs of interoperability testing (IoT). Typically a handset will require three months of IoT and tens of DHL’ed packages exchanged between the OEM and the operator before the binary image is finalised. The set of several thousand requirements will have to be tested (usually manually) against each handset that is part of the season’s portfolio.
3. Ceasing control of the software suppliers that form part of the operator’s suite of preferred applications that feature on the handset – such as the Opera browser for T-Mobile, Cibenix or SurfKitchen for on-device portal functionality, and PacketVideo for video-streaming functionality. With tier-1 operators across the globe, including Vodafone, Orange, T-Mobile US/UK, Alltel, Verizon, Telstra and Optus who are mandating specific apps to be featured on their ‘signature’ handsets, management of ISV suppliers is of critical importance to operators. This includes not only app specification, but also control of licensing, marketing arrangements and network integration.
4. Platform fragmentation; Vodafone group report that is has to support around 20 software platforms across its handsets today.

Container programs: the new chapter
As of late 2006, a number of operators globally have embarked on what essentially constitutes the next chapter in the history book of handset customisation: container projects. Containers are platform approach to handset customization; a reference software platform which acts as the container for applications and customization elements and is then retro-fitted onto the operator’s handset portfolio. There is no formal announcements and no common definition of what constitutes a container program for example Microsoft refers to the same concept as the operator defined software image . I believe container programs consist of two pillars:

1. A choice of specific software platforms. Orange, Vodafone, Telefonica, T-Mobile and TIM have all publicly endorsed Nokia s S60 platform as a preferred platform. Vodafone and Orange have gone further to also list Windows Mobile and. Naturally these advanced OSes may constitute only 15% of the operator s user base for 2007. Selecting specific platforms means operators can pre-integrate their preferred applications and settings onto these platforms, which are then ported onto devices. Endorsing a specific platform means that the operator wants to reduce the platform fragmentation across the device sales base, but it does not alone imply a container program. Indeed a second fundamental pillar of a container program is:

2. A fundamental change in the process of managing partners . Up to now, the handset OEM has integrated operator-specified applications into the platform and managed all integration, licensing and testing. With container programs, the operator undertakes licensing of partner applications, integration on its short-listed reference platforms, testing and certification.

Simply put the container model is an operator-specific integration layer which sits on the device operating system; the intent of which is to decouple the service deployment lifecycle from the device delivery lifecycle.

To better appreciate what this means in the handset value chain, consider the following ‘before’ and ‘after’ diagrams, adapted from Microsoft’s insightful presentation at the recent Handsets World conference in Amsterdam.


Presently I m aware of at least two European operators who have embarked on container projects, with one operator planning to launch devices based on this new model in H2 2007. According to Microsoft, there are a total of 5-6 operators working on container projects today. In Korea, this model has been practiced since 2004 with the WiPI layer (originally intended to replace BREW), moving to Japan in 2005 with DoCoMo s MOAP layer (on top of Linux and Symbian), in 2006 with KDDI s BREW-based layer and in 2007 with Softbank s Aplix-based layer.

There are a number of advantages to operators in this approach, as mentioned in Microsoft s presentation at the Handsets World conference:
– reduced interoperability testing, and therefore reduced time-to-market
– lower costs by bringing new ODMs to market without huge investments
– higher revenues by faster rollout of new services across the platforms
– lower per unit royalties due to aggregate application licensing or buy-out arrangements
– better control of OTA updates
– better knowledge of software elements

Naturally, the challenges are equally noteworthy. Operators have to burden the responsibilities of the system integrator s role, i.e
– security and system integrity assurances,
– testing and certification of applications
– warranties and related liabilities
– software license management
– manage business failures of partners

What next ?
Is this new strategy in handset customization going to survive ? I would argue not. Firstly, operators have extremely limited know-how in software (in the same way that handset OEMs don t know how to run networks). Secondly operators are high-inertia organizations where sales cycles are extremely long (typically 12+ months) it s like try to steer a speeding truck without slowing down. Thirdly, operators will find it too costly to run partner application licensing, integration, validation and in-life support and will be feeling the pressure when the OEMs won’t be accepting liability for software-related business failures. In Korea where WIPI has been used as a service layer on handsets for the last 3 years, the challenges are becoming obvious even to the consumers; the general concensus in Korea is that WIPI adds a cost of $30-$40 to the retail price, and delays handset launch. Due to these challenges WIPI is no longer mandatory in the market.

The challenges faced by operator container projects is an opportunity for what I call a handset system integrator (HSI): an organization which combines professional services with software know-how (see Teleca, SysOpenDigia and Sasken) and is able to execute container programs on behalf of the operator. I would argue that operators should start outsourcing container projects to HSIs sooner than later.

In the meantime, handset OEMs are finding new ways to fight back in the never ending power game for customer control. Here s two: firstly, OEMs are already back into the service business (see Nokia Content Discoverer and Nokia Catalogs who sell post-sales inventory to partner service and application providers). Secondly, Nokia has been known to use a pre-inserted removable card to install its own applications on the handset when the user switches it on for the first time (now that s ingenious!).

The mobile industry never seizes to amaze..