Pillars of a Mobile Strategy

Outlining a B2C Strategy

A B2C strategy is built around two pillars: reaching out to users and making them happy. Both pillars are quite generic and can be implemented in various scenarios with slight variations.

You may need to reach the largest audience possible, including holders of low-end devices devoid of flat connectivity rates. Likewise, you may need to focus on holders (and potential holders) of smartphones. You may need to push a mobile application with certain characteristics to keep existing users and make them glad that they chose your brand. Alternatively, you may need a mobile application to attract and engage new users by offering new services or new ways of consuming existing services.

Needless to say, a B2C approach is particularly suitable for companies that already operate their core business in B2C mode. It comes as no surprise that, according to the Gartner report mentioned earlier, the industry sectors most interested in mobile are transportation, retail, healthcare, software publishers, financial services, media, and in general, content providers.

Focus on Your Audience

Any business that aims at being successful should focus on its potential audience and make projections about the composition of this audience in terms of age and other social and personal aspects. With this consolidated information in hand, you can make better plans. In this regard, a mobile strategy is merely a specific form of business strategy.

A mobile audience is made up of people who own a mobile device and are (or may be) interested in the services you provide. Figure 1-1 depicts these two sets of users and shows how mobile applications fit in with your existing customer base.

Not all of your existing customers will become users of your new mobile infrastructure, but some generic mobile users will join the universe of your customers because of the mobile framework. This also should be read the other way around: If you don’t go mobile, you may lose a share of your existing customers who are also mobile users.

A Quick Look at Global Numbers

It may sound obvious, but I’m going to say this anyway: the world is full of mobile devices. For the most part, these are low-end devices with a basic HTML browser, a quarter VGA (QVGA) screen (240 x 320 pixels), perhaps a camera, an MP3 player, and a few games and utilities.

