In our first episode on merging software apps, we talked about how we believe in continuous deployment rather than coming out with one big bang, long overdue, release. Setting a clear goal and moving with incremental steps towards that goal are key here.

In this second part we’ll explain how you know it’s time to cut the cord and guide your users towards the new situation.

When do you flip the switch?

Another crucial question that pops up is: when do you start phasing out the old apps? Most of the time, the first (or even only) strategy proposed to tackle this boils down to waiting for feature parity. It’s easy to see where this requirement comes from: it’s all based on the idea that you can’t take away features a user is used to. But is this really true? Start by asking yourself these questions:

• Do you have data that proves that users are using this feature?
• Does this data indicate that the majority of users are using this feature on a frequent basis?
• Is this feature a major value driver in your mission to reach your product goals?

It’s often seen that the feature parity argument is used because stakeholders are afraid that the reviews for the application will be bad. But look at it this way: users won’t give reviews purely based on features, they give reviews based on their overall experience with your product. Features are just the output of your product teams, and output can be good or bad. It’s the value of the features you want to focus on. Quality over quantity, outcome over output. Btw, one of our team leads wrote a great read on this matter. Check it out here.

Of course, the decision here is a little bit different in our two scenarios we sketched in our previous episode. When you’re upgrading over an existing app, the old feature set is basically lost, so your cut off point to make the switch will probably require some additional features in comparison with the other scenario where you temporarily have the new app next to the existing ones. But in both cases, it’s favorable to get to this cut off point in the shortest amount of time needed. So this will mean you’ll need to think about dropping features. Luckily you can also use this as an opportunity to clean up your product debt. Some features made sense at the time of creation, but years after that, they could just be a weird legacy. The most important lessons here are that the timing and the feature scope of the cutoff point should be clear from the beginning, as well as the way to reach those requirements, otherwise, you end up maintaining the old system for many years to come.

One more thing about user reviews: it’s very likely that in a first phase, your user reviews will go down a little bit. It’s not in people's nature to love change, most users need some time to fall in love with changes. So you need to show your users that there is value in the changes, and the best way to do that, is by giving him the high value features first. As change is very difficult for people, you have to make it worth the effort they invest in it.

Guide your users

Another aspect you can’t forget about are your end users. How will you guide them towards the new app experience? You can’t just throw them in the water and expect them to swim, you need to guide them.

When you’re phasing out one of your old apps, you should let them know in advance. You can do this in multiple phases:

• Inform them about the new application, start a campaign in your current product to inform users about the upcoming product.
• Start nudging them towards the new application. You can start easy on, but can start pushing harder when the deadline for the switch approaches.
• Block the old application and force them to use the new one.

These scenarios are only valid in case of a new application next to the existing one, but even in the other case of an app upgrade, you can do a gradual migration by using beta’s with opt-in possibilities.

If you’re using the new app approach, also think about the actions users have to take to make the switch. How easy are they? Can you make it easier with e.g. a transfer account feature between the two apps?

Controlling the risk

Rolling out a new app for an already existing and possibly large user base is always a risk. This is why you don’t want to do this all in one day. To mitigate this, you could set up multiple tracks.

• Internal closed beta: eat your own dogfood, before you let others test your app, first setup an internal testing program to make sure that you ensure a decent level of quality
• External closed beta: once you’re pretty sure about the quality, you can go to a beta program with external users. They will be the first users without background knowledge and are often very engaged with your brand. They will forgive you the early bugs, and can provide you with valuable feedback before you go to the mass market.
• Phased rollout: once you’re ready for a public release, consider using phased rollouts. This will gradually increase the amount of users that have access to the new app version and give you time to follow up the data to see if everything is going well without affecting all your users at once.

This is not a one time use scenario, the above strategies combined can form a release train that has a regular release schedule and builds in certainty for every release you do in the future. It’s a best practice throughout the software development industry.

‍

Conclusion

There’s a lot to think about when you’re considering such a major pivot with your product, but it is perfectly possible to make it a less scary operation when you follow the right steps. It’s all a matter of knowing where you want to go, make that goal clear and follow up on it. It’s essential that business and tech go hand in hand in every phase of this process to make it a success: none of these decisions can be taken alone, there will always be trade-offs that need different insights to find an optimal balance and efficiently reach the goal.

Want to see this in practice? Check our work for Payconiq by Bancontact, KBC Vindr & Stievie.