Want to avoid overwhelming and possibly alienating users with too many features? Here’s an in-depth look at how product managers can avoid feature overload.
|In this Article:|
Last week I stumbled upon an article by Rian van der Merwe about avoiding building products that fail. His entire post is extremely well-written, but one section in particular caught my eye and inspired this article; van der Merwe made the observation that that product managers sometimes erroneously believe product features and customer needs are one in the same, leading them to pack products with features customers don’t actually need.
“Have you ever used more than one or two of the preset cycles on your washing machine? And how many different ways do you need to toast your bread? The evolution of household appliances is a perfect example of what happens when features are equated with value,” wrote van der Merwe, adding “more isn’t necessarily better.”
He’s right, in most cases, less is more and there is actually great value in simplicity. Alas, it is so easy to get carried away without realizing it. After all, features are fun. Engineers love to build them, sales loves showing them off, marketing loves having a new selling point, and product managers love improving their product’s capabilities. Our enamourment with adding product features is why we have new vehicles rolling off lots equipped with bells and whistles like heated steering wheels, pulsating speaker lights, and other extras that most drivers never realized they needed.
When those extra goodies become too much, both our products and customers suffer from feature fatigue, a term coined in a “2009 study published in the Journal of Marketing Research. The first half of the study looked at the effect of features on buyer behavior and found shoppers almost always pick the product with the most features, and when given the chance to customize a product’s features, they pile as many on as they can–buyers love lots of features.The second half of the study looked at customer satisfaction and found that customers greatly overestimated their ability to learn to use the extra features, causing frustration and degrading their overall user experience–users don’t love lots of features. Customers don’t always know what they want, and as the study concluded, “too many features can encourage initial purchase but damage satisfaction and reduce repurchase probabilities, leading to lower customer lifetime values,” which means it’s product’s responsibility to understand and serve customer needs first and foremost. So what’s a PM to do? It’s all about striking the right balance between features and functionality and maintaining a laser-focus on your product vision. [cta id=’2003907′]
As van der Merwe discussed in How to Avoid Building Products that Fail, household appliances often suffer from feature bloat; coffee makers, vacuum cleaners, blenders, and even simple wine bottle openers come equipped with extra controls and features—instruction manuals with page counts that put vehicle owner manuals to shame. But it’s not just household products that experience feature bloat, consumer electronics like cell phones and digital cameras often toe the fine line between “just enough,” and “too many” features, social media sites get carried away with features, and simple word processing programs get more and more complicated with every update.
A Quora thread I recently read cited ICQ as the most notable example of a product decline by feature bloat. If you don’t remember ICQ, it’s an instant messaging client initially launched in 1996 that quickly became one of the most widely used messaging clients out there, more popular than even AOL’s AIM. ICQ’s popularity was fairly short lived, and while there’s no scientific evidence that the product’s early decline was due to feature overload, it’s often said to be a culprit. After ICQ launched, it began dropping new features on the regular, which was fantastic…until it suddenly wasn’t.
“It got too cluttered and stopped being developed. In 1996 it seemed like there was a new feature every few days. At some point after 2001 it stopped seeing radical improvements.
I think they were scared of taking stuff out which people liked, too, which made it hard to improve,” wrote Robert Scoble in a 2007 blog post about the fall of ICQ.
In 2005 or so, ICQ jumped the shark. The company launched a stripped down version of itself called ICQ Lite, a last ditch effort to make a comeback. It wasn’t enough, ICQ had already overdosed on features, alienating its long-time users and warding off new ones.
But where exactly did ICQ go wrong? At what point did they cross the threshold and step out of the “innovative, useful, usable product” category and into the “crowded, confusing, intimidating product” category, and why didn’t they do something about it? Perhaps the ICQ product team didn’t fully understand their users’ needs, perhaps these new features were being made without any customer data backing these decisions up, perhaps perhaps perhaps…We can speculate all day long about where ICQ went wrong, but rather than doing that we should focus on keeping our own products in shape.
“Make everything as simple as possible, but not simpler.”
– Albert Einstein
Do you remember the first time you drove your first car? Last year my mother sent me a photo of a very special moment: my baby brother had just purchased his first set of wheels and was about to drive off the lot in the shiny new 2014 Ford Focus he’d had his eye on for months. I was expecting to see my brother grinning from ear to ear cheesily in excitement as he basked in his newfound independence. Instead, I got this:
“Not so fast buddy, you’ve gotta read the manual first.”
He does not look like a happy camper, in fact, he looks extremely stressed out. It turns out my brother’s dashboard was so overloaded with features that he apparently needed a tour before he could even drive off the lot–and he’s one of the most tech-savvy people I know so this was quite a shock.
Then I found out why he needed a tour, his car’s dashboard resembled that of a spaceship:
My brother’s car, and many other cars on the market right now are so bloated with features that simply driving them has a learning curve–and that’s a product problem. Why? The basic, primary function of a vehicle; transportation from point A to point B, is now slightly harder to perform because there are too many features in the way. That, my friends, is one indicator that a product has too many features.
Features should not be your number one priority. Look at your Minimum Viable Product’s essential function, prioritize making your product to that one thing extremely well, with or without the bells and whistles. Features should enhance that function, that function should not rely on features.
Marketing researchers Rust, Thompson, and Hamilton nailed it on the head in Defeating Feature Fatigue, “Design products that do one thing very well. Perhaps the worst outcome of feature creep is the one captured in a New Yorker cartoon that shows a man arriving in a store with a simple question: “Do you have any phones that make phone calls?” Too often, in their eagerness to layer on additional functionality, developers lose sight of the product’s basic function – the one thing it must do extremely well.”
Customers don’t always know what’s best for them. As the feature fatigue study I cited earlier in this article found, customers want it all, until they have it all and realize they must learn to manage it all. A Harvard Business Review article on the same study noted that customers know very little about their needs prior to making a purchase because “the experience of using a product changes the equation underlying consumers’ preferences.”
So if customers are so bad at understanding their own needs and preferences in a product, why listen to them at all? While customers may not be able to accurately pinpoint the specific solution they need, their feedback can provide insight into the underlying problem they’re experiencing and indicate unmet needs. The key word here is “needs,” don’t build features that don’t solve problems and serve needs. Customers may say they want a flying skateboard, but they don’t necessarily need one–a good Product Manager will dig to the root of such a request and determine why. Perhaps your customers want a flying skateboard because they want to be able to tackle rocky terrain; they don’t need a skateboard that flies, they need larger wheels with more traction.
It’s critical to understand that what your customers want is not always what they need, and where there’s no underlying problem, there’s no underlying need. Focus first on customer needs, and second on wants, chances are when you’ve served your customers’ needs, they will no longer have so many wants.
While managing customer feedback to understand the root of the issues they’d like to solve is somewhat of an art, applying data to that feedback to make product decisions is a science.
When you have customer and usage data at your fingertips, or at least readily available, you essentially have access to the most powerful Product Management tool out there–so put it to use. Beyond looking at the feedback your customers are providing, look at the weight of that feedback–it’s not necessarily about the customer feedback with the highest number of votes from customers, it’s about the feedback that’s coming from the your most valuable customers, the customers who spend the most money on your product. How many of these high-paying customers are requesting a certain feature? How valuable are these customers? Don’t build something solely on qualitative data, or as an online experimentation team at Microsoft found, you may never see a return, “Every feature built by a software team is built because someone believes it will have value, yet many of the benefits fail to materialize.”
I’ve written before about the important role of data in a Product Manager’s process and am not alone in my belief that data can reduce risk when making any decision. Kris Gale, VP Engineering at Yammer wrote recently “On the product side, your best tool for eliminating complexity cost is data,” suggesting developers “methodically test the impact of each change” and eliminate features that aren’t being used.
This is exactly what product managers should be doing. The root of the issue with feature fatigue is that customers are easily overwhelmed by clutter and perceived complexity, so part of preventing feature fatigue is preventing clutter. In other words, don’t build crap your customers won’t actually use–and if you accidentally do, get rid of it.
Customers, executives, sales, developers–each of these groups will likely suggest you implement a feature at some point or another. If you listened to and acted on every suggestion you received, your product would get very feature heavy very quickly. Stay focused on your product vision, and your product’s purpose–focus on the basic need that your product seeks to serve and the long-term goal of your product.
We’ve written before about saying “no” to customer feedback, something every Product Manager should get comfortable doing. It takes an assertive Product Manager to keep a product on track, “being assertive during the design process brings value in the long run. It keeps your product clean, easy-to-use and worth recommending. The problem is, people are more comfortable with making short-term decisions. Junk food and cigarettes would not be so popular otherwise. Long-term vision is something that a good product manager must always keep in his mind,” Bartosz Olchówka wrote on his team’s experience redesigning Live Chat, noting that being selective about what feedback to act on is important.
Olchowka advises Product Managers to plan every feature and execute with great care, “Don’t compete in the features rat race. This would move your product development efforts in the wrong direction.” This kind of care and focus on the big picture means saying “no,” often. A single user’s feature request shouldn’t be the reason a feature is built, and a feature suggestion coming from sales or an executive shouldn’t be implemented merely due to its source.
“Perfection is reached not when there is nothing left to add, but when there is nothing left to take away.” – Antoine de Saint-Exupéry
Sometimes clutter happens despite our best efforts to curb it. Sometimes a little feature Spring cleaning needs to happen–that’s okay–and you don’t have to build a “Lite” version of your product like ICQ did. Get rid of dead feature weight as often as you can, if customers aren’t using a feature, drop it.
If new customers are taking one look at your product and leaving, that may be a good indicator some clean up is in order, according to Mind the Product’s Janna Bastow, “Your users probably have very little time to sift through piles of options or user guides to figure out how to accomplish what they signed up for in the first place. If they can’t figure this out quickly and easily, they’ll walk away.”
Knowing which features to keep and which ones to toss is critical, certainly not something to attempt without first considering customer feedback, usage data and other resources. This MTP article provides some more in-depth advice on killing features, but at a basic level suggests Product Managers “focus on maintaining the features that make your product really shine.”