When to say no to a feature

Profile picture of Coren Feldman




Illustrations by {name}

Sometimes, we need to stand our ground and not execute the tasks we’re given. Instead, it’s up to us to offer alternative routes.

8 min read

A white flag with the word 'No' on it.

Stay informed on all things design.

Thanks for submitting!

Shaping Design is created on Editor X, the advanced web design platform for professionals. Create your next project on Editor X. 

Get our latest stories delivered straight to your inbox →

Managing a product isn’t easy. There are always people higher up to answer to, whether those are managers or investors, who will push for certain features or growth metrics. It’s hardly an overstatement to say that a company’s fate is dependent on gaining more users or making more sales.

It can be difficult to weigh the product and user needs against these powers, or even to stand up to them when you feel it is necessary. Yet however powerful these forces may be, it's important to remember that they are approaching the company and the product from one specific angle. All the while, users and employees have a different perspective.

So what are the things you need to consider when deciding whether to push back on a feature request coming from the top? How do you show that it’s not the best way to go about accomplishing a goal, or that moving forward with it will hurt your users?

These are the things you should be considering:

What is the goal of your feature?

Identify what the feature is meant to achieve

Features are all built around goals. With any feature, there should be something that it is trying to achieve, whether that’s increasing click-throughs on a certain action, improving retention, or boosting engagement. Pinning down the motivation behind the feature will help get everyone on the same page, so that you can evaluate it properly and, if necessary, brainstorm other options.

A feature should never be worked on without stating a clear goal. If you don’t have a solid understanding of why this feature is necessary, you should ask for one from management.

It’s good to add this to specification documents as well, so developers and QA can understand what makes this feature important.

There’s nothing wrong with having company goals, but, ultimately, features should benefit your users first and your company second.

Is this feature the best way to achieve that goal?

Once everyone is in agreement on the goal of the feature, you can try to analyze the effectiveness of the feature as a means to achieving it. Is this a sustainable solution? How will your users react?

For example, restricting a feature to users who have invited friends can definitely boost the conversions for that action, but, in the long run, more users are likely to get frustrated and leave your product. So, while in the short term it will lead to an increase in invites and user acquisition, in the long term, it will decrease engagement and retention. This is because users will feel that they are being pushed to perform an action that they are not interested in.

Woman sketching a graph

Who is this feature for? Understand your audience

Is this feature coming from business needs or user needs?

New feature requirements will often come down from management based on company needs, and they might not want to admit that up front. There’s nothing wrong with having company goals, but, ultimately, features should benefit your users first and your company second. If the feature was designed with only business objectives in mind, it may not be a good fit for your users.

But there’s no reason features can’t answer both user and business needs. Often, the reason management wants a certain metric boosted can tie in with benefiting your users as well.

For example, say there’s a platform driven by user content. An obvious company goal here would be to get users to create their own posts. This same metric could also be beneficial to users, if this hypothetical platform could create engagement and positive feedback from their submissions. Business and user needs are not inherently at odds; we just have to figure out how to tie them together.

What do your users want?

There are a lot of ways to get user feedback. Ideally, these should all be in place in your company and help prioritize your roadmap.

At times, when management is pushing for a feature that may not be right for your users, these are the places you should check to validate your theory:


Prioritizing analytics early on in the product’s life will pay off quickly and consistently. Hearing from users may give you valuable snapshots into how your product is being used - but there’s usually more to it.

Analytics can show the larger picture and broader trends. Sometimes a few users will say that they don’t like a feature, while engagement data will show that most users don’t feel the same way. Users mostly reach out when they’re unhappy, and that’s important, but you also need to know when and where things are going well.