As you build a product, you will inevitably get requests for new functionality from everyone who uses the product, whether they are open source users, enterprise customers or design partners.
Feedback is obviously good — but there is also a very real risk that the product will end up getting pulled in too many different directions, ultimately leading to a product that tries to do everything and doesn’t do anything particularly well. Even worse, having too many features in a product can make the product frustrating to use.
Ending up with a product that does too much is often called “feature bloat” or “feature creep.” For the purposes of this article, feature bloat is when a product has too many features and tries to pack in too much functionality. This causes problems both with useability and maintainability.
“It just makes the product harder to use,” said James Wilson, director of product management at Weaveworks, which makes a GitOps platform.
He gave the example of getting started in the cloud: “You go to any of the cloud providers, and you are bombarded with like 70 different features.” That’s overwhelming, and it’s not an experience you want to replicate for your users.
Feature bloat also makes products harder to maintain and update. “You come up with architectural patterns that are not sustainable for the future,” said Karthik Ranganathan, co-founder and chief technology officer at Yugabyte, a cloud native database company. Because there are more moving parts, each iteration cycle takes longer and the risk that something will break increases.
Why Feature Bloat Happens
For startups that are iterating fast and trying to get to product-market fit, feature bloat can be a huge problem, Wilson said. “They’re iterating quickly, they’re trying all sorts of things. And that can all build up, so even after they have traction there’s still all these lingering things.”
Ecosystems are also rapidly evolving, and it can be hard not to chase the shiny new object that appears every three to six months.
Then there’s the constant push and pull of customers and users. Especially in the beginning, it can be challenging to say no when a potential customer asks for new functionality, implying that with that new functionality they’ll buy your product. It can be just as hard to turn down existing customers, out of fear that they’ll churn if you don’t deliver the new feature.
The Importance of Vision
Ideally, as a founder and as a product leader you’ll be able to proactively avoid feature bloat. The first step is to make sure you have a clear vision and strategy coming from the top, Wilson said.
If you don’t have that vision, he said, “it makes it hard for product managers to find the right features to build and to hone in on the problems they’re trying to solve.”
This does not necessarily mean there’s no room for flexibility, according to Lauren Hanford, vice president of product at Tidelift, a management service for open source applications. There are times when a startup might want to accommodate a request that deviates from the vision — for example, an early-stage startup trying to sign its first major client.
She refers to this as “vision debt,” which isn’t necessarily bad as long as everyone involved understands that vision debt has been incurred and doesn’t let it get out of hand.
Killing Your Darlings
Another way that feature bloat happens is that people, whether it is founders or product managers or engineers, get too attached to an idea and can’t let go even when the market feedback indicates the feature isn’t valuable.
“Sometimes we can fall in love with the problem we are trying to solve,” Wilson said. “You get these blinders on as you’re going down this path, and you have to be careful not to overinvest.”
Getting overly attached to favorite product functionality is part of being human. But it’s also made worse by the fact that even the least popular features will likely have at least some fans among your customer base. And when you do decide to sunset a feature, you’ll have to do so with a lot of tact to make sure you don’t alienate those customers.
Removing a feature is always harder than never adding the feature in the first place, both for technical reasons as well as because of the potential for loss of customer trust.
2 Steps to Avoid Feature Bloat
Ultimately, avoiding feature bloat comes down to brutal prioritization. “Sometimes it is literally about making tough calls to prioritize the most important thing,” Ranganathan said. But there are two ways to guide thinking about what to prioritize.
1. Focus on Outcomes, not Features.
“First and foremost, we want to be able to understand what the customer is telling us they’re not able to do,” Hanford said. Even if multiple customers are coming to a company with requests for a specific feature, it’s important to look past the feature request to the problem that’s motivating it and the outcome those users want.
She gave an example she saw at Tidelift in which a customer asked for a feature that would block builds automatically if a developer violated certain policies. This struck the team as ultimately more disruptive than the customer realized. Instead, they worked on understanding what the customer needed (to absolutely ensure policy compliance) and worked together on a way to achieve those goals in a less disruptive way.
Once you understand why a customer is making a feature request, it’s often possible to find a solution that doesn’t involve adding something to your product. Maybe the functionality already exists and you just need to educate the customer; maybe a very slight tweak to an existing feature will accomplish the same goal.
Either way, understanding the motivations and pain points behind each feature request will help prevent feature bloat.
2. Build for Markets, not Customers.
When a customer makes a request, whether it’s framed as a feature request or as a broader request for an outcome, Ranganathan said it’s important to take a step back and evaluate if the pain the customer is feeling is unique to that customer or something your entire target market is likely to experience.
Out of 10 requests from a customer, he noted, you might find eight that can apply to your entire market and two that are unique to the customer.
As a general rule, don’t build features that will serve one customer’s unique needs. Only build features that are going to provide value to your entire market.
Accept Some Bloat as Inevitable
“Building real products is hard,” Hanford said. There are a lot of competing demands and a lot of complexities. Even long-time product leaders don’t necessarily have the recipe for building perfect, sleek products every time.
But getting as close as possible just means making tough choices, understanding the outcomes your customers want, and making sure you’re not trying to build a product that is all things to all people.
The post Entrepreneurship for Engineers: Avoiding Feature Bloat appeared first on The New Stack.
