Customers Don’t Want More Features
My job involves managing software products. That means working to understand what the market needs, prioritizing what goes into the next release, and getting buyers and sellers to understand how (and if) the product solves their problems. Given the amount of discussion around Traktor 2.5 I thought people might find this short article (not written by me) of interest. The article is written with the product managers, designers and developers as the target audience.
I have also been thinking about writing an article on product development. It won’t be Traktor specific but it might help people on the outside (a.k.a the customers) get an idea of what a software company has to consider when setting out roadmaps and releasing products. Let me know if that’s something you guys would be interested in reading about.
Anyway, here’s the link to the article and a paste of the bare text.
There is a common myth about product development: the more features we put into a product, the more customers will like it. Product-development teams seem to believe that adding features creates value for customers and subtracting them destroys it. This attitude explains why products are so complicated: Remote controls seem impossible to use, computers take hours to set up, cars have so many switches and knobs that they resemble airplane cockpits, and even the humble toaster now comes with a manual and LCD displays.
Companies that challenge the belief that more is better create products that are elegant in their simplicity. Bang & Olufsen, the Danish manufacturer of audio products, televisions, and telephones, understands that customers don’t necessarily want to fiddle with the equalizer, balance, and other controls to find the optimum combination of settings for listening to music. Its high-end speakers automatically make the adjustments needed to reproduce a song with as much fidelity to the original as possible. All that’s left for users to select is the volume.
Getting companies to buy into and implement the principle that less can be more is hard because it requires extra effort in two areas of product development:
1. Defining the problem. Articulating the problem that developers will try to solve is the most underrated part of the innovation process. Too many companies devote far too little time to it. But this phase is important because it’s where teams develop a clear understanding of what their goals are and generate hypotheses that can be tested and refined through experiments. The quality of a problem statement makes all the difference in a team’s ability to focus on the few features that really matter.
When Walt Disney was planning Disneyland, he didn’t rush to add more features (rides, kinds of food, amount of parking) than other amusement parks had. Rather, he began by asking a much larger question: How could Disneyland provide visitors with a magical customer experience? Surely, the answer didn’t come overnight; it required painstakingly detailed research, constant experimentation, and deep insights into what “magical” meant to Disney and its customers. IDEO and other companies have dedicated phases in which they completely immerse themselves in the context in which the envisioned product or service will be used. Their developers read everything of interest about the markets, observe and interview future users, research offerings that will compete with the new product, and synthesize everything that they have learned into pictures, models, and diagrams. The result is deep insights into customers that are tested, improved, or abandoned throughout the iterative development process.
2. Determining what to hide or omit. Teams are often tempted to show off by producing brilliant technical solutions that amaze their peers and management. But often customers would prefer a product that just works effortlessly. From a customer’s point of view, the best solutions solve a problem in the simplest way and hide the work that developers are so proud of.
One company that has understood this is Apple. It is known for many things—innovative products, stylish designs, and savvy marketing—but perhaps its greatest strength is its ability to get to the heart of a problem. (See “The Real Leadership Lessons of Steve Jobs,” by Walter Isaacson, in our April issue.) As the late Steve Jobs once explained, “When you start looking at a problem and it seems really simple, you don’t really understand the complexity of the problem. And your solutions are way too oversimplified. Then you get into the problem, and you see it’s really complicated. And you come up with all these convoluted solutions…That’s where most people stop.” Not Apple. It keeps on plugging away. “The really great person will keep on going,” said Jobs, “and find…the key underlying principle of the problem and come up with a beautiful, elegant solution that works.”
Determining which features to omit is just as important as—and perhaps more important than—figuring out which ones to include. Unfortunately, many companies, in an effort to be innovative, throw in every possible bell and whistle without fully considering important factors such as the value to customers and ease of use. When such companies do omit some planned functionality, it’s typically because they need to cut costs or have fallen behind schedule or because the team has failed in some other way.
Instead, managers should focus on figuring out whether the deletion of any proposed feature might improve a particular product and allow the team to concentrate on things that truly heighten the overall customer experience. This can be determined by treating each alleged requirement as a hypothesis and testing it in small, quick experiments with prospective customers.
Development teams often assume that their products are done when no more features can be added. Perhaps their logic should be the reverse: Products get closer to perfection when no more features can be eliminated. As Leonardo da Vinci once said, “Simplicity is the ultimate sophistication.”
