There are over 1 million Chicagoans using android devices so it is important to the startup in their ramp-up to proving a product is viable to find out what set of features will ebcome that viable product as than that test can be refined for the USA markets. But what is a mobile application product?
To the un-trained for example, TransitChatter seems like a product, but its not and lets dissect why. Most mobile buys are impulse decisions. That means you want something of high affinity for groups of high affinity items as features.
In travel applications one of the high affinity items is the map user interface. The direct map user interface is not the high affinity item, its the feature that you can implement that allows the end user to plan their commute that is the high affinity item. In fact its such a high affinity itme that iPhone users are recjecting Apple Maps because of that high affinity item.
The other aspect is that a group of features must be releated. In TransitChatter you have a chat feature that is not related-able to the other feature items such as transit travel times, etc. If the feature items are not connected via the UI implementation than one does not act as the end user funnel for the other feature to encourage engagement, etc.
An example might be displaying, in our TransitChatter example, travel times of the transit route right in the chat of a particular transit route. But sitll you have to have both the high affinity features and using the UI implementation to group and relate features together to grab the end user through an impulse buy or download and than gain their use of the application as a daily habit.
Its the difference between a so-so-average mobile application and a great one like Instagram. If you are a startup hiring that first android consultant to do a temporary project of building your android version of the product you want them to in fact collect end user metrcis and change the implementation as far as the feature set, etc to get the magical push-and-pull between grabbing the end user impulse to buy or download the application and the pull fo how the UI and feature set is implemented in relating to every feature and relating that to the edn users activities in how those things pull the ned user into that magical daily habit that translates into engagement and product success.
Often time you as a statup when you first start implementing the andorid version of the application you will have to let the android developer change things from that blueprint in your head to march towards an actual successful viable mobile application product. Its a challenge to get that push-and-pull between the impulse end user buy or download and the engage of the end user right.
For more code technical writings, view my Android Blog.
