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...
I would concentrate on iPhone and Android development, these platforms will dominate the next years, and if you have enough ressources, do a bit in JME (but do the first named before).
The really cool, next apps will come from the Appstore and the Android Market and will run on Smartphones likes the ones above.
January 30, 2009 5:27 PM
Hi Ofir, great
post. The first rule left me wondering what would a
solid operator strategy be? I'm asking because I've been trying to
establish partnerships with operators to have our product on-deck and
so far I've been unsuccessful, even though I tried pitching revenue
sharing - something they're not too interested given the nature of our
product and the fact that it doesn't have traction enough yet to cause a blip on
their radars -, advertising partnerships, etc. but it seems that until
we reach a very large audience they'll keep the ball rolling but not
advancing in the game. Would you mind sharing some insight on this
topic? What are the best ways of approaching operators?
January 31, 2009 8:23 PM
Ofir Leitner said...
This is a good question but not an easy one...
Operators are quite known for being not very accessible. The general rule of thumb is that the bigger the operator is, the more difficult it's going to be to reach a decision maker... And of course the real trophy is to land a big operator rather than a small one...
Operators are flooded with a lot of applications and services and have to choose which ones they promote. In order for your service to catch their attention, it has to bring them some value - and not necessarily money. For example, some operators want to be perceived as innovative/young etc. - if your app is very new and edgy, it might play directly to that and they might even promote it, even if it's not a cash cow.
Still, monetization is a key factor, they will love to share revenues with them if you can prove you have a killer service that generates a lot of money - but for that of course you need some market proof and reputation.
To obtain that reputation you probably have to work with an operator (chicken and egg...), but this is actually doable - coming back to my first point - you can start with smaller operators that are more hungry for innovative services, even if you don't earn a dime, and after you have a case study - go to the bigger ones.
There is also the aggregator way, which is not suitable for every service, but can work for you - these guys have direct working relationship with operators, and though they take another cut out of the pie, it might be useful for the first sites.
There's probably a lot more, and if any of the readers had positive experiences with their operator strategy - you're more than welcome to share them here.
January 31, 2009 11:01 PM
Very good post, i think many of the young startups I see should give it a read.
Re. the question raised of how to build an operator strategy i'd like to add my 2 cents here.
1. Don't go for the big guys as your first move. Although it is very tempting to have Vodafone on your customer list, the penetration costs (time and money) are huge and the competition is huge, i would suggest to try and have several small ones, it's a quicker (relatively) sales cycle, the backoffice integration & performance req. are sometime less challenging and it's usually the best "jump point" to the big ones (ref. customers and prove of model)
2. Rev. Share sounds like the holy grail, but in many cases it is not. Although the pitch goes like :"no risk here, if we bring rev. we'll both enjoy it" from the carrier perspective, each such app require investment from it's network, IT and finance deps. and ofcourse involve risks by introducing a new service to their customers which are not very tolerant.
that's just out of the top of my head now, i ususaly advise to brake down the "strategy" to a specific list of carriers, learn them, see what models they were using with other vendors and try to build the right model they are "used" to chew. (In many cases, having the right partners, SI or aggregators, will prove as a good start until you know better how to approach them)
February 1, 2009 10:57 AM
A very good post with several good insights. I specially liked your last rule - like in the French language, you sometimes find that there are more exceptions to the rules than patterns that follow the rule.
Few points that I'd like to add:
1. The most important is to listen to be open to ideas, and be willing to modify your path as you go. I've seen too many companies that tried to explain to the operators that they know better what's good for them.
2. I completely agree with the comment made by Naor regarding the big operators. Too many startups were killed (or shall I say - suicide) by making their first sale to Vodafone... These guys are very demanding, and the sales processes there can take forever.Do it only if you have deep pockets and a lot of time. Oh, and the myth about the big guys paying a lot, is indeed a myth...
3. I'd like to point out another phenomena that we start to see in Europe - the App Stores. Every operator creates their own App Store, and the easiest way for them to handle mobile applications is to push them to this store, that is sometimes more like The Carmel Market.... In this case, the developer needs to take care of the advertising and the placement in the menus, or otherwise they will find their application on the 72nd page.
4. Another comment is about data schemes - today in France most of the contracts are for "unlimited" data usage. Not going into the issue of the limits of the "unlimited" offer, this is an advantage and a drawback - on one hand, free data usage is good for increasing the usage of the mobile applications, but on the other hand, you can't sell to the operator that you application "will increase their revenues from data usage".
5. The last comment - don't try to do everything on your own. Choose well your target markets, and get the best people you can to sell in these markets. It may cost you a bit more in the short term, but will save you precious time and efforts.
February 2, 2009 10:44 PM
@cpinto Flirtomatic have a good middle-ground operator portal strategy - they just buy advertising space! Most operators now sell inventory on their portals so rather than go through a whole palaver to get "placement" you just buy an ad. This gets you the benefits of being on-portal without the hassle.
On viral marketing on mobile - some startups ARE starting to work out how to get viral effects going - see here
February 3, 2009 6:20 PM
Mariana Oliveira said...
I really liked your post. It's very valuable to those who are begging in this market. It's not easy, but who said it would be?
Being at mobile market for over 10 years showed me some points:
Excellent team is essential and if you have a good idea, be the first. There are many opportunities worldwide to enjoy. Good luck!
February 3, 2009 7:03 PM
Good post. With all the platforms out there, we do see a trend, there are those that will only target certain devices like the iPhone and the BlackBerry (at least in North America), and then others who need to be on as many devices as possible, thus requiring JME.
Then even in that camp, there are those that will spend hundreds of thousands on apps, and others that need to bring them market quickly and easily.
Depends if your app is the next big game, or something a bit more straightforward, like content aggregation.
February 4, 2009 5:49 PM
I have a comment regarding #4 - Choose your Platform. Depending on what sort of demands a mobile application has it's quite possible it could be a web app supported by a number of device-web bridge products that allows the same application to run across a number of different mobile platforms while at the same time leveraging device specific functionality. This approach, where possible, significantly reduces porting efforts. There are a number of open source products, including phoneGap (http://phonegap.com/) and QuickConnect (http://sourceforge.net/projects/quickconnect/) and even a standards initiative called Bondi (http://bondi.omtp.org). Worth investigating.
February 12, 2009 2:49 AM
Thanks for the well considered post. There is no question that all these points are valid. If you are a small start-up that has limited time and money don't bother with all of that insanity. Develop for the iPhone and get a revenue stream going or develop for the Web and get traction. Trying to even talk to key decision makers inside big companies is a lot harder than getting users to believe in your product.
February 19, 2009 11:13 PM