Features should be forbidden

At my company, we have a design philosophy—actually, it’s our experience methodology—called Designing for Happiness.

Designing for Happiness has many maxims, but one of the most powerful is that features should be forbidden. It sounds simple enough, and is probably something you and your consumer-focused colleagues believe in, too. However, I’d venture to guess no one reading this is immune to feature fatigue.

There are any number of reasons that product owners skew toward feature overkill rather than feature minimalism, even when it comes to building an MVP. Products are built by businesses after all, and most businesses tend to try appeasing as many internal stakeholders as possible when building products. Additionally, for those companies who do strive to maintain a high degree of communication with your product’s customers, it can be very difficult to activate the consumer’s genius and get them to think outside the realm of feature creap.

A great HBR article from 2006 describes the trend toward feature fatigue well:

Even marketers, who are trained and paid to understand the majority of consumers, are led to believe that more is better by economic theory and standard market-research techniques — both of which use models that predict that increasing the number of positively valued features makes products more appealing.

The authors go on to discuss waves of research that illustrate consumers say they want all the bells and whistles, but when it comes down to actually using products, they’re more likely to stick with just a few of the features that actually give them value.

At this point, you might think it’s about time to start making feature trade-offs, and on the one hand you’d be right. It’s human nature to want to do all the things. On the other hand, if all you do is focus on features, you run the risk of becoming too siloed and forgetting about the user’s needs. It’s in the middle of this dilemma that product owners need to activate what Roger Martin calls integrative thinking.

If you’re stuck with a budget and the features have crept well beyond the limit, you don’t have to fall into the trap of making an either/or decision. Instead, take a step back from the backlog and re-ask yourself the important question that led to the product in the first place: what super harry problem is the user faced with, and how are we going to help them best solve it?

Remember, when your product finally makes it into the hands of its users, those people really won’t care about all the fancy features. All they care about is that it solves the problem it promised to solve. It’s easy to venture too far into the weeds when a feature backlog gets prioritized. Reminding yourself that you exist to solve problems, not create features, will not only make it easier to trim the fat from your products, but you’ll also discover ways certain pieces of the puzzle can work together in ways you might not have originally considered.

Show your support

Clapping shows how much you appreciated Billy Collins’s story.