Welcome to the second post on my journey toward building a mobile app. In my last post, I talked about why I decided to write my own app. In a nutshell, I’ve never had the opportunity to product manage myself through the process of app development, so I thought this would be an interesting exercise. I don’t plan on revealing the nature of my app until the last post, so, until then, I’m charting the process along the way.
My first challenging decision was to figure out for which device I’d write my app. I know the stats — the entire Android community is outselling Apple’s iOS and behind them is RIM’s BlackBerry OS. The problem is, from a development perspective, each platform is different. If you write for one platform, you have to essentially re-write it for the other platforms.
One option is to use a tool like Phonegap, which allows you to write in one “language” and then deploy to the various devices. This seems like an easy choice — pick a technology that allows you to write once and deploy everywhere. Well, I’ve heard this before and nothing is as easy as it sounds. Another option is to write your app in HTML5 and deploy it to all devices that support HTML5. But not all mobile browsers support all of HTML5′s features, so you’re putting yourself and your project at risk.
Give the user the best possible experience
But enough of this technology analysis; the only thing that really matters is providing your users with the best experience possible.
In today’s app world, user experience is everything. It truly sets apps apart from one another. Any app that does not provide an awesome experience is not going to get good reviews or get picked up. In my last post I mentioned the new star-gazing app that I bought. The first app I bought did the job, but the user experience was not very good. However, my experience with the new app is awesome. I use it now exclusively. People are attracted to an app that provides a great experience and will share it with their friends.
My app has to have an amazing user experience.
The issue of loyalty
Users are loyal to their devices. Not only do they invest in a device, they also invest in a platform. Each platform has its own distinct look and feel. The buttons, symbols and navigation methods define the device. Just look at Android, iOS and BlackBerry OS — each has its unique style. As a user, it takes a while to learn this style. This learning is the soft investment a user makes in their device. They get familiar with the way apps on a platform behave. The way they navigate around the app becomes second nature and they intuitively understand what the button symbols mean. Apps with a different look and feel require an additional investment in learning by the user.
My app must have a native look and feel so the user feels right at home.
So what did I decide? I decided to write a native iOS app. My app is going to be available for iPhones. As with all iOS apps, it will also run on iPad, but where users will use my app is not conducive for iPad usage.
Why did I decide on iOS and not Android or BlackBerry?
I ruled out BlackBerry rather quickly — my app is a consumer, entertainment kind of app, and BlackBerry does not excel in this space. What swayed me slightly away from Android is the vast number of different Android desserts (froyo, ice cream sandwich, honeycomb, eclair, etc.) that I would have to support. Lastly is the cachet factor — iPhone has it, the others do not. (Note: The newer Android devices have it, but the majority do not.) My target user believes in having devices that are cool. They like to be seen with their cool devices. They like to dress nice (and dance cheesy?). Hence my decision to pick the iPhone platform. Once my app is available, I will monitor any requests to support other platforms and may at some point decide to make it available on another platform.
Now that I decided on iOS, I had to come up with a name for my app that:
- Did not conflict with any other name in the iTunes App Store.
- Is related to the functionality and value of my app.
- Had a domain name available.
That’s a tall order with all the apps in the App Store. Luckily, I managed to find a name that I believe fits those three criteria. The first thing I did was reserve the domain name. That way, I’m guaranteed to have a website for my app.The name you choose should contain a keyword that’s related to your product. It doesn’t have to, but I found that this helps your search ranking. If you are waffling between two or three names, reserve the domain names for all of your choices and decide later which you will go with.
So the pressure is on to build the app to a point where I can deploy it to the App Store, before the name or a close derivative is taken. Apple has a 120-day limit for name squatting, so if you believe that you can build your app to the point where it’s usable for users to try within 120 days, then reserve your name. Otherwise, you have to wait. In my case, I am going to wait.
My next post will cover the triumvirate — product requirements, user experience, and implementation — which I’ll balance with the process of building the Minimum Viable Product (MVP) — a real product management dilemma.
Peter Hanschke is an Ottawa-based product management specialist.