How Not to Drown In Your Portfolio Of Apps with Stefan Bielau from Dynamo Partners

Oct 2, 2017

Whether you have a lot of apps because you love making them, or you have inherited loads of apps through an acquisition, more apps don’t always mean more opportunity. It can also mean more headache – particularly if you calculate the cost needed to maintain, manage and optimize them. In this episode, our host and Chief Content Officer Peggy Anne Salz catches up Stefan Bielau, managing partner of Dynamo Partners, to discuss sure-fire strategies for migrating a massive app portfolio.


MOBILE GROWTH: We have an avalanche of apps. We’ve heard enough about that. We’ve heard about the number of apps, the number of downloads, the maturing of the app economy -it’s all about numbers and all about the fact that we have a large number of apps! The problem going forward may not be, ‘how do I soft launch my app and get another app into the marketplace’. Instead we might ask, ‘what do I do with a large portfolio of apps? I have a large family of apps that I’ve accumulated or through acquisition, etc.’ To address that other side of the coin, we have Stefan Bielau, Managing Partner of Dynamo Partners, a great boutique consultancy based in Berlin, Cologne, and Warsaw. Stefan, I understand that clients are coming to you and saying, ‘I have a large portfolio of apps, what do I do about it?’

STEFAN BIELAU: You’re right. Now for almost a year I’ve been involved in various projects where established companies either had assembled or acquired a portfolio of apps. For example, a competitor did not really differentiate when you look at the nature of the app, the features, its purpose. Or over the last couple of years they went into other countries, other markets and localized the applications and ended up with a similar app in various languages or localized versions. Being faced with this kind of complexity, a couple of companies have tried to test certain features in the wild with a standalone app before releasing such features in their core app. In realizing that they have assembled a certain number of users in this standalone test kind of feature app, now they are being challenged to migrate or bring over those users into the core app.

It also works the other way around. Some have found that a feature, per se, was so great that it was worth it to carve it out and launch it as a separate standalone app, whereas later the result did not work as well. How did I bring back those users into my core product? Those are the two playing fields we are looking at. On one end you have assembled a portfolio of apps of similar nature, on the other end you have split your app into a few different ones or tested out a couple features that are standalone. How do I bring back those users into the core app? That’s the key question here, and as I’ve mentioned before you’ll find something like this across all kinds of categories. We’ve been involved with a travel company that had such a situation, also a huge classified marketplace across countries and regions. That’s the migration issue.

MOBILE GROWTH: The migration issue, I can imagine, is going to be even higher on the agenda as we move forward, because that’s just what happens. I was talking to a brand marketer at a major health and beauty company, and he said his major headache is he’s looking out at 120 apps. He’s got to figure out what to do. Because in the first days of the app, every local subsidiary would do its own thing and have its own app. So it’s an issue for brand marketers, but also probably for gaming companies or those that have been acquired by another company. You have this problem, and there’s no single solution, but I would be interested in hearing what the challenges are with a potential migration project. When you go into this project with your client, what are you looking to address first, or what are the things that you just need to be aware of?

STEFAN BIELAU: First, I would say it’s complexity. If you consider the development, the release cycles, the updates, you must run finance and maintain it throughout the lifecycle of numerous apps; it adds up. The same is true when it comes to complexity in the data. Comparing certain things or aggregating a certain user behavior/user segments across various apps is always more challenging versus picking out one app and just highlighting the user case or user profile.

From a brand marketing perspective, I integrate clear call to actions which end up in a certain destination, like a link to the App Store or a link to a landing page if I have more than one app. I must make sure that the tracking works well, that I send a dedicated user to a dedicated destination, not mixing up across various apps with tracking architecture or link architecture. Wherever you look within the business of running an app: publishing it monetizing it, marketing it, if you have more than one that’s the way it adds up. Cost complexity, room for errors – this is one thing people realize and want to consolidate or migrate their app portfolio.

On the other hand, Apple and Google have a very strict policy when it comes to running similar apps in the stores. Twice we had a case where Apple and Google gave us the yellow card, if I can use a football reference, saying ‘hey guys we see you have more than one app basically doing the same thing. Maybe it’s a different name of the item, but the way the user perceives your offer it’s a similar app, and our policy states clearly, it’s not allowed to run such similar apps in the stores’. There’s a risk when you run your apps very close to each other. This can cause damage to your business if you don’t take care of it.

MOBILE GROWTH: What are your strategies? Obviously, it’s going to depend on the category of app. It depends on a lot of factors, but could you give me the top 3 steps in a strategy for migrating an app portfolio? A check list, if you will.

