Migration is a Strategic Challenge, not a Technical One

As recently as 2015, “we’re rebuilding our product and need to migrate users” was a rare problem. But with the pace of technology and pervasiveness of technology in our lives, it’s increasingly common.

The common reason for a re-platform is technical debt. But that doesn’t mean the migration plan should be left to engineering.

Technology creates the problem. Strategy/product needs to solve it.

Yes, I’ll say it again. The problem stems from technology, but it can’t be addressed that way.

Many teams see re-platforming as a temporary pause, a pit shop to tune up the engine so you can accelerate faster later. It assumes that ONLY technology has changed since initial decisions were made.

Building *anything* comes with a cost, and for a period of time, you’re going to be building something that is not adding more value to customers than what already exists.

Sobering thought, I know. From your start to our launch you’re devoting resources to something with no direct increased customer value.

With our limited resources, we always have to focus on the biggest impact.

Is it to minimize costs, or increase revenues? Team goals may be different, but I’d go with increasing revenue. Therefore, the focus shouldn’t be on “build as fast as possible” but rather “onboard customers as fast as possible.” Get an ROI on what you’re investing in.

When I was doing product strategy for ReadyTalk’s new video conferencing platform (later branded FoxDen), the team started with an initial hypothesis of MVP. We needed video, voice, app share and bling. Yes, our early presentations had the word “bling” in them. This represented the secret sauce that was going to offer the jump in value that would entice people to switch.

Early on, I’m sure stakeholders thought we’d have to eventually migrate over all the functionality from the existing platform. We product folks really hoped that wasn’t going to be the case.

It’s inevitable that over time, a product will bloat. We add support for new use cases and types of users. Technology trends change and new interaction patterns are adopted. Frankly, it’s hard to remove something from a product once users have seen it.

So, we aimed not to replicate the feature set, focusing instead on the ‘job set’: the jobs our users were trying to get done.

In designing our new platform, we strove for job parity, not feature parity.

One of the first features we safely dropped from scope? Application share. You may or may not remember, but web conferencing platforms use to let you share a specific application (Word or PowerPoint) with participants. Over time, “Share your desktop” or “Share your screen” was introduced, and enabled essentially the same primary action as Application share. Screen share is a lot easier to build, so “application share” came off the list.

The joy of this being a strategy initiative is that we had access to our existing customers. We rolled out the product as a beta for some of our existing customers, and could monitor their usage and have interviews with them.

One of the most fascinating interviews I’ve EVER held was during this study. We were speaking with users who had access to both platforms, to understand when they might choose to use one platform versus another, with the aim of identifying critical “tipping point” features.

One participant had a clear difference in his mind for when he chose one product over the other. “When I’m speaking to a peer vs having a more formal conversation.”

He wasn’t using any additional features. It was really the brand and interface that drove his choice, given the context.

So what do you do with that sort of information?

Obviously, this was a single interview, but it launched a thread of new inquiry. This was a customer voice, an outside force, that could have impacted our planned rollout. Again, had we seen this purely as a technical problem, with a goal of mapping functionality as quickly as possible, we may have missed this signal.

One of the toughest questions of migration is “what about the rest of the world”. Again, not a tech problem. By migrating, do you expect to continue support existing users only, or to pick up new ones? If the latter, you also need to consider their needs in your strategy.

Back to ReadyTalk, our old platform didn’t support video well. So had we asked customers about the relative importance of video, they would have rated it low. But we knew we had to grow our customer base (which, after all, was part of the reason for the new platform: to enable things the old platform couldn’t easily support).

Re-platforming is expensive. Doing it with the sole goal of just supporting our existing base will not make your finance people happy.

One of my favorite questions to ask a team is “if you were to start a company today to compete against us, what would you do?”. This is a great way to break free from perceived constraints. If it’s too expensive to invest in something today, are you willing to pay the cost down the road when your customers leave for a competitor? Re-platforming is the opportunity to break free from old decisions. Given the market and technology of today, where are your resources best spent?

“If you were to start a company today to compete against us, what would you do?”

Eventually the day will come when it’s too expensive to keep supporting the existing product. Remember that profit trumps revenue, and if you keep a platform running solely to “not lose a customer” and not because it’s profitable, you’re operating off emotions. Sometimes the best way to deal with a customer that costs more to support than they pay you is to be forthright, and encourage them to find another provider that may be able to better meet their needs. Leaving this on a good note can build the goodwill and keep the door open for a possible future where their needs may dovetail with your product direction.

Every product decision should be made with the aim of generating the most value for the company. The decision to re-platform is no different. Just because your initial product was developed with a certain target market and business model in mind doesn’t mean that can’t shift. Indeed, you don’t have the same feature set you did with your first release, do you? No, you started something, then learned and iterated on it. Your re-platforming initiative needs to follow the same pattern. Some features just don’t make sense to build, despite the fact that someone somewhere may want it. And as always, the “should we” is a strategic, not a technical, question.