Please help us continue to provide you with free, quality journalism by turning off your ad blocker on our site.

Thank you for signing in.

If this is your first time registering, please check your inbox for more information about the benefits of your Forbes account and what you can do next!

I agree to receive occasional updates and announcements about Forbes products and services. You may opt out at any time.

I'd like to receive the Forbes Daily Dozen newsletter to get the top 12 headlines every morning.

Forbes takes privacy seriously and is committed to transparency. We will never share your email address with third parties without your permission. By signing in, you are indicating that you accept our Terms of Service and Privacy Statement.

Users want more features. But thinking about software in terms of features may jeopardize the product entirely in the long run. While adding features may improve the customer experience, feature-based thinking can lead to a hollowed-out product with no true creative north. Here's why:

1. Psychological Bias Can Make Features More Attractive Than Back-End Value

We love shiny things like gadgets, trinkets, and anything we can show that has a clear, tangible value. Software features are exactly those shiny objects that everybody loves to see.

People need palpable things that prescribe value to something, and software features are just that in the development world.

The problem is that feature-based thinking can be shallow and near-sighted and can ultimately detract value from the software. That's not to say that we should forget all about features, but they should be kept in careful check and considered against the overall software vision.

2. Users Are Crying For The Features

Feature requests come in from all over the place, including from investors, employees, clients, and users. Everyone has something to say about the software: “It’s great, but …” And the temptation on the product side is to keep people happy by adding those features.

Features are an incredible way of superficially demonstrating how much a product is evolving. These are things that people can see and actually grasp, as opposed to database architecture, security or other imperceptible back-end features.

When they're watching a demo or comparing products, for instance, people will typically line up features side by side and assess them to see which product will add more value.

3. We Need To Deliver Results Now

The challenge is that in a world driven by results and the subsequent fear of not achieving them, feature-driven development will often steamroll over architectural design. The end result is that you end up allowing feature-based thinking to dictate development rather than carefully assessing features and understanding them in the context of the grand software design.

So this is a case of short-term, immediate thinking trampling over long-term vision -- no news there. It’s where many people stand with the current investor-corporate paradigm: We often sell illusions of value as opposed to being genuinely interested in creating value. The focus is on product perception, raising capital and exiting as opposed to remaining genuinely and solely on the product.

4. We're In A Feature Weapons Race

Because users are inclined to evaluate a product and make buying decisions based on features, we run the risk of entering into a feature race against our competitors. Rather than focusing on the overall product integrity, we may feel we need to deliver the features in order to remain competitive. A better product with fewer features can require a lot more sales effort in order to establish credibility when prospects are comparing it to a product with more features. That is why it’s easy for product teams to engage in this race without really trying to understand the "whys" behind those features.

5. We Treat The Symptom, Not The Disease

Features are to symptoms as the software architecture is to the disease. It’s relatively easy to develop features to work around overall architectural limitations as opposed to addressing the limitations themselves.

Just like we have an inclination to address the symptoms as opposed to truly understanding the disease, we also have a propensity for addressing the symptoms as opposed to reassessing the architecture. It’s challenging to change deeply ingrained habits such as eating, drinking water, sleeping and stress. It’s just as challenging to refactor or overhaul the back end of a living platform. It’s comparatively easy to pop a pill and to release a feature. This doesn't mean that we are truly addressing what matters, though.

What To Do

The first step is awareness. The understanding alone that we have all of these biases and triggers in place that cause us to focus on features will open the road to overcoming this propensity.

Rather than focusing on the feature, we need to take a step back and look at the bigger business case. This will allow us to understand feature requests in a much wider context so that we can take a critical perspective and question the relevance of each request. To do this, we can follow a few basic but helpful guidelines:

• Forget the upside of adding the specific feature for a second. Whether it's landing a big deal, keeping a current customer happy or solving something that is troubling users, put that aside.

• Now that we've forgotten the upside, let's look critically at the feature request and think about whether it's possible to address it systemically rather than symptomatically. As a simple example, if a client asks to log in through magic links as opposed to emails and passwords, we could see that as low-hanging fruit and something that's easy to implement. However, there are bigger questions: How does this fit within our security vision and policy, and what benefits will this feature bring? In this example, as the problem points to log-in simplicity, we could better address it through a cloud-based identity and access management provider such as OneLogin or Okta as opposed to the magic link. It's not that the magic link won't add value but that the problem may be more definitively solved by a deeper, more all-encompassing fix.

This is just a mundane example, but the framework applies to more complex situations as well. The main goal is to let go of the immediate reward of adding the feature and think systemically about the feature at the same time.

As we reaffirm our commitment to the ultimate product vision, we will naturally make hard choices and prioritize the long game as opposed to the quick fix. The challenge is that we need to develop strong mental muscles that allow us to avoid caving into the pressure and temptations of introducing more and more features as we remain true to the product’s deepest purpose.