STEFAN BIELAU: In terms of the strategies, you can go the following ways: you pick your strongest one, meaning the one with the highest usage, the strongest download rate, the performance is the best across the portfolio, the one that’s really an outlier there. You really want to keep that one and make it the ultimate core app at the end of the migration project. To analyze and figure out which is your best performer, that’s a pretty easy job. Then you must build your milestone project plan around this destination, driving all other users from the other apps into that best performing application. It’s straightforward. It comes with the risk that if your current app is not straightforward or has some flaws, you might want to update it anyways.

We’d rather recommend phasing a migration where you pick out 3 to 4 of your best performing ones, and then group the apps in tiers and migrate those tiers into one of those 3 or 4. That leaves room for checking and measuring if something happens on the negative side. If there’s a huge error, you face it and you can pull out an application, or pause it, or dismiss an update. Instead of, on day one of the migration it sends all your existing users into an application that has an error when running an update. You should keep in mind there are many details around it. There’s product involvement across the field. It’s the marketing part, the analytics part that you want to make sure is all working fine when starting such a project. There’s a checklist that covers about 60 points, maybe more, but if you keep a close eye on product analytics and marketing you should cover the main issues.

MOBILE GROWTH: From another angle, how do you know if you have succeeded or failed? There’s some KPIs and some benchmarks to keep in mind, because it’s very straightforward. It’s about picking the best and combining it in the best way as an overarching strategy for migrating your app portfolio. But again, how do you know if you did it right or if you need to do something differently?

STEFAN BIELAU: In my opinion, the first indicator of success is that your message resonates with the existing users. What’s the reason why I should update the app or move to another one? What’s the biggest pain point you’re solving here with this new offer, from a user’s perspective. Make sure that this message is built out initially and then weave in your whole communications and marketing plan. If this really is a compelling offer, maybe even triggered or supported with an incentive to download the new app, then people will start clicking on a banner within the app they’re currently in, or reading your newsletter and responding to that or wherever you communicate this new application. That’s a clear KPI for success, if the top funnel starts responding and converting into the download of the new one. Then you look at your current download rate across the portfolio, and you compare how much download traffic your single or standalone app (or if only one app in your portfolio, you do the same) is generating. Look at your daily, weekly, and monthly active users, depending on the behavior or the nature of your app. You don’t want to lose out on the overall sum of monthly actives when migrating into one application and unpublishing the old one.

Ultimately, a good benchmark for how fast people convert into a new application is if you look at the version update rate you currently have. Whenever you run an update, you can measure how much of your existing user base is updating your application over a day, over a week, or any other given period. This is a good benchmark to apply when planning out your migration process. When you see, for example, that within a month’s time, usually 80 to 90% of your users have updated your app version, then within a month’s time you might consider 60 to 70% as a good benchmark or starting point for downloading your new app offer, or the offer of a new app within your portfolio. Obviously, it’s lower, because the nature of a download is more complex than an automatic update which happens in the background of your operating system. This is one thing I would apply when planning and measuring success of a project. What we’ve seen, at least in those projects we were involved with, you can achieve about 80% of previous users becoming new users of your standalone app after about three months’ time. It depends on the app, the frequency of usage, but that’s a good rule of thumb to have 80%, if you do a lot of things right and take care of minor details.

MOBILE GROWTH: I just want to wrap up with a quick question about exactly that. Obviously, there’s different sizes of portfolios of apps, but how much time and effort am I going to need to invest this year? In terms of money, if you could put some numbers on this, it’d be interesting to hear that as well.

STEFAN BIELAU: In terms of time, everything starts with a good project plan. You should invest a couple of days with your team, from the product development side and the marketing and analytics teams to go through a concrete project plan, establish a little dashboard to measure your assumptions against actual performance. Then you should rely on certain update cycles or review times. If for example you launch a new app, which becomes the destination, or if you want to update your best performer, you go step by step. It can be old apps into a new one, or it can be phases where you go through tiers that really determines the timing.

I would not give any particular timeframe for the overall project. Ultimately, at a certain point in time you should make the call if 10 to 20% of your users do not convert, despite the fact you have sent them push notifications, shown banners, sent emails or retargeted to get them to download this one single standing app. If this percentage does not convert, after 4 to 6 months, you might have to make a call and just de-publish and disconnect the service. It could be another trigger; if you say ‘hey listen guys, within the next 4 weeks we’re shutting down the service for this particular app, it will no longer be supported. Click here to get the new one’, then you should make the call on your own.

In terms of budget, there are internal resources and costs you must budget and give development time for a special app format or a re-authentication. If you want to accelerate and have a bigger impact on the whole project, you can put the media budget behind it when you start making the project work on day one and people start, per your internal communication, downloading your single standing app. If you put budget into this app you just amplified it with more downloads and more engagement. You might want to run retargeting campaigns, where your existing users are triggered outside your app or via your own operated inventory by a call to action to get the new app. So, if you want some media involved, play it smart and weave it into your project plan.

MOBILE GROWTH: Great segue way to wrap up!