When to say no to a feature

Profile picture of coren feldman


Illustration by Shai Samana

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.

9 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.

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.

A person using a tablet

When to put your foot down

Is this feature harming your users?

It’s unlikely you’ll be able to make a stand over every feature you don’t like. Make sure that when you do, it’s a hill you’re willing to die on. If you feel very strongly about it and think that the feature is harmful to users, and there are other people who will put their weight behind you, it’s probably worth doing.

Tech is a very large industry that, unlike some others, doesn’t have any ethical guidelines in place. Some lines are obvious legal issues that won’t be crossed, but those aside, no one is regulating a company’s behavior or its effects on users.

Many products have intentionally misleading copy, dialogues, hidden fees, and other UI/UX patterns that are designed to grow their businesses at the expense of users. Many of them will get away with it without significant backlash, but that doesn’t mean it’s the right thing to do.

There are good guidelines out there, such as Mike Monteiro’s A Designer’s Code of Ethics, but, ultimately, it’s up to a company’s employees to implement them. That’s not always going to happen, since pushing back can harm your standing with your employer. At the same time, there’s no one else who can stand up for the users’ best interests before these changes are pushed out.

How to say no to your manager

There is a clear power dynamic in your relationship with your boss that needs to be taken into account when raising a red flag.

You can’t talk to them like you can talk with coworkers. One reason for this is that decision makers tend to defend their own judgment calls, especially when they feel like their authority is being challenged.

Here are some actionable tips to use when talking to your manager about a problematic feature:

Use constructive feedback

Don’t barge into their office accusing them of bad intentions and demand they change their minds. You have to understand what caused them to make the decision they made and empathize with their situation.

Once you’ve put yourself in their shoes, you can calmly make your argument without being antagonistic or hyperbolic. You’re both in the same boat and share the same goals; you just feel differently on how to accomplish them.

Make clear arguments

Going into what might be a significant disagreement, it’s best to compile everything you have on this feature and why you think it’s not the right way to go.

User feedback, surveys, data, personas, development input–all of these things can help make your case, and you want to be armed with them when you walk into that meeting.

Provide alternatives

Don’t move ahead with your pushback unless you have good alternatives that can achieve similar results.

You can have a great argument against a decision, but, unless you come prepared with another solution, you’d most likely just be met with a shrug.

Respect the chain of command

Finally, one of the most important parts of any fight is knowing when you’re beat. You may not always be able to win these arguments.

When it’s made clear to you that a decision is final, your job there is done. You raised a flag and made your claims, but, ultimately, it’s their call. Not relenting after a certain point is counterproductive and could cost you your job.

A team of coworkers and a manager talking


Don’t act reflexively when a feature doesn’t seem right. Talk to your coworkers, gather data, and work cooperatively on finding a solution.

You likely have more power within an organization than you realize. If you wield it responsibly, deliberately, and wisely, you can impact the product in positive ways and distinguish yourself as a trustworthy employee whom management can count on to keep both the company’s and users’ best interests in mind.