A Product Manager’s Guide to Replatforming [Mind the Product]

Replatforming is arguably one of the most difficult things you can tackle in a product management career. And if experience is about learning from mistakes, let’s just say that I have a lot of experience on replatforming.

First,we should start with a quick definition. Here, replatforming is about replacing the computing platform on which a number of other products or systems are built. It’s the foundation that, for instance, powers a website and allows developers to add pages and features.

Replatforming can become very complicated, very quickly, for at least three reasons:

1. IT platforms are usually the backbone on which a large part of the business is running. Replacing them is an expensive and high-stakes endeavour.
2. They tend to have a relatively long lifecycle, up to several decades in some cases. By the time they need to be replaced few, if any, people from the original team are still around and, in any case, and no one fully understands the IT in detail.
3. Over time, platforms evolve organically and carry the legacy of previous business models, markets, or pricing strategies. This gives each platform a unique twist and makes each replatforming project unlike any other.

These challenges make replatforming a messy affair right from the start. And then it gets worse. Some research from Forrester indicates that “key performance indicators (KPIs) take a hit after a replatform goes live. For example, 39% of companies surveyed reported their conversion rates were negatively affected after a new platform was launched, while 44% saw a decrease in site load time.”

Done right, however, replatforming can deliver significant competitive advantages and be instrumental in supporting the business through another major period of growth. Here are some practical suggestions that can help avoid common problems and make the most of the opportunity. Although I’ve written this post in the context of replatforming a high-traffic B2C website, many of the principles can apply to other situations like apps or B2B systems.

Three key Recommendations

1. Avoid replatforming and rebuilding the site at the same time

This is a common mistake, rooted in the way a company arrives at the decision to replatform. There may be a multitude of things that the leadership team wants to achieve, and each one would require a prohibitive amount of time and money with the current platform. As a result, the investment is tied to delivering the new things wanted by the execs through a new platform. For instance, at Zoopla, when we attempted to make the site responsive on the old PERL monolithic platform, the number of quickly issues grew exponentially. It was decided that it was time to build a new platform on which we’d build the new responsive site.

But doing both at the same time goes against the grain of incremental iterations from which you can learn. If you change everything at the same time you can end up with too much to analyse and test and you’re left unable to work out why some areas are underperforming. It takes time and slows down the replatforming rollout. Another issue is that when the team building the new platform is also building the new pages, then UX and UI have little to do during the periods when most of the work goes on things invisible to the user. And bear in mind that the longer the rollout takes, the longer you carry the risk of misreporting performance while you manually consolidate performance numbers from two platforms.

This is why you sometimes hear people describing replatforming as replacing the engines of an Airbus while cruising at 40,000ft. There’s little room for error, and it often ends up taking much longer than anyone has planned for.

So what’s the alternative? Where possible, you should aim to decouple the platform from whatever it’s powering. Replace the platform and rebuild the products it powers to the current specs. It is less wasteful than it appears. The user interactions of the old platform are already designed, and perform at a known level. Running it on a better platform reduces the risk of the combination of the new UX and new platform under-performing against the old system. It allows for small incremental improvements which are easier to integrate and test against the old platform. Finally, it allows the team to have a very simple and clear list of objectives instead of constantly having to balance short-term fixes with long-term investments. If you cannot keep the same UI, at least keep the UX as close to the existing site as possible.

TL;DR: build a new platform but lift and shift as is whatever it is powering, don’t reinvent the experience at the same time.

2. The Platform IS a Product

Even if you’re able to separate replatforming from redesigning the products that run on it, there is still a risk that the platform is treated like as a technical prerequisite and not as the product that it is. This can lead to the new platform missing out on opportunities to provide the organisation with additional competitive advantages. Product thinking is absolutely needed when it comes to setting a vision and looking at the platform from a wide range of stakeholders. It can prevent the risk of finding out later that the new platform is not suitable to a category of products or users because the technical solution envisioned is not feasible for all sorts of non-technical reasons.

