Feature creep. Featuritis. Feature bloat. Creeping featurism. Bloatware. These all refer to the same thing, and it isn’t good.
Feature creep (and its synonyms) is the “tendency to constantly add features which inevitably leads to complex products that are confusing and hard to use.”
New York Times columnist David Pogue was one of the first people to publicly call attention to feature creep when he “famously demonstrated to a rapt audience at the 2006 TED conference what happened when he opened every possible toolbar in his Microsoft Word program—there was no room on the screen for the primary value-adding function of composing a simple text document,” explains Matthew May.
We get it. Feature creep isn’t a malevolent act against your customers. But by shoving numerous features into your product you risk turning your product into something that does many things marginally well rather than accomplishing a few core tasks exceptionally well.
People can get over not having a feature if your product is solid, but cannot get over having buggy or poorly thought out features. Focus on quality over quantity. As you grow, you can add well thought out features that are easy to use, but don’t jump the gun just to satisfy a customer or two.
While determining which features will be developed and saying “no” to avoid feature creep falls primarily to product managers it is important for everyone involved with a product (from development to marketing) to understand feature creep and its consequences.
In today’s blog you’ll learn:
- Why feature creep is bad
- How feature creep happens
- When to say “yes” and when to say “no” to new features
Why feature creep is bad
More issues, more money
Every feature added means more potential bugs and utilizing more of your company’s resources. Resources are not just the front-end development time, but also promotion and lifelong support (via development and customer support staff). “Every change you implement requires building, testing, and iterating…and then, launching, promoting and supporting it,” explains SaaS copywriter Pawel Grabowski. All those resources and additional support increase costs, and expenses are often substantially more than your initial estimates.
Ever heard of the saying “having too much of a good thing?” Feature fatigue is a phrase coined in a 2009 study published in the Journal of Marketing Research and it occurs when your overabundance of features becomes “too much of a good thing” for your customers. “Too many features can encourage initial purchase but damage satisfaction and reduce repurchase probabilities, leading to lower customer lifetime values,” according to Grabowski.
Feature-heavy products often include complicated user interfaces or user experiences, neither of which are very user-friendly. Another lesson from feature fatigue is that often customers don’t actually enjoy having tons of features.
If we all agree feature creep is bad, why does it still continue to happen?
Common reasons feature creep happens
While not an all-inclusive list, below are some of the common reasons features are requested and reasons requests become feature creep.
- A belief that this feature is “the one.” a.k.a. The feature linchpin that launches your product into unicorn status.
- A (big) potential customer requests it
- Your competitors have features that your product doesn’t provide
- A belief that if you don’t build the feature someone else will and you’ll be at a competitive disadvantage (this is similar to the point above)
- Your boss or a coworker wants the feature
- You imagine the feature being helpful in the future
- You want to incorporate emerging trends such as building a social feature to capitalize on the current social media craze
- Development time is quick
- It would be great to give customers the option to utilize this feature
- You haven’t released any features in a while and you don’t have any upcoming releases
- “Lots of” customers are requesting it. What does “lots of” really mean?
Now that we’ve looked at the common reasons feature creep can happen, let’s look at the most important aspect of avoiding feature creep: saying no.
When to say “yes” and when to say “no” to new features
When analyzing feature requests, use the points below to help determine when you should say “no” to new features.
Focus on the problem your product solves for users
Always go back to your original product vision and purpose. “Product vision guides everyone involved in developing a product toward making it a success. It’s the goal you strive for, the reason why you created your product. So every time you face a new idea, run it by your product vision,” says Grabowski.
“It’s all about striking the right balance between features and functionality and maintaining a laser-focus on your product vision,” advises Heather McCloskey, Inbound & Content Marketing Manager at UserVoice.
Focus on project priorities
This is similar to the information above, but on a more macro level. “Set an overarching product goal…keep your high-level goal at the forefront, and make sure each feature supports that goal,” suggests Ellen Chisa, VP of Product at Lola Travel.
Consider the time/resources involved
“Sure, it might take an hour to build a feature in an ideal test case. But when you try and integrate that into your existing platform, work on the UI & UX, get your designers involved, write some tests, and eventually push the code, you’ll probably have spent the whole day. Is the feature worth it? Maybe. But you need to be realistic about how long it’ll take,” points out Intercom co-founder Des Traynor.
And quite possibly our favorite quote regarding resources and feature development came from Chisa:
“A universal law of product management: There are always more feature requests than available development time.”
Look at the data
You can look at usage data to determine which features are being used and those getting the most usage.
What features are increasing user engagement?
You do need to also be cautious when looking at data to determine the validity of a new feature. Traynor explains why:
“Even if the data is solid, and the increase in engagement is good, you still have to question whether it fits within the purview of the product. Add Tetris to your product and you’ll probably see a boost in engagement, but does that mean your product is better?”
Listen to customer feedback
As we discussed in the previous section, it is important to look at why customers are making the requests that they are. Dig deeper into the underlying issues. “Sometimes feature requests are actually usability issues in disguise,” offers InVision’s Jennifer Aldrich.
It is also critical to clearly distinguish between customers’ needs and wants.
“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,” says McCloskey.
Determine ease of use
This point ties in to the one above. Be honest about how user-friendly the feature will be. How much effort will it take customers to use the new feature? If it is more effort than the reward, it isn’t likely to be utilized — even if it fills a need.
Examine impact to the existing workflow
“Adding a whole new workflow to your product should be a rare occurrence. The majority of your time should be invested in improving, complementing, or innovating upon existing ones, and for any given project you should know which of these you are doing,” explains Traynor.
Look at how your overall business will be affected
A new feature is especially tempting if the impact is likely to be increased revenue. But, be careful here. The resulting revenue is something that should be considered, but not be the sole determining factor. Some features may increase revenue short-term, but derail the original product vision.
Recognize impact to existing customers
This point often relates back to a potential customer’s request for a new feature. First, a customer shouldn’t take precedent over the overall value of your product. Second, the extra value the requested feature will bring to one customer often takes away value from existing customers. Remember, your current paying customers keep your company afloat.
Short-term outcome vs. long-term value
When looking at common reasons feature creep happens, we discussed the desire to capitalize on a current or emerging trend (such as social media). When weighing a feature request and its value you may want to ask yourself, “will this feature still be valuable in 5 years?”
“A good sign that a feature isn’t well scoped is when it lacks specifics, e.g. ‘Make it work for bigger companies’, or that it’s feature based e.g. ‘reports’, as opposed to job-based e.g. ‘Let sales managers see their team performance’,” explains Traynor. When reviewing a feature request, be honest about its scope to avoid future issues.
For great examples of exactly how to phrase your “no” Intercom has an interactive infographic, “Put an end to feature creep,” that’s worth checking out.
The infographic at the end of this post summarizes the points you should consider when evaluating feature requests and determining if the feature adds value to the original product vision or would be more likely to contribute to feature creep.
Don’t be afraid to kill features
This topic deserves it’s own blog, so we won’t dive too deep into it now. With that said, it’s worth mentioning the importance of killing features that no longer make sense or provide value.
“One of the hardest parts of managing feature creep is tearing out features after you’ve built them and they haven’t worked,” admits entrepreneur Jake Peters.
Groove went through the difficult decision to remove their LiveChat feature and they detail the process in their blog, “Why We Killed One of Our Biggest Features to Grow Our Business.” It’s a fantastic read and one we highly recommend you check out.
Regularly auditing your product’s features and killing those that aren’t providing value is an important aspect of keeping feature creep at bay. The act of killing a feature can be difficult, but remind yourself there is a reason for your decision (and make sure you know that reason).
One of a product manager’s hardest jobs is determining which new features to develop and which requests to pass on. It is never easy to think (or say), “Yes, that is a great idea, but we’re not going to do it.” Saying “no,” especially to a boss or investor, can be difficult but it is necessary for the overall success of your product.
How does your company handle feature requests? Has it allowed you to be successful in avoiding feature creep? Please share your tips and experiences in the comments below.