As a Product Manager for consumer-facing apps, I have had this dilemma before. Should I split up the mobile app offering into more than one apps to the consumer? How do we address the potential changes to the app portfolio?

The app portfolio dilemma

The existing app – let’s call it App A – had been around for some time. It served as an end-user engagement tool, and not as a monetization tool. The potential second app – let’s call it App B – could house some specific features that differentiated the overall offering of the brand. I had one of the two following choices: 

• Either split it into two apps, with each app serving a core purpose. Like Facebook had split up their Messenger functionality from the standard social media app.
• Or stay focused with just one app and evaluate how much of the added functionality would go into App A

To split or not to split?

The Decision-Tree

There are plenty of variables that go into this decision tree. Few of the crucial parameters included the following:

• Who’s the user? Will App A & B be served to the same or different target users?
• What’s the purpose? Is App A and B serving completely different purposes, or is there an overlap? If there’s just one app, is there a risk of feature bloat? Will it result in disengaged users?
• What about user acquisition? Do we have a marketing budget to run campaigns and get users to download App B?
• How about engineering complexity? How does keeping one vs. two apps impact code complexity? Would there be more or less effort to maintain these one or two apps? What are the implications of maintaining and supporting one or more codebases?
• What about org readiness? Overall, splitting the apps, would it be worth the extra effort at training the org about these features? The customer-facing teams like call center & support, marketing content teams would need training on these. Is it worth it?

Decision & Rationale

With the above parameters in consideration, we decided to keep the app portfolio to just one.

Yes, let’s stick with the one app!

In the meanwhile, the delighter functionality was instead added to App A. While thinking through the above decision tree, the following were the conclusions for each of them

• Who’s the user? It’s the same target audience. Even if the apps were split, they would still target the same end-user. Would he/she care about installing more than one app for one brand? If the apps were split, we would need to convince the user to install yet another app from my brand.
• What’s the purpose? If split, both apps would still ‘engage the user’, albeit there would have been one material difference. App A would continue to be a utility app delivering ‘basic needs / must-have-features’ as defined by the bottom quadrants of the Kano Model. App B would, however, would deliver ‘delighters’ to the end-user. This was a big motivation to separate. However, the possibility to monetize through this would be a big ask.
• User Acquisition? Low budget allocations from marketing to an app-product that drove engagement was the norm. In the grand scheme of things, selling revenue-generating TVs acquired a large chunk of marketing $ as opposed to this. Considering that, running campaigns to drive downloads of App B wasn’t realistic. Serving the existing user-base of App A and growing it organically was the way forward.
• Code complexity? Splitting them up to apps A & B, could simplify engineering complexity, yet, on the other hand, supporting and maintaining two different codebases didn’t seem worth it. The single App A with a common code base appeared good enough to deliver the value we expected.
• Org readiness? If split, there would be a steep learning curve for the end-user touch-points. It meant higher effort and the need for additional continuous training to the various support functions. Given the capacity constraints on that part of the org, adding yet another app to the portfolio would strain the teams, hurting our ability to deliver good customer service with the existing portfolio.

In Summary

Deciding whether or not to split the app portfolio is a complex decision. It can, however, be simplified through the lens of the customers, starting with customer value and following that up with business viability.