Let’s say you work at a fast-growing subscription business, and you’re facing a huge amount of pressure to develop your service offering. You need to keep pace with the market, which is demanding more: more functionality, more optionality, more everything. So you see a quick opportunity to make a minor adjustment to a current service, by tweaking a bundle, changing a list price, or throwing in an add-on. No harm, no foul, right? You’re just pushing a tiny piece of code out to your website.
Now your sales team needs to be informed and enabled. Will this affect the way they structure deals? Will it affect their renewal process? Is there a new amendment that needs to be accounted for? Your legal team, of course, needs to consider this change from a contract perspective. Your billing team needs to account for it. Will it change the way you recognize your revenue? There might be compliance implications to consider. No one wants to see their CFO carted off in an orange jumpsuit.
These kinds of problems are only compounded, of course, if you’re chained to a strictly linear ERP system that is designed to process widgets on a conveyor belt instead of a constantly changing digital service. Lots of businesses have long outgrown their back-office systems, and are dealing with all sorts of nasty “bullwhip effects” as a result — in other words, a single anomaly creates a cascade of repercussions that ripple throughout the entire system. As the old eighties song goes: “One thing leads to another.”
So how do you avoid the dreaded bullwhip effect? Well, if you are Justin Donlon, Vice President of Process Innovation and Analytics at CarGurus,you decide to build a brand new technology stack that automates all of those anomalies out of existence! That was a particularly brave decision on Justin’s part, because CarGurus is growing like crazy. They’re currently on track to generate well over $800 million in revenue this year, at a YoY growth rate of roughly 50%.
Justin basically had to switch out the airplane engine in mid-flight! He was kind enough to share some hard-won lessons on enterprise architecture reinvention with Zuora’s Director of Product Marketing An Ly during our recent customer day event. I encourage you to watch the entire exchange on-demand, but here are a few key takeaways:
This is a strategic business initiative, not simply an IT project.
The decision to upgrade your tech stack should come from your executive team and your business partners, not just from your IT group. And preferably that decision should come well in advance of the project, from a list of long-term strategic initiatives. Why? Because you’re essentially building a brand new foundation for your company. In the case of CarGurus, they formed a steering committee that included the CFO, the EVP of Revenue, Head of Sales Ops, and Head of Product. This team decided early on that it was a better idea to start with a fresh set of systems than try to manually drag their old solutions into the future.
Work with partners, but manage internally.
Projects of this magnitude always entail the help of outside experts, but CarGurus made an early decision to manage the project internally because they didn’t want to be left with a system that was essentially built by someone else. This also forced them (in a good way) to deprecate their legacy system; their steering committee told all the key stakeholders that they were not going to put more than 30% capacity to their legacy system over a period of eighteen months. “That was kind of a frightening thing to say,” notes Jon, “but we knew we wanted to spend 70% of our capacity building the future.”
Two key hires: product manager and order-to-cash architect.
In anticipation of the project, CarGurus made sure to put a dedicated product manager in front of the IT team in order to help prioritize their work, knowing that the business was going to have all sorts of normal dependencies during the 18-month transformation effort. IT teams get barraged with incoming requests from product, sales, and finance even when they’re not reinventing their tech stack! The company also hired a dedicated order-to-cash architect to act as a management layer for all the new SaaS administrators they were bringing on.
Work iteratively. Avoid big bangs.
Rather than attempt to transform their legacy system in one fell swoop, the CarGurus team opted to work iteratively and in parallel. That meant starting with their smallest geographies and customer bases to stand up their new tech stacks alongside their existing legacy systems. “No amount of UAT (user acceptance testing) compares to launching something in a real-world environment,” says John, “And building out our new instances one at a time allowed us to iterate and test.”
Treat data as a first-class citizen.
It’s a mistake to assume that if you build your new system correctly, then its data will fall in line effortlessly. It’s an even bigger mistake to think that stitching legacy information with your new data is a straightforward task. Treat your data as is its own autonomous independent organism, with its own dedicated governance, rules and reporting, and headcount. “We even brought in an external party just dedicated to data, because we didn’t want to make the mistake of assuming that if the system is built right, the data will follow suit. It just doesn’t work that way.”