Profile picture of Coren Feldman

8 min read

When to say no to a feature

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.

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

Illustrations by {name}

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. 

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.

If the feature being proposed doesn’t match the data you’re seeing–for example, if a popular feature is being removed–you can quantitatively show that it’s a bad decision.

Customer support

The customer support team is the biggest qualitative insight you have into your users. They are directly in contact with them and know very well where their pain points are, and what features they want added.

As UX designers, we usually focus on individual features as they are handed to us, and don’t always have the time to check in with the bugs or feature requests coming in from users. A weekly report from customer support could be incredibly valuable in keeping in touch with your users.

If there’s a feature being built that the users will not appreciate, customer support will likely be the first to clue you in.


If it’s unclear whether a feature is a good fit for your users, you can just ask them directly.

Sending a survey to a small percentage of your users (either in the product or via email) can be a useful way to get input on a very specific issue you’re dealing with.

This is also a good way to gauge user satisfaction, and keep track of how changes you’re making in the product are being perceived by the people who use it.

Research using data analysis

Is this feature a good market fit for your demographic?

We always have to keep our users in mind when creating a roadmap and designing new features. User personas are very effective in creating a consensus about who your users are, and it’s helpful when dealing with disagreements around features, but it alone won’t always do the trick.

If you find that your user personas aren’t enough to change course on a problematic feature, it might be worth supplementing them by conducting interviews, either with actual users or people in the same demographic.

If management is being headstrong about the feature, it might be a hard sell, but seeing real people (or videos of them) voicing their honest opinions about the direction the product might go in could have a significant impact on decision-making. Understanding the consequences of these choices, and hearing how they will change your users’ attitudes towards the product, could help change course before it’s too late.

It’s critical that you use neutral language when you conduct user interviews, and that you don’t try to lead the interviewees to any one answer. People are easily influenced by the way questions are worded or by the answer they feel the interviewer is looking for.

Following best practices will make the results more conclusive and lower the likelihood of anyone questioning the results. Plus, you need to be open to being wrong about your opinion, too.

A team of coworkers talking

Is this the best version of your feature?

How much time will this feature take to develop?

A feature doesn’t have to be outright bad in order for it to be the wrong approach. Sometimes, we can fall in love with a specific idea at the design phase, only to realize that is hard to implement and would double the development time.

Sometimes, we approach the problem from an angle that’s more resource-intensive.

If implementation is the issue, the flag was likely raised by developers. As a UX designer, you should therefore support their efforts to find a better version of the feature.

Can we implement this feature with low development time?

Implementation can often be made easier by using third-party libraries and native operating system elements. This usually requires some flexibility on the product end, as these elements may not cover all of the functionality that was originally outlined, or have the exact desired UI.

Usually, being able to implement 80% of the feature in less time is a pretty good win, that can be iterated on and tweaked later.

Is there a more user-friendly version of this feature?

You can achieve a goal in more than one way, and it’s worth considering all options when a problematic feature comes up.

When dealing with growth hacking, the idea that seems like it will raise the metric in question the most, will often win out over more conservative and user-friendly options. However, putting the company needs ahead of the users’, may obscure a clearer and more user-friendly path to your goal.

For example, a platform based on user-uploaded content, might try adding big “upload your first post” buttons in an intrusive way, showing persistent reminder bars across different pages, or blocking off parts of the platform until the user has created a post.

Surveys and in-person user interviews might show that many “lurkers” on your platform would actually create content, if only they could make their feed private. This solution can seamlessly address both user and company needs, deeming prompts for public posts as ineffective and annoying.