I’ve been working in startups for almost ten years, and in the fast-paced world of software development, staying ahead of the innovation curve is essential. Continuously improving, and updating our solutions to stay competitive. So when I was tasked with revamping our tool’s main dashboard, I felt empowered to deliver an impactful change. I followed the discovery processes by the book (or so I thought). I talked to key users and enthusiastically made a plan to remove all the legacy features and outdated elements. Little did I know that this seemingly harmless act would turn into a colossal mistake…

Interviewing users to create a new dashboard

Before changing this core element of our software, I conducted a thorough survey with our key customers to gauge their opinions on the current design. I noted down all the frustration points, to ensure our new dashboard would resolve their current pain and issues. Based on that feedback, I worked alongside a talented designer and we strived to incorporate all of it into our new interface. We developed new concepts, simplified the global navigation, and highlighted the main point of interest our customers should focus on. We worked on new design elements, and we carefully removed ALL points of friction to ensure a seamless experience for our clients. After many rounds of revisions and internal testing, we were finally satisfied with the result. We then presented the new design to our clients, showcasing how their feedback was taken into account. Hoping to blast them with the improvements and the new user experience. But we faced a huge backlash instead.

Understanding the Legacy and Historic Features

In our rush to make changes, we deleted some key functionalities that some customers were very attached to. We focused so much on removing the pain and the legacy features that we left aside the value-adding part of the process. We didn’t spend enough time understanding the purpose and the importance of the legacy and historic features. We didn’t delve into the user segments that were still using these (painful) features to better understand their underlying needs. Instead of building upon the historic features (while removing some legacy) we only subtracted value. I learned the hard way the difference between two key concepts :

1. The legacy: parts of the product that need to be improved to better meet new customer needs and eliminate friction points.
2. The heritage: the core of the product, that needs to be kept because it brings value to customers.

Iterating on the approach to make it better

So there we were, with a useless but brand-new dashboard in our hands after weeks of research and design. We had to take a step back, and we decided to loop back to the first step of our research. We went back to our customers, asking for more interview time. While showcasing the old and the new dashboards, they pointed out the key components missing in the rebranding. Although some of these components were criticized, we took the time to understand why they were crucial and how we could iterate on them instead of simply removing them. They also helped us frame which part of the new dashboard brought extra value, and how we could melt the best of the two versions.

Before making any changes, we wanted to ensure that this time, we comprehended the purpose and importance of each one of the legacy and historic features we had planned to remove. in addition to interviewing (again) our users, we backed our analysis with data to ensure our sample groups included the subsets of users that still actively used the legacy features. This allowed us to pinpoint which features needed to stay at the dashboard level (for all or some users) and which could be repurposed somewhere else.

Although it took extra days, we landed on a new version that was less revolutionary but packed with way more value than before.

Incremental Changes and Rollbacks

The end? Well, not quite. After the dashboard successfully underwent customer reviews and feedback, we had an arduous debate about the release process. Due to the initial backlash, we decided to opt for a phased approach to release this new dashboard. Instead of removing all the legacy and historic features in one go, we wanted to have more control over the process to identify and address issues at each step. It seemed necessary to have the ability to roll back after each incremental change, although it can be challenging for the operation teams to guide customers through several release phases. We informed our users well in advance about the upcoming modifications, and we clearly explained the rationale behind removing specific features and provide alternatives or workarounds where possible. This was not the overnight transformation that the marketing team had hoped to announce on social media. But it was a smooth and gradual change that significantly impacted our customers. They became our best advocates online!

It took me a significant amount of time (and the Build To Sell training class) to articulate what I learned that day: innovation can backfire and kill innovation if approached too bluntly. I’m now approaching major changes with more humility. Assuming that the previous chief engineers developed the product that way for a good reason, to address a user need. Therefore, when I am tasked with a complete redesign or revamp, I make sure to spend extra time understanding what already exists, what is historical, and what is legacy before jumping ahead. I ensure that I bring a lot more value than I destroy, each step of the way. By keeping these points in mind, we can achieve true innovation and bring significant value to the market, while minimizing the risks to our customers and our business.