Rationale behind the “app constellation” mobile strategy

It’s been over a year since Fred Willson coined the term “App Constellation” and Foursquare broke into two separate apps. However, while this strategy has gained adoption and momentum, it’s still an open question as to whether this approach is a successful one.
 

Mo Apps, Mo Problems?

The basic idea behind “App Constellations” is that, in mobile, well-established companies tend to launch portfolios of apps, rather than a single “all-in-one” product, like we’ve seen on the web.
 
There has been some recent debate, on Quibb, and CB Insights, as to whether this strategy is working. The prevailing argument is no; since these additional apps have not gained traction (as judged by installs / App Store rankings) this is a failed strategy…with Facebook Messenger as the lone breakaway success.
 

App installs are a worthy goal…sometimes

Classifying app installs (i.e. customer adoption of the ancillary apps) as the primary metric of success, only tells part of the story — and will certainly point to more of “failures” than “successes”, particularly as we’re so early in the mobile era.

So, it’s worth exploring a few of the the underlying rationales, behind an “App Constellation” strategy, and thus the appropriate measures of its success.
 

Strategy #1: Extension (“going broad”)

Let’s start with the case where installs is the best success metric. With this approach, the platform is looking to grow its user base by acquiring new users from other sources. Therefore additional apps are employed to do so, via 1) acquisition (e.g. Facebook & WhatsApp, Dropbox & Mailbox), or 2) launched internally as a new line of business (think of a new “tab” or “section” on the homepage as a web-based analog).
 
Expansion is the primary tool of a successful company that has already reached critical mass in its primary market (or has a predictable path to achieve it), and needs to grow overall. Here, “installs” is a fine metric; however, when using this approach to test new markets / opportunities, it is fully acceptable to mothball failed apps (see Twitter Music, Facebook Poke), or to roll them back in as features of the main app. So failure to achieve app install goals, can be just as important, in those cases.
 

Strategy #2: Unbundling (“going deep”)

A multi-app strategy is also employed to drive retention & reuse with the existing platform, by providing existing users more & different ways to engage with it. In this case, perhaps a more apt term than “app constellations” is really “app families”, where “parent” apps spinoff functionality into “children” apps (the additions to the family over time). The underlying rationale, behind having multiple applications, is twofold:

1. Breaking off the specific use cases to either optimize them (i.e. make it simpler / easier than in the main app and avoid “low-end” disrupters), or;
2. Allowing specific use cases to be extended and take on a life of their own, and thereby remove them from the shackles of the parent app.

Examples of this unbundling approach are Facebook & Messenger, Foursquare & Swarm, Instagram & Layout, Twitter & Periscope.
 
We can assume, in this model, that both parent & child apps coexist on the user’s device, with the dominant acquisition channel flowing from the parent app to the child one. As a result, it is highly unlikely that the child app will ever gain the traction of the parent app. So, a better success metric than installs is whether existing users of both apps are more engaged with the platform than just the parent app users (based on time spent, frequency, activity, etc.).
 

Strategy #3: Replication (“going global”)

A final case for multiple apps is where these extensions span different geographic markets, or completely different customer segments, rather than multiple apps to the same user. In that model, “app constellations” are critical to reaching new users and tuning functionality to meet the needs of separate user bases. Here end customers may not ever interact with multiple applications.
 
For example Starbucks uses specific applications for each geography, rather than an “all-in-one” like Uber. This unbundled approach enables each application to pursue its own development path and be unencumbered from the main one (i.e. no release in the US App Store for Indonesian support).
 

Mobile is still really, really early

It’s way too soon to say to judge winners & losers of app constellations yet — especially if we judge by installs. Instead, we need to properly account for the underlying strategy the company is pursuing, especially as it scales, and enters new markets. Moreover, we should also keep in perspective that we’ve had a solid 20+ years of consumer internet, where “portal-based” strategies applied vs. ~5 in mobile where streamlined and specialized experiences seem to rule. So, there is still lots of room for evolution.