I experienced this first-hand when I was head of product at PhotoBox and we realised that the choice for a new CMS platform had not sufficiently taken into account particular types of users. The old CMS was a very technical affair that allowed the team merchandising the site to publish HTML, CSS and Javascript without a release. This technical approach had significantly contributed to the staggering amount of technical debt that the front end had accumulated. The solution was simple: use a modern off-the-shelf CMS that would allow non-technical marketeers to run site-wide promotions. But two problems surfaced very quickly. All the merchandising team saw was unacceptable restrictions to what they could do and they radically disagreed with the idea of not being able to push out any HTML, CSS or Javascript. To make things worse, the non-technical marketers saw more work coming their way and struggled with the interface. It was too technical for the marketers and too basic for the technical members of the merchandising team. I wish I had seen it earlier, but I wasn’t really treating the platform as a product. My priority was on developing a great user experience for our customers. My list of stakeholders was centred on external users and I had not given enough consideration to the internal teams.

The learning point? A much better approach is to assemble a platform team with at least a technical architect, some developers, a technical business analyst and a product manager. The team is then given a clear problem statement along with some boundaries and then left to zero-in on the right solution. With such an approach the stakeholder mapping is much simpler and weighted towards serving the real users of the platform. This approach also allows you to look at the platform in terms of what it could do to provide the business with some competitive advantage – by looking at the natural strengths of the organisation and designing it so that it uniquely leverages them.

TL;DR: treat the platform as a product, not a technical prerequisite needed before you can build more advanced products.

3. Bring in Outside Talent

• If you don’t have a good technical business analyst, start with that. We’re not talking about a product manager helper here, you need a world-class business analyst able to extract from the existing platform a blueprint of exactly what it does and how much each detail really matters to the business. According to Jawwad Farooqi, scrum master at Zoopla, and also a senior business analyst, agile coach and replatforming specialist: “One of the things I would suggest is build up a strong analysis of the as-is system. You should come across a number of features that are either duplicated, depreciated, or unused. Also some features / business rules can be merged together to provide a better functionality. For example, you may find out that out of 50 different types of discounts you offer, only two or three are actually being used.”
• Try to find a product manager with relevant experience in building and migrating platforms. They differ from a more traditional product manager as their focus and experience centres on developing a long-term asset for the company, one that will deliver competitive advantages where possible. This suggests someone with strong strategic skills and extensive business experience because they will end up reinventing how a lot of people do their work. They will also be more focused on how to serve the various stakeholder groups using the platform and support them in developing a great user experience.
• The third key player you need is an experienced technical architect. The traditional way to build a first platform is to start with a small problem opportunity, add features incrementally and refactor your way to a great infrastructure. But when you already have a platform, you have a lot less room for emergent design in the architecture choices for the new platform. What you decide will ultimately dictate whether you’re able to migrate everything you intended to or not. These choices are strategic because they are very difficult to reverse later. That’s why it makes sense to enlist the help of an architect who can steer the project so that options can stay open as long as possible, at a minimal cost.
• Finally, as the technical foundation on which the business currently operates, the existing platform has shaped the way people work and the type of employee that is hired. A new platform is not necessarily good news for everyone. For instance, the developers of the PhotoBox merchandising team were all too aware that the company’s trajectory could make their jobs redundant. It’s only human to resist what threatens your value to the business, however good it is. According to scrum master Farooqi, an organisation should consider adding some transitional/temporary roles like change managers, coaches and project managers. Typically these people will be contractors, their role will be to deal with the wider commercial and HR impacts of the migration.

TL;DR: your team is probably inexperienced in replatforming, so bring in some outside specialists.

So, yes, replatforming is messy. These three recommendations will hopefully help a little. What’s your replatforming experience? Please share your views in the comment section below.

The post A Product Manager’s Guide to Replatforming appeared first on Mind the Product.

Source: Mind the Product http://www.mindtheproduct.com/2018/01/product-managers-guide-replatforming/