When your software product needs an overhaul. Part I
Evolution is life and so it goes that every now and then an occasion arises where your software product needs a big overhaul. Be it a merger with another company, a new business model that requires a new app or a complete rewrite of the current system, all of these scenarios boil down to the same questions: what will that new situation look like? And how do we smoothly migrate from the old situation to the new one?
Just like any big change, a migration process might feel overwhelming at first. "Is full feature parity a Go or No Go?" "How will we maintain our high development speed?" "Do we need additional team capacity?" "And what about those app store reviews after the launch?" Truth is: yes it does come with some risks but proper planning and support will pave the way for a smooth transition both for your software team as for your users.
You’re nodding but not sure how to do that? In the past we’ve helped Payconiq by Bancontact, KBC Vindr, Stievie and many more to take the plunge so read on to discover our learnings!
Deploy or die
Let us first set something straight: at In The Pocket we are not a fan of big bang releases. It’s anti-agile and we just don’t like to put delivery on hold for a year or more to work on the next big thing or eliminating legacy software. It wouldn’t be the first time in the software world that this one year estimate becomes a multiple year project. Keep in mind that during that time of working full focus on the new product, you’re often not delivering any new value to your current users. That’s why we believe that digital products should be deployed as frequently as possible. It allows us to validate assumptions, capture feedback earlier, respond to demand sooner, fix issues faster and by doing all of that, deliver value and reduce risks earlier.
Set a goal
As always, the first thing you need when you start a challenge, is a clear goal that everyone is aligned on. This sounds easy, but often isn’t. The goal should make sense and should be solid, not only for business, but also for the technical teams. You’re one team, right? The goal should be ambitious enough to know where the product is going to be in the coming years, if it’s too short sighted, you’ll probably have issues with growing the product past its first release.
This is how we plant the flag at In The Pocket:
- We start with understanding the landscape the product is operating in
- Together with all stakeholders, we’ll come up with challenge statements: what do we want the product to solve?
- Once everyone is aligned on the challenge to be solved, it’s time to formulate and prioritise them as key objectives.
- These key objectives need to be made measurable to determine if we’re going in the right direction to reach our goals.
Craft the incremental path towards the goal
Now that we’ve determined the goal, take a deep breath and let this sink in: you won’t reach your goal in the first public release. But there’s a bright side: the quicker you have your first release, the faster you’ll start moving towards your goal.
This is where the first big question pops up: how will we evolve from our current app towards the new one?
You have 2 major options here:
- Introduce a new product and phase out the other ones
- Upgrade one of your existing products and phase out the others.
In general, there’s no good or bad option. It all depends on the current maturity of your product, the architecture,.... In the following table we’ve summarized our experiences in these kind of choices.
It’s also important to take into account how you will technically evolve to this situation. If you’re merging multiple apps, you probably have separate backends for them. What backend will you use for the new app? Probably you’re going to pick one of the existing backends and upgrade it, or you’re going to create a new one. But will all this work fit in the release schedule? Maybe you need an “in between phase” where the new app is giving the user an illusion of a unified product, while it is actually still working with some parts of the old backends. Multiple approaches are possible here.
In our next episode on merging software products, we’ll talk about how you know it’s time to flip the switch and how you keep your users close along the way.
