OBJECTION 2: ALL OF THE LEGACY FEATURES MUST STAY
Have you ever had an executive on a project who has “pet features” or encountered a product with legacy features that “absolutely must stay in”? This can be a difficult situation . Legacy features have a bad habit of preventing newer (and often superior) approaches from being implemented . More often, they make for a cluttered user interface or product usage flow. On the other hand, there are a few tricks available for making legacy features easier to deal with
Often what you really need to do is show someone the product is wrong without forcing them to take responsibility for the decision—some outside, objective force needs to do the telling . The first thing to determine is whether the market is actually using all those elegant features; product trials, user testing, and statistical analysis can help here . You may discover that some features are useful and others are not, and you’ll have the data to back up your opinions . Some features might be used by a small number of people but be crucial to them . In this case, it may be possible to demote the legacy features in the user interface if they’re not as important for everyday use
Another way to solve this problem is to create a “light” version of the product to help users get into it without overwhelming them . Adobe used this idea to great effect, releasing a cheaper version of its full Photoshop product called Photoshop Elements . It worked well enough to introduce people to the basic concepts of photo editing and some of Photoshop’s tools without overwhelming them This allowed for a new generation and section of the market to pick up Photoshop and integrate it into their workflow, more than doubling Adobe’s addressable market in just a few years
At the last company I worked at, a single stakeholder had complete control over one page of the website . He loaded it with as many features as he could . Then we launched the site with our design and included his single feature-laden page in the launch . We ran statistics to see if anyone was using the page, and when we found that no one was visiting it, we were able to present a data-backed argument to remove the page (and eventually to release a pared-down, redesigned version in line with the rest of the site).