The New Product Leader: Dealing with Legacy Tech

Intro

At some point in their career, every product leader will take a role in a company where they’re exposed to that classic nightmare known as a “legacy platform”. It might be something that you need to integrate with, it might be something that you’re being asked to replace, or it might just be the heart and soul of the company and product that you’re tasked with owning. Regardless of how you’re presented this beast, there’s solace to be had in knowing that you’re not alone and that there are some time-tested tactics that you can use to approach the process of improving on and slowly replacing such terrors.There are two kinds of software projects: those that fail, and those that turn into legacy horrors.-Peter Weinberger, co-creator of AWK

Understanding the Legacy

While it can be very tempting to go into a situation where there’s legacy technology with guns blazing, demanding to update anything and everything that you can, therein lies the path to ruin. There’s usually a reason (sometimes a good one) that a product and a company are relying on legacy platforms to do what they need to. And that’s our job as a product manager -- using the same skills and methods that we would rely on in discovering customer problems to uncover the underlying reasons why the company and product continue to rely on legacy software or hardware.The bottom line, especially in B2B contexts, is likely to be that there’s revenue coming in on the platform and a fear that disrupting the legacy underpinnings will threaten that revenue in the long or short term. Either that, or the fear that the cost of reworking and updating the technology will wind up being higher than the cost of simply maintaining the existing status quo. Regardless of the reason, we have to be cognizant of the financial implications of any updates or refactoring that we will want the company to consider -- these things don’t just happen in a vacuum, and you rarely have the opportunity to just R&D some new platform in private without making changes to the existing systems.You’ll also commonly see upper management taking an “if it’s not broke, don’t fix it” attitude, and preferring to apply resources to tacking on even more functionality to the existing legacy underpinnings. And while this is understandable -- especially when there’s revenue associated with the platform and its inner workings -- it’s also usually a position taken out of either fear or lack of understanding. Fear that the reworking will either start a death march of constant tinkering, or a lack of understanding of how updating the technology will actually benefit the company and the customer.‘Legacy code’ often differs from its suggested alternative by actually working and scaling.-Bjarne Stroustrup, creator of C++

Use Allies to Find Pressure Points

If you’re coming into a new company or onto a new product, you’re going to need to start the process of updating things by working your internal network and building your social capital in the organization. The best resource you can have for moving forward with your desire to update things is to figure out where the tribal knowledge exists within the organization -- something that you’ll discover if you do the research advised above. But once you know who they are, and have established a trusted relationship between you, you’ll need to start poking and prodding to discover the weak points of the legacy systems. You want to slowly build up a list of all of the potential failure points that exist due to the aged systems that are being used.But we don’t want to use those points as the primary ammunition as we start to move forward. Think about it -- almost everyone around you is happily chugging away, making money enough that the company’s growing and expanding, and here comes this new product leader telling them how poorly-designed and fragile these systems are that underpin everything. As the old saying goes, you’ll get more flies with honey than with vinegar -- and that’s precisely what we need to do. We need to take what we discover about all these failure points and catastrophic scenarios, and bounce the new technology off of them so that we can sell the benefits of the new approach rather than the weaknesses of the old.And, the best way to do this is to start pushing for new resources who are as familiar with the new, unused technology and approaches as they might be with the legacy underpinnings. We need to try to slowly build up the organization as a whole to somewhere that we can succeed when we get the opportunity to start updating things. And, by and large, where there’s a large body of legacy technology, there’s also a large number of resources who may not be as familiar with new approaches as others out there in the market -- simply because they haven’t needed to be familiar with it. They’re happy doing what they’re doing, with what they have -- so we need new blood in the organization to revive these discussions and push for improvements that others will overlook if given the chance.The idea that new code is better than old is patently absurd. Old code has been used. It has been tested. Lots of bugs have been found, and they’ve been fixed.

• Joel Spolsky, Joel on Software

Evolution Before Revolution

Assuming that we’ve done all the heavy lifting of discovering the reasons why the legacy architecture is in place, begun the process of building a coalition of interested parties willing and able to bring things into the present, and we’ve sold the company on the benefits of using new and updated technology, we’re faced with the obvious question: now what? Simple -- figure out something small and relatively innocuous you can meddle with that’s unlikely to trigger those fears mentioned above -- revenue and stability. Generally speaking, there are always projects that lie on the periphery of the core platform -- APIs, UIs, and internal tools can be a really great place to start. In fact, with all of those things, you can wire in future goals or needs that can be put in place in a fault-tolerant fashion -- so that when you can light up something new, there’s instant value found in work that you’ve already done.There’s two reasons to start with these small, evolutionary steps. First, they’re usually small projects that can be done relatively quickly, with a small resource impact, and that you can use to demonstrate success rapidly and definitively. Second, you’re not putting any recurring revenue or any of the fundamental stability of the product at risk if you’re updating something that’s already been or needs to be “tacked on” to the underlying platform. Both of these factors allow us to be relatively certain that we’ll be able to show The Powers That Be that new technology isn’t as scary or dangerous as they think, and let us take the next step, then the next, then the next, until we’ve managed to change all of the wheels while nobody on the bus was any the wiser.What we don’t want to do is try to jump right in on something that’s mission-, customer-, or product-critical. Remember that legacy systems are there for a reason -- they’re reliable, they’ve been tested over years of work, and they’re the life-blood of the current system. Messing with those components as a first effort is like performing your first open-heart surgery as a resident medical student...but without any supervision or assistance. You’re equally likely to do something to cause the patient to flatline as you are to succeed in your efforts. We need to minimize the risk that we’re taking on, because we’re trying to assuage fears. And the worst thing that can happen in these early efforts is to make a significant and revenue-threatening mistake. If you approach the problem piecemeal, one small component at a time, you’ll have significantly more success, and each such success will lead to more leeway and flexibility on the next project.Every once in awhile, a new technology, an old problem, and a big idea turn into an innovation.-Dean Kamen, inventor

Putting the Pieces Together

The end goal of all of these efforts and this overall framework is simply to build trust, negate uncertainty, and push the company and product into the present or future where its technology is concerned. This will not happen overnight, and it will not be without struggle and setbacks. As product leaders we need to be diligent in balancing the needs of our existing customers and our existing product’s success and footprint with the need to expand, revise, and improve on our technology. We cannot expect The Powers That Be to bless our efforts at using new and improved technology just because we want it to be; we need to convince them first that it’s the right thing to do, then that it’s the safe thing to do, and finally that it’s what will allow the product and the company to maintain its growth and success in the customers’ eyes. If we can do all of that, then we can slowly chip away at those legacy horrors such that they can be relegated to a small closet in the back room that nobody ever opens again.