Top 8 rules for mobile entrepreneurs & application developers

If you are a mobile entrepreneur or on your way to become one, you probably know that there is something different about being in the mobile space... And if you don't know, then you are about to be surprised...

So as an entrepreneur that has been surprised a few times, and to save others the surprises on the way I tried to compile here a list of rules that are unique for the mobile space. I tried to be as thorough as possible but if you have any additional rules you're more than welcome to post them as a comment. Anyway, here goes:


Have a solid operator / carrier strategy

When asked about their operator strategy, a lot of good startups will say: "Operators? We don't need them! Our product is going to revolutionize the value chain, in fact the whole idea is that with our product you can bypass the operators...". VCs love hearing that sentence, or to be more accurate loved this sentence, as it is definitely easier said than done - the fact is that most startups might begin with these statements, but down the road, they and their VCs find out that working without the carriers is quite difficult.

You have to do the marketing on your own, you have to overcome a lot of business model/technical issues and the walled gardens of the operators don't allow you to really bypass them, at least not without losing 90% of your potential customers. So after being a "brat" for a few years, these startups mature and start to cooperate with operators which are a natural partner for mobile startups.

Now don't get me wrong, I think operators still hold too much power and are too afraid letting go, which makes things very difficult for application developers (read my post on launching an app in the US). A more open environment will probably boost the eco-system and in turn benefit the operators themselves. And someday this will happen, but that day is not today, and in the meantime you have a startup to run and a product to sell...

So instead of wasting precious time and resources, establish an operator strategy from the beginning. It doesn't mean that you have to go hand in hand all the time, by all means take advantage of off-deck opportunities if you have the resources to market on your own, or if you find a suitable partner - you can also launch something offdeck to make some noise and grab the attention of the operators - but in the end operators are still one of your best chances to get to the mass market.


Mind the data costs (or: forget about the viral effect)

If you provide your application for free and expect it to have the same viral effect free web apps have, you're in for an unpleasant surprise. Nothing is really free in mobile, which is both good and bad for you... It is bad because users who want to download your app will have to pay the data costs for the download. If your app also makes subsequent use of the network - data costs will strike again... In fact virility in mobile takes a real blow from data costs, which makes it harder to provide viral experiences such as Facebook, YouTube etc.

