Russell Beattie

Here's the first of various business plans I'm working on right now. I use "business" and "plan" loosely as I'm a techie and so I'm looking at what's needed from a technical perspective, but these ideas may not be viable from a business perspective. Also, I am only thinking of things that I can implement. I have a certain skill set and I'm trying (this time) not to think outside that box.

The Idea

Let me start by stating what my view of the mobile market is. You can take a view of mobile phones, in my opinion, in two ways. One is as a standalone consumer device: A teen buys a phone and uses it for basic activities: communicating with his friends and playing games. You could say this is the Asian or European way of looking at the mobiles, and the fact is that this way of thinking has already proven to be valid.

The other way is to view the mobile phone as part of the digital ecosystem that we are now living in. This is more of an American way of thinking. We have a PC at home and at work and we have an smartphone or PDA in the middle to help us manage our data when we're away. Right now, PDAs fill the spot where the smartphone will fit in. And they manage their job by synching with one or both of the computers before detaching and going out into the world.

So I see there is an opportunity to fill a gap in both of these mobile worldviews by offering a service I'm code-naming "Dot Mob" as a mobile copy of Apple's .Mac online service. The idea incorporates much of the same sort of offerings in .Mac, but with additional eGroups style capabilities for interaction among mobile phone users.

The Market

My target market is Series 60 phone users, as to maximize the functionality of the service. The market for Java phones is much, much larger, but I think with over 10 million Series 60 phone users by the end of this year (and that's counting only Nokia's phones) this is a sufficiently large market. For comparison purposes, Apple's .Mac service has over 100,000 users at $100 a year, meaning they are garnering $10,000,000 a year in revenues from the service. To compare, 100,000 Series 60 users by year-end would mean that I'm only tapping 1% of the market.

One of the other reasons I'm targeting only a subset at first is to minimize development time and effort. Multiple platforms means exponentially more time debugging the service - which needs to be at a consumer level of Just Working - so that means starting focused and expanding later. A business is a business, however and you make money however you can, not based on some theme. My thoughts are to fill a market need but to also be open to changes as the customers demand.

Another reason that I think Series 60 is a viable market is that Nokia is selling these phones stressing only their multimedia capabilities. The carriers want low-cost MMS phones and that's what Nokia is giving them. However, the Symbian OS is a Trojan horse that will allow your phone to take the place of your PDA and become your main PIM - but only if the services and applications are provided first. By providing the abiliity to allow consumers to tap into unused potential on their phone, the service will be worth its price.

Like Vodafone Live!, packaging and ease of use will be key. But instead of heading towards a collision course with the types of services that the carriers will be providing, I want to aim at the high-end user. I'm not looking to provide games and ring tones, but to help the user of a Symbian phone manage their data. If you're a user of an smartphone with a PC, you can use the service I'm talking about in place of "synching". The data will be accessible from a central server

The Details

Here's the services offered by .Mac: Mail, Address Book, iDisk, Home Page (including iPhoto Albums), Backup, iCards, Anti-Virus, and Support. All of this is tightly integrated with the Mac OS and I want to mimic this level of integration.

Here's what I see as potential online services offered by Dot Mob (and I'll explain their technical underpinnings after), many are almost identical, others are more specific for mobile phones. All will be available via both the Web (HTML) and your phone (WAP/XHTML):

• Disk Space (mDisk)
  • Personal Backup
  • Secure Shared Disk Space
  • Save images, video, sounds, ring tones, apps
  • Backed up Messages (SMS, MMS)
• Photo Services (mPhoto)
  • Image Upload Server (from Series 60 built-in Images app)
  • Auto Photo Album
• PIM Functionality and Virtual Office
  • SyncML synching (using Series 60 built-in SyncML support)
  • Contacts (Address Book)
  • Calendar
  • Tasks
• Email
  • POP/IMAP/SMTP
  • For use with Series 60 built-in email system
• Greeting Cards (mCards)
  • MMS Sending of Cards
• Home Page - Weblog
  • Diary (moblog)
  • Different Templates (auto content)
  • Support for multimedia, etc.
  • Support for Weblog APIs - post to your normal weblog online
• News and Favorites
  • News Aggregation Services
• Support
  • Knowledge Base
  • Tips & Tricks
  • Priority Support for Businesses (Red Hat Style)
• mGroups
  • Forums (discussion)
  • Friends (presence)
  • Favorites (bookmarks)
  • Polls
• Database (forms)
  • Customizable Forms and DB
  • Shareable with Security (Users/Roles)
  • Used by people and businesses

Now this list may seem like throwing Spaghetti against the wall to see what sticks, but most things are low-hanging fruit that only needs to be organized and packaged.

Here's the technical comments on the services listed above:

Most "online" functionality will be packaged using HTML and WML/XHTML. WAP pages, as I've written about before, have become useful now that GPRS improves the speeds of the pages.

If there is a need for a richer UI - say for moblogging or choosing a photo-album template - I think I'd probably aim at using J2ME apps for their rapid development and easy install. Form-based J2ME apps are relatively straightforward to whip up as well as having it communicate with a custom servlet. Targeting only Series 60 phones allows an easier time debugging and a little more leeway in terms of design (larger screen, colors, sounds) than trying to target multiple devices.

SyncML and Image Uploading are integrated parts of the Series 60 Phones. They just need to be packaged and sold as a combined service. You can see an example of SyncML functionality being used at MightyPhone.com, and you can see the Image Uploading/Album functionality at FotoDock.com and Club.Nokia.com. Both services use HTTPS to send/receive data.

Email is a basic service that may or may not be provided already by the carrier. Packaging it as an integrated service is again low hanging fruit and depending on the plan you're using, may be cheaper alternative than using MMS.

File Backup and Sharing will need a custom Symbian app. There are already several "FTP" applications, but it would be nice to use a HTTPS based application instead combined with a server-side application to manage the files. This has benefits of being scalable, secure and controllable. The great thing about mobile data - at least at first - is that in general the amount of data being stored is smaller. Even if you upload 15 photos you took last night, you'll probably only use � a meg of data on the server. To seen an example of this type of application, check out BeeWeeb.com

MMS Greeting Cards is more low hanging fruit. From what I understand, all MMS takes is a WAP server and a simple SMS message. Send the specially formatted SMS message and then the User will download the MMS from your WAP server instantly. There are probably other uses for MMS that I haven't thought of yet.

I'm very excited about the Database part of the application. I think that this is will be a useful in a variety of business contexts. Say you're in the flower delivery business. Well first you go to the web page and you decide which fields you want to capture in a basic flat-file db structure: Say 'delivery time', address, etc. Then the "form" J2ME app downloads the XML description file of these forms and displays this custom form to be filled out - off line - which can then be uploaded later to the server and downloaded as a comma delimited file or even an Excel spreadsheet. There are lots of apps like this.

There are of course, other services that I'd love to provide, but would need lots of custom apps to do it. One I can think of off the bat is voice-blogging and voice messages. However, right now, if you record a sound on the 7650's built in audio-recorder, it gets saved as a proprietary AMR file. I'd love to have an app that could save voice to MP3 for posting online, however, that would take a custom app that isn't written yet and I don't have the skills or time to even try it. It would be a neat thought, however, to rebrand and resell some of the apps that are already out there like the various video apps and integrated them into the service. That would have to be later though.

The Business

So now let's talk about the business. Is this viable - both to start and maintain?

Well, the main flaw with this plan in my mind is providing a service instead of an application. Each user you add while providing a service costs you XX dollars more in bandwidth, storage, database, and support costs. Unlike the famous ROI on software, which has made Bill Gates a zillionaire, providing services online is a great way to go broke.

The good thing, however, about providing a service is the fact that you don't have to worry about pirates - which right now in the mobile world is running rampant. And you can provide the services as you develop them as well for charging for the real cost of each service. There's nothing that says that you have to bundle all of these services for a specific fee. You can provide more services as they come online and improve services incrementally.

However, that said, there's definitely a price point that you need to target. Apple is providing their services for $8.33 a month. Will that be too high or too low for mobile users to pay? And will it be enough to cover the costs of developing and maintaining these services?

As an additional source of revenue, the whole system can be packaged up to be sold to the telecoms. Everything will be written in J2EE, of course, so it seems like a good opportunity to write the apps with an eye towards selling licenses to telecoms and other businesses - both as a branded service like Handango's J2ME portal - and as a software package. I know personally I don't like to rely on small-company services any more because of the risk involved with betting your company on something that could disappear tomorrow.

To look at the numbers, it's something like this: to pay myself the equivalent of what I'm earning today (after taxes) I need to earn around $3,500 a month. Add to this the costs of running the server, say $2000 a month in storage, bandwidth and SMS fees and that comes out to about $5,500 a month I need to earn from this business. That means the number of users I need to pay myself fall along this scale:

 

Final Thoughts

There's obviously a lot more to flesh out in this plan: how to charge users of the service, marketing, security, and more. I think the kernel of the idea is providing packaged and easy-to-use data services to mobile users - exactly what, I'm not sure, but there's no shortage of ideas. Maybe some of what I pointed out above is overkill - geeky stuff with no demand. Other parts of the plan could be where the cash really is, but isn't getting focused enough. But I think that's part of the point. The idea in general is provide services that I personally wish existed today that aren't available, aren't easily available or available from too many sources. As others come online with these types of phones, they're going to be looking for similar services as well.

Comments welcomed. (In fact, that's the whole idea).

-Russ