According to the 2010 statistics of the International Telecommunication Union (ITU)—the agency of the United Nations (UN) responsible for information and communication technologies—there are 78 mobile devices per 100 inhabitants distributed all over the world, and a peak of 114 per 100 inhabitants in developed countries (see http://www.itu.int/ITU-D/ict/statistics).

Whichever way you look at it, the data shows that there are a few billion mobile devices of any type out there. How many of these are devices (and users) that you want to reach with your application? Probably as many as possible if you’re Facebook or Google; a small fraction is enough otherwise.

The same ITU source reveals that there are about 30 Internet connections per 100 inhabitants all over the world, and 70 per 100 in developed countries. Although the two numbers are not directly related, this statistic gives a better approximation of the size of a potential mobile audience. However, according to eMarketer (http://www.emarketer.com), in 2011 the smartphone penetration in the world expressed as a percentage of all mobile devices is around 11 percent. That figure is expected to grow to about 50 percent over the next three years.

The data is more interesting when you look at these numbers for selected areas and countries. For example, the smartphone share grows to 37 percent in North America and 32 percent in Western Europe. It’s around 10 percent in Asia and stays below 5 percent in Africa and Latin America. Amazingly, the country with the highest penetration is Italy, with 47 percent currently (expected to grow to 67 percent by 2014). And this in a country—my country—that still has wide areas of digital divide, and where one family out of three doesn’t even have a home broadband connection.

The next section presents a few more numbers to help you understand the big picture of mobile connectivity.

A Deeper Look at Numbers

If you take global numbers literally, then by focusing on an iPhone application and disregarding mobile sites entirely, you cut off 90 percent of the potential worldwide audience—and even more than that if you consider that not all iPhone devices may be capable of running your application because of versioning issues. From this perspective, a mobile site seems to be a very reasonable choice.

Regardless of your final choice, blindly looking at global numbers is not necessarily the correct approach.

Suppose that after running a few customer surveys and having analyzed your website logs, you know that 50 percent of your real customer base use iPhones and connect from Italy. Given those figures, should you really focus your effort only on a mobile site? Probably not. A desktop site that looks decent on most devices, that looks good on iPhones, and features a native iPhone application is the best combination. Note that the costs of implementing the iPhone application dwarf anything else.

On the other hand, if your business is selling ringtones or news, then you need to reach out to the widest possible audience, regardless of the devices they’re using. A solution that reaches this objective with the lowest cost is your Holy Grail. Today, this means developing a solution based on HTML and JavaScript.

Facebook Was Not Built in One Day

In mobile, as well as in any business, time to market is critical. In laying out your strategy, consider applying an agile schema that lets you release applications piecemeal. Figure 1-2 presents the canonical Scrum process adapted to mobile projects.

The entire set of features and applications (“product backlog,” according to the Scrum dictionary, and labeled “Solution backlog” in the figure) is partitioned into multiple sprints or iterations. At the end of each sprint, you release a working segment of the entire application (such as an iPhone application) and then are ready to reiterate the same process for another sprint (for example, an equivalent Android application).

More often than not, sprints for mobile solutions also include the following:

• Arranging a website that’s usable by both mobile applications and sites. This means exposing the core functions of the website as easily callable, Representational State Transfer (REST)–based, HTTP endpoints. For example, if you’re building the website using the ASP.NET Model-View-Controller (MVC), this may mean exposing an ad hoc controller that can serve requests based on the use-cases that you implement in mobile clients.

• Developing a set of pages (scripts, styles, graphics, and presentation logic) for a class of mobile devices. You may want to start with high-end devices and proceed downward to enable more and more lower-end devices to access some fraction of the full site functionality.

• Optimizing the behavior of these pages with more accurate device-detection capabilities.

• Developing native applications for most popular mobile platforms.

• At each level, you can propagate valuable user feedback through the entire stack of applications you’ve built thus far.

To paraphrase a popular saying, “Rome was not built in one day.” I’d say that Facebook was not always the huge platform we know today, either—after all, it’s been around only a few years. A mobile solution, therefore, will look increasingly like a small platform of integrated services; it requires hard work and overcoming many challenges to complete.

Delivery Models

A B2C application is (ideally) distributed worldwide. The costs of spreading the word about its availability (not advertising...) are entirely up to you. A website is immediately available from any place in the world, but again, the costs of spreading the word about it must be borne entirely by your organization.

In the mobile world, appstores rule over the publication and distribution of platform-specific applications. You publish your application to the appstore, giving it instant exposure to users of a particular platform. Each device ships with an applet so that users can access the platform’s appstore—where your application gets published. Users can then access your application, read release notes, check requirements (such as that your application requires Internet access, phone calls, text services, local storage, and so on), see some screenshots, test-drive a trial version (if available and supported)—and what then?

What do you expect the return from investing in a mobile application to be? More generally, how do you expect to recover the costs of developing a mobile site and/or a few native applications? That’s another part of overall strategy that management has devised.

The Free/Paid Dilemma

Mobile applications are typically very cheap when they’re not entirely free. The cost of the average iPhone application is around $2—even less for games. The average iPhone user is expected to download (and pay for, if that’s required) about 80 applications in the course of a year.

Paid applications generate direct income subject to the marketplace tax (and, of course, government taxes). Free applications are generally built for marketing and branding purposes, or as an additional form of customer service.

After reading analysis and projections, expert opinions, and analytics, I formed the idea that mobile applications should be free; they need to generate revenue in some other way. However, if you’re an individual or a small company and happen to have a stand-alone (not bound to a strategic business plan) mobile application, why give it away for free? If it’s a well-done application that fills a hole in people’s mobile lives, you can likely recover your investment, and perhaps even more.

A third option is advertising-supported applications, which are free for users but generate revenue for the author through dynamically inserted ads. Switching to a paid or ad-based model is an important step. If you first release the application for free, you get a lot more downloads, which are good for feedback. It also helps you understand how well received your application is and whether it really fills a hole.

If you look into the most popular appstores such as the Apple App Store, Android Market, Windows Marketplace, and BlackBerry App World, you will find that there are almost always more paid applications than free applications. For example, in the Android market, free applications outnumber paid applications by about a 60/40 ratio.

The free/paid dilemma is not really a dilemma with a binary, black-or-white answer. There are a few other models that mix free and paid content according to different recipes.

The Freemium Model

The Freemium model is based on the idea that you provide the full application free and then offer users the chance to buy a few extra services. From a realistic business perspective, however, the Freemium model means that the vast majority of your users will consume your application for free; only a minority will pay for any extra services.

So how can this model be worthwhile (financially speaking) for mobile applications? First and foremost, you need a lot of users, preferably on the order of millions, and at minimum on the order of tens of thousands. Maintaining all these users probably has a cost as well. For example, if you need to maintain a website to provide data to the mobile application, then you have a growing cost directly related to the number of users. Even if your application can run as a self-contained device application, you still may have some costs per user because you have to support users and reply to their emails.

An excellent example of a mobile application for which the Freemium model is perfect is Evernote (http://www.evernote.com). These mobile applications work entirely on the devices they target; all they need is storage space. According to http://blog.evernote.com/2011/01/04/evernote-2010-a-year-in-stats, Evernote has more than 6 million users. Of those, only 3 percent pay an extra subscription fee.

Another example is Searcheeze (http://www.searcheeze.com), a new startup that offers collaborative search. Users, both groups and individually, can run and publish a search on a given topic. This search—realized by humans, not search engines—may be left free or published to an internal marketplace. Becoming a Searcheeze user is free unless you want to buy extra services, such as installing a private engine on your company’s servers.

The Premium-with-Free-Sample Model

The premium-with-free-sample model is fairly new in the media industry, but it’s already the model toward which most content providers and newspapers are moving. Basically, it consists in making a significant portion of the content available for a small fee but leaving a fraction of the content free for everybody to access.

The New York Times pioneered this model. It currently gives you a number of free articles per month, after which you have to pay a fee to access more content. In contrast, the Boston Globe locked three-quarters of its digital content and offers free access only to the remaining part. Repubblica.it, Italy’s largest news site and second-best-selling newspaper, also uses this latter model. In addition, Repubblica.it charges for access to its mobile site. In contrast, the desktop site is free, but you need a smartphone to read it effectively.

It’s worth noting that the Boston Globe mobile solution is based on a HTML5-powered mobile site, which maximizes the audience without incurring the costs of developing ad hoc mobile applications and, importantly, without paying the typical 30 percent marketplace tax to an appstore owner. Appstores, in fact, may impose ad hoc policies for in-app payment. During the summer of 2011, Amazon quickly modified the Kindle iPhone and iPad applications to comply with new Apple policies for subscription-based applications. At nearly the same time, the Financial Times application—a best-selling program—was pulled from the store because it was patently in violation of the store rules. As a result, the Financial Times now encourages customers to use its new HTML5-based mobile site, which—guess what—has been optimized for iPhone browsers and looks nearly the same as a native application.

The Quid-Pro-Quo Model

As an Italian, I would have used another Latin phrase to express the same concept: do-ut-des. According to Wikipedia, the English usage of quid pro quo in fact matches the Italian usage of do-ut-des perfectly, meaning “I give so that I can receive.”

This model is probably the one I feel most comfortable with. In my personal vision of the world, a mobile application exists as a complimentary feature, a favor that the publisher does for me. I reciprocate the favor by buying some of the publisher’s other content or services.

The free applications are entirely free; there are no strings attached. To use them fully, however, you need to buy or consume some other services that the publisher relies on for income. Applications you use in an airport, during a tennis tournament, or at a conference are all examples that fall in this category. You get some services via the application in exchange for the simple fact that you’re there (in airports or at conferences): you don’t pay directly for these services (mostly information and news), but you pay in some other way. For example, you probably paid to attend the conference or bought a ticket through that airport.

Here’s another example of an application that I had the pleasure of knowing from an insider’s perspective: I ported it from iPhone and Android to Windows Phone. The application is called Postino; you can find out more about it at http://www.postinoapp.com. Postino was originally built for the iPhone and then ported to a number of other platforms, one step at a time, as the result of a classic B2C strategy.

Postino lets you snap a picture as you travel and promptly creates a (virtual) postcard that you can send to a friend. The postcard contains a message, a signature that you draw on the screen with your finger, and an address. If the address is an email address, everything is free. If the address is a physical address, then you must buy a virtual stamp and upload the card to a server, which will print and send a real postcard.

An application built around a simple but good idea can be free, generate income in an indirect way, and still represent a success story for the developer (or the company), which may generate more business.