The good side of things is that users are okay with paying for services on the mobile, unlike the web 2.0 standard which is everything for free, just come and use our app... But then again, trying to make a non-free application viral is much more difficult, and here is exactly where the problem is: Even if you do make a free application, the carrier will still charge data costs, which still means no money for you (which you're okay with for virility puposes), but no users as well...

It is true that there is some movement towards flat data rates which can help things, but as it stand now data costs are very high around the world, and the billing structure is not transparent enough or understandable to users, so a lot of them are simply afraid to use data on their handset. And don't get me started on roaming charges (which kills a lot of applications).

There is no simple solution here, but here are some thoughts: Partnering with an operator can sometimes take the data costs off your back. If your game/app is on-deck, a lot of operators allow free access to their portal, so at least the download itself will be free. Same goes with network use inside the application, you can try to negotiate a zero-rated network use for your application - the chance of that happening is highly dependant on the specific operator and the region. However, note that even in cases where the data is free for users - some users have had bad experiences and do not want to take a chance, so they avoid any network use.

If you don't have a (good) deal with the operator, which will be usually the case, just make sure you communicate (in your web site) to your users all the info related to the data costs, so there will be no surprises. Also if possible, try to lower as much as possible network use inside the application - use data compression to lower the amount of data sent, and make your protocol as minimal as possible.


Mobile phones are not PCs!

This is a very important rule which is overlooked too often. Mobile is a different media than the Web/PC. Not everything we do on the web we would like to do on mobile. This point becomes more important as technology advances, since in the past you couldn't do much on mobile, but today you can. However, this still doesn't mean you should...

One of the biggest differences between mobile and PC is the screen size. While PC screens get bigger and bigger, handsets feature small screens, and will stay that way, since one of the key elements of a mobile phone is that it should be mobile... So, while you enjoy watching TV on your 42" TV at home, or even at your 22" PC screen, doing that on a mobile phone is not that comfortable and can be described as a "second best" in a good day. You have to adapt the experience to the medium. For example even if you wouldn't watch a full length movie on your mobile, you still might enjoy a 5-minute funny clip.

Another difference is the input method - handsets have limited space for keys which leads either to a numeric pad or a very dense qwerty keypad. Neither is very comfortable for writing long documents (but short emails are okay). Also while I would enjoy playing a complicated game on my PC or console, doing that in mobile is simply impossible, which leads game developers to follow "the rule of thumb", meaning you can play their game with one thumb only...

On the other hand, mobile has some clear advantages in some areas, and they can be utilized to give a more in-sync experience. The most important feature of a mobile phone is again its mobility. This led to the replacement of many MP3 players by handsets, and the same cruel fate happened to some really good digital cameras... Another area that is about to flourish is location services. You can give the user info and offers on where he is when he needs it (But of course, mind the data costs...)

Of course, every once in a while something comes along and changes the rules, and with the input mechanisms this was the iPhone with its touch screen that opened a lot of options to make things that were not suited for keypad phones to become mobile.

In anycase, just remember you are running on a handset, even if you can do anything you can do on a PC on it (And we are not far from that day). For more on that refer to one of my first posts called Mobile is a different medium than the Web/PC/TV.


Choose your Platform

Web 2.0 entrepreneurs have an easy life, don't they?... They have to support one platform only called the web browser. Now it's true that there are some nuances between IE and Firefox/Safari, but again these are nuances which can be overcome by good coding practices. Different operating systems? Not really, with Windows dominance on the market this is a non-issue (Plus the browsers serve as a VM for that purpose). Server-side platforms are also a non-issue - you can choose whatever you want: Java, .NET, PHP etc. as long as you serve HTML pages, your application will work on any browser without any special installations. Perhaps the most difficult and significant issue is Flash vs. Java (client-side) for those making extremely interactive content such as games.

And what about us in the mobile space?.... Well, not looking too good... A multitude of operating systems and VMs: J2ME, Windows Mobile, Symbian, Brew, Linux, iPhone, Android - all cannot be ignored and have a significant market footprint somewhere in the world and for some type of applications (or will have one in the future). Unlike the web-world, the differences here are not nuances: Applications written in one platform will simply not work in the other (or in some case like J2ME on Symbian will work poorly).

As a startup usually you don't have the resources to develop to all these platforms and you have to "choose your poison"... This is not a very easy decision and can make or break your success. There's also a lot of hype to the newer platforms such as iPhone and Android, and this can be confusing since though it does seem they have a bright future, their actual install base is quite small compared to more mature platforms (See my post on that).

The important thing to do is to choose the platform according to the users you are targeting and the play you are looking to make. If you're a game developer and your target market is Europe then no doubt you should start with J2ME. This is by far the de-facto platform in this GSM continent. Your games will also run on Symbian devices with Java VM (i.e. Nokia series-60) though will probably be slower and more buggy, but it's an okay compromise to make until you have the funds to issue a Symbian version.

If your target market is the US on the other hand, your decision is more difficult. J2ME should be a good way to go, but since US J2ME devices are some years behind Europe, you might be limited in VM resources which will lead to reduced overall game quality. On the bright side there's a good play to make in the US with BlackBerry (which can run a slightly modified J2ME code).

Also there are a lot of Brew devices in Verizon which is the biggest operator in the US, a Brew play might make sense especially if you have some good connections in Verizon, as Brew is basically a walled garden, no way getting something on the air without the operator. But again - just make sure you start with one platform, and advance to the others. And of course there's the iPhone - a play on its own where you can maximize your innovation and get a pretty good market in the US, but again this is not the mass market.

If you're going to the Eastern markets, you have to carefully learn the situation there. Starting with developing countries with very basic devices up to the mobile power nations Japan and Korea, which have their own platforms (i-mode, WIPI and more).

I can go on and on here, but you get the picture: Choose one platform and focus on it. Just make sure you choose the right one for you.


Establish a porting strategy

After you choose a platform, your troubles have not ended, they are just getting started... Even within the platforms themselves there are a lot of variations in the handsets. Starting with operating system/VM versions which are not always backward compatible (i.e. Windows mobile version, J2ME MIDP1 vs. MIDP2), going through unsupported or buggy features or APIs in some devices and ending with the simple fact that devices have varying screen sizes, processing power and input mechanisms (For the issues in J2ME take a look at my J2ME Porting 101 post).
This requires porting of your code to hundreds of different devices. The cost of porting within the same platform is not as high as porting from one platform to the other (which is basically a code rewrite of the entire app), but still when talking about hundreds of devices, this aggregates to a very nice sum... And bear in mind that porting is not a one time thing, you have to maintain or redo the process every time you issue a new version...

The key to survive porting is, again, to know your target market. It is okay not to support every device in the world, or even in your market. You can start with key devices and progress overtime to additional ones. Just make sure to find out which are the key devices are for you - i.e. what devices most (or a big share) of your potential customers hold. Obtain metrics from metric providers and reports on the web, and don't rely on hype.

Also, give some preference to easy targets (For example SonyEricsson devices are known to be pretty portable when it comes to J2ME), and forget about devices that give you too much trouble (unless they're critical) - it is not worth it spending 2-4 weeks just to port to some stubborn device...

As for the porting itself, some prefer to do it in-house completely, some using 3rd parties tools and some outsource it completely, usually to offshore porting houses. There's no right way here, it depends on your needs.

Obviously porting houses in India, China and Eastern Europe can provide with competitive pricing and some already have a well-structed process for porting - this is all they do, so they must be good at it... But as with all outsourcing processes, it has some overhead and the distant communication also doesn't help, but still it takes a huge load of work from your employees that can focus on the development of the product.

If you plan to issue new version frequently (and have the resources to do so), meaning you do frequent porting, then porting might be something you keep in-house - you can either use 3rd party tools to manage the process, or build your own framework, which is not as hard as it may seem.


Make sure users can actually use your app...

Everyone who deals with usability in mobile will tell you it is simply hell... If creating web applications that are easily understood by users is a difficult task (and it is...), then doing the same for mobile is simply a disaster... Crunching all the info on a tiny screen while trying to let the user to interact with a limited numeric pad is a hell of a challenge.

Usability is a major factor that will determine if your application gets adopted. Don't test users' patience - they don't have a lot of it - if they can't understand you app in 2-3 minutes they will never use it again. This also stands for the distribution of the application, there's a lot to improve in the download experience - some of which you can't affect and is in the domain of handset vendors and operators, but there are some things you can make easier for the user (i.e. SMS with a link to the app, sign your app to avoid as many installation questions as possible etc.)

As for the application itself - the key to success here is not to get wild. Remember that the average user is not a super-geek like you (or your CTO...), in fact the profile of mobile users in terms of technical capabilities is even lower than PC users. So keep things very simple. Also, it is very useful to see what others have done - don't reinvent the wheel, look at other mobile applications - some of the biggest UI challenges have already been solved in some way that users have gotten accustomed too, so you should probably follow the same guidelines.


Use the power of convergence

Being a mobile entrepreneur doesn't mean you have to stay in mobile only. There's a whole eco-system around us, and sometimes your success can come from connecting with non-mobile services or applications. This can sometimes be fruitful for both parties.

Now, don't get me wrong, sometimes a mobile-only play is the way to go, for example if you develop non-multiplayer mobile games, you don't necessarily have anything to do out of the little screen - your games look great on mobile, but don't compete even with PC titles dated 5 years back... On the other hand, if you're a mobile VoIP provider, connecting to PC VoIP providers can do you only good. If you're in the social networking space, communicating with the online networks and fetching data from there can do wonders to your app. And how about saving data to known portals, syncing calendars with online calendars etc.

Also, if your service is a success on mobile, you can try to see if opening the same for non-mobile users makes sense. Sometimes it doesn't because the service you offer is unique in the mobile space but too crowded in the "regular" web. But sometimes you can bring something different to the mix, relying on your mobile strength. This of course is more relevant to more mature startups, as focus is very important, so you should expand only after you gained some traction in one medium.

In any case, the key here is to try to see the full picture. Can your application or service connect with online services in a beneficial way for your users? Will a non-mobile version of what you do now can work? If the answers to any of those is yes, go for it (Just make sure that the answer to "Do I have enough funds to make it happen" is yes as well...)


Don't listen to rules...

The last rule is simple: Don't listen to rules... Mobile is a new space and there's still a lot of practices we haven't found. Some of the things that look like Axioms today, might change along the way and open new opportunities. Perhaps you'll be the one to discover them when not following any rules...