10 reasons why you shouldn't build that feature
Every great visionary understands the importance of saying "No!". Steve Jobs famously said "People think focus means saying yes to the thing you've got to focus on. But that's not what it means at all. It means saying no to the hundred other good ideas that there are." While this is a lovely quote, it can be difficult to live by in practice. Feature creep is real my friends.
If you hear yourself or anyone else on your team saying any of the following lines, take a step back and think twice:
1) "It won't take long to build"
This is awful logic. Features should always be built with a long-term value perspective. Quick, unthoughtful and impulsive feature decisions might feel insignificant but they'll interfere with your smooth product experience, confuse users and add unnecessary complexity. Outside of purposeful experimentation, this is a recipe for technical debt.
2) "Loads of users have requested this feature"
This is a common trap product teams fall into. Being reactive to customer feedback and suggestions is important but you shouldn't build everything customers suggest even if you have heard the suggestion lots of times.
In these situations it's important to ask yourself a few important questions:
What problem does this feature request solve for our customers?
What percentage of our customers actually requested this feature?
Do these customers fall into the 20% of customers that generate 80% of revenue?
Does the feature align with our strategic goals?
Is the feature mission-critical for customers or nice to have?
What is the opportunity cost of building this feature?
3) "The executive team want this feature"
There are a whole host of reasons why building features based on internal stakeholder requests can become an issue. The executive team is unlikely to be on the ground speaking with customers every day. Even worse, the highest-paid person (HIPPO) in the room can be the most dangerous to your company. Inform product decisions with user research rather than internal assumptions.
4) "We are going to lose a customer if we don't build this"
Only in very veeeeeery rare cases should one customer be able to command so much agency over your product like this. If you have to jump through hoops for a single customer, it's going to take your attention off the rest of your paying users. If one customer has this much influence over your company, you need to think about diversifying your revenue stream. Losing this customer could bankrupt your business.
Want to discover what you actually should build? Use OpinionX to stack rank people’s priorities so that you can make decisions with real data.
5) "We will build it but make it optional"
This usually means a messy interface with too many confusing choices. If you find yourself adding optional features, it likely means you don't have a strong strategic objective and vision. Besides, the 'Paradox of Choice' says that having many options to choose from (rather than making people happy and ensuring they get what they want) can cause people stress and disempower decision-making.
6) "My cousin/neighbor/wife/friend/dog said we should build it"
This is a simple one. Anecdotes are not data. They shouldn't be used for decision making. You can think of anecdotes as a sample of 1 — not very robust! If an anecdote surfaces something truly interesting, research the idea thoroughly and back it up with quantitative data.
7) "The data says we should build it"
Often product teams do experiments. Experiments are good and can tell you a lot in a short space of time. But there's one issue to be aware of; if you conduct an experiment and people are using the feature, it doesn't always mean you should go ahead and build it.
Ask yourself:
Why did these users engage with the feature?
What would the customer have done if the feature wasn't there?
Did they spend more time on your product because of the feature?
Did they get more genuine value?
Did any other feature suffer as a result?
8) "Our competitors did it so it must be a good idea"
This is a classic point of failure for many companies. Being obsessed with your competitors distracts your attention from customers. Your competitors might be doing an experiment, they may have bad decision-makers or could even have different strategic objectives to you. You should learn from competitors but don't be blindly reactive to their choices.
9) "This could be the feature that changes things"
Enthusiasm is fantastic but it needs to be mixed with a healthy dose of practicality. Speculation about future feature success can get the team excited but you might be overlooking some important factors. Sleep on the idea and conduct in-depth user research, then see if you still feel as enthusiastic.
10) "We have nothing else planned, we might aswell"
The 'keep the engineers busy' mentality has led to many failed product features. If an engineer has idle time there is plenty of high-value tasks they can be doing like fixing bugs, cleaning up test suites, refactoring or even talking to customers. I know what you are thinking, "Engineers, talking to customers? Noooo way." **but only good can come from more of the team having hands-on experience engaging with your end users. It increases empathy for both the customers and the people who usually do the talking with customers.
So how should you make feature decisions?
I recently wrote a blog post titled 4 Prioritization Techniques For Deciding What To Build that walks you through 4 ways that you can make intelligent feature decisions. I recommend starting there.
Subscribe to the OpinionX newsletter for more user research and product management tips: