We always knew that Mobile apps mean different things to different people. But did you know that the same user sees different apps differently?

If we consider different Mobile apps as different features that get added to the Mobile when they are downloaded and installed …we can easily extrapolate the learnings of building a single app to the whole concept of Mobile Apps. So lets start with how one goes about designing a single app with multiple features.

While working on a multi-purpose mobile app, the product manager usually considers the frequency and duration of the feature usage and decides its placement priority within the app, monetization model and even resource allocation priority.

Let us say, there was a master Mobile application which planned to have multiple features such as News, Games, Chatting, Social Networking, Books, Utilities, Music, Medical Advice, Weather, Dictionary, Bollywood, and Travel embedded in it.

How would the product manager answer the following questions:

1) Which feature should he ask his developers to work on first?

2) How should he monetize each of these features?

3) After all the features have been developed, which of these features should be available more upfront than the others?

Simple. The product manager builds a frequency-duration matrix such as the one shown below:


*Please note: Here duration is not the amount of time user spends indulging in the feature (or the app) but the amount of time the feature is expected to be of interest to the user.

From the chart above, lets take Books for example. Single Books like it is for kids, get frequently used but then forgotten. If the feature is actually an eBook Reader with steady supply of eBook, the usage patterns would change drastically. Similarly features/Apps for Kids also have high frequency and low duration usage.

Until or unless it is a game-changing game such as Angry Birds, most games also have a short-lived life but with a high frequency of use. For such high frequency but low duration features I would suggest an immediate-and-now monetization plan – bill the user when he is about to use it for the first time.

It is interesting to note here that old school games such as Chess, Chinese Chickers, Ludo, Tic Tac Toe tend to have lower frequency but long duration usage.

Features such as chatting, news and Music are high frequency and high duration items. There is no best way to monetize these applications because everywhere else users get these items for free. And then, there is intense competition as well. So, the best approach to monetize this set of features (or apps) will be to indulge in banner advertising because these features can help serve tonnes of banner impressions. You can always try with subscription for specialized content – besides the free regular news you could perhaps try the subscription model on financial updates or Celebrity Pics etc.

Next comes Social Networking, which I would say stands alone…. with a little less than maximum frequency but really long duration. I say a little less than maximum frequency because users involuntarily tend to divide their Social Networking experience into – on mobile & on PC. This doesn’t apply to developed nations with good browsing speeds but in developing nations like India, likes, comments, and updating of status, uploading of individual photos etc happen via mobile. Consumption of friends photographs and viral videos happen on PC. Again, this is debatable so we will leave it here.

The last bunch of feature type that exists is the one with very low frequency of usage but very high duration of usage. Features (or apps) that are – Medical Advice, Dictionary, Travel, and other utilities fall under this category. The best way to monetize this category is subscription or in-app billing which user is exposed to once he starts using the feature (or app). To give you an example, Dictionary could come free but the Thesaurus which only a more evolved user is likely to use, could be paid.

The crux is: If you want your feature/app to be used very regularly and for months on end…choose your feature/app category accordingly. Also, choose your monetization model that is MORE LIKELY to work with your feature/app category.

As for your product, design it according to frequency and duration of use…always make sure features that will be used more often are upfront in your product design. And features whose frequency of usage is low…like Help, Settings, customizations naturally end up deep inside.

Any thoughts? Please share.