There have been numerous situations in my career as a Product Manager where I’ve come into a project or product that’s so established and critical to client success that there’s a strong hesitancy on the part of anyone to dig in and muck with what’s “working”, even if it’s not really “working” in the eyes of the customer or user. This is, sadly, the fate of many B2B applications that have been in place for more than 5 years or so — B2B systems tend to be designed to meet specific goals and specific purposes, then have additional capabilities “bolted on” afterward, with little or no attention paid to how everything works together or what the overall user experience is.

And, what you wind up with in those cases is a runaway bus that needs to have the engine tuned, the wheels changed, the outside painted, and the upholstery redone — all while the bus remains in transit, and while it’s entirely full of passengers.

Unfortunately, in many of these cases, people just keep adding on to the bus — maybe a hood ornament here, a trailer hitch there, a spoiler on top, a trailer that’s big enough for a new bus that will never be built.

There is a solution to these situations, though — incremental transformative change. Big words for a simple concept: When you’re working on something under the hood, do everything that you can to make that component better — even if that means it’s inconsistent with the rest of the system. If you make it better, easier, and more discoverable, you will logarithmically increase the usability and satisfaction of your product.

When you’re working on something under the hood, do everything you can to make that component better!

Now, this doesn’t mean just make changes at random — that just results in a polka-dot bus with tie-dyed seats that nobody wants to ride. Rather, you have to ensure that you have a plan that covers the overall retrofit that you’re putting the bus through. You must have a vision of what that bus will look like when it’s all over, and be willing to work slowly and piecemeal toward that vision.

Here are a couple examples from my experience on how this works:

Working for one of the first companies to enter the electronic discovery space, I took on the challenge of reinvigorating their user experence. The platform had started as an on-premises install, then migrated to a pseudo-SaaS offering, but most of the original design constructs and user flows were quite terrible. We started by doing some light research, building out those user flows and pointing out that many common tasks were hidden under multiple levels of menus and sub-functions. We then built a design that focused solely on the document review panel — not on the production system, not on the loading system, not on the user management system, though we had ideas and designs for all of those as well. We validated the designs internally and with customers, then completely rebuilt the component from the ground up, in about 4 months of focused effort. We launched the new interface close to the beginning of the year, over a lot of uncertainty and discomfort from many people across the company, and in doing so we received nearly no support requests related to the new interface and decreased the overall ticket rate by about 8-10%. This didn’t solve all of the problems of the platform, but it did change a single component quickly, and with significant returns on the project.

Another example was when I worked for a company that facilitates the distribution of online retail data. From day one at the company, I struggled with their item details page, a common enough page for everyday shoppers to view, but practically useless within the context of the B2B app itself. It was one of the first things built for the platform, and showed its age every time someone looked at it. After convincing the executive team that an overhaul was needed, this was the one component that we tackled first — because it was something used every single day by both our internal service bureau as well as our external customers. We started with a brainstorming session that let the service team tell us everything that they could possibly want on the page, then narrowed that down to a few key use cases that we could tackle in short order: (1) viewing item details, (2) editing item details, and (3) channel information related to the item. We spent about 3 months iterating on the work, validating it with both members of the service bureau as well as customers outside the walls of the company, and we introduced the new details page incrementally as well — first as a beta, then as a fully-featured alternative view, and finally replacing the original one we achieved “parity” of its basic functionality.

In both of these cases, the original idea was to take a long and winding road approach, to start from scratch with the system as a whole and to take 12+ months of development time to re-engineer the entire system from scratch; and in both of those situations that would have been nothing less than a deathmarch project, as it would have suffered all the same issues that any waterfall approach would — by the time the changes were released to the customer, it would have simply been too late.