Remember when Twitter (now X) revamped its verification system?
Turning the blue checkmark into a paid feature was meant to improve trust. But users saw right through it.
Instead of preventing impersonation, it fueled it. The result? A flood of fake accounts, credibility issues, and widespread backlash.
More recently, Instagram’s sudden feed ratio change had users up in arms. Why? Because it wasn’t something they asked for—it was something business wanted. And that’s where things often go wrong.
The best app features aren’t forced onto users; they’re built with them in mind. So, how do you ensure your next launch isn’t met with backlash?
Here’s what our principal product manager suggests.
Three Reasons Users Reject Your New Feature
Besides users not wanting it…
- No clear value: “Cool” isn’t the same as “useful.”
- Bad timing: Features that launch when users don’t need them.
- Overcomplication: Features that disrupt existing workflows.
5 tips to minimize feature rejection
1. Never skip the product discovery stage
With feature rejections, users are usually given unsolicited solutions that don’t correspond to their needs with the app’s existing features.
So, product discovery is essential to identify actual user needs.
Market research, user interviews, and quick prototypes will help you validate the problem the new feature is aiming for and identify the need for a solution straight from the source — the app’s users.
Set objectives and measurable targets by asking yourself the following before you begin market research:
What to question before starting
- What problem is the feature solving?
- Who is the feature targeted for?
- Is this issue painful enough that users would pay for a solution?
- Does this feature align with the current product strategy? (e.g., if the goal is expansion into Indonesia, revamping UI for Mandarin characters isn’t exactly a priority.)
- Is the cost of building this solution acceptable for the company?
2. Involve users in the entire process
Including an app’s users in the development process is a no-brainer.
However, users are often left off the decision-making process due to time constraints or pressure from internal stakeholders and competitors.
So, the team ends up working with internal assumptions when developing the feature. And assuming what users want instead of actually asking them is a guaranteed recipe for disaster.
Instead, product owners should involve them from the start. After all, they are where the feature ends up.
What’s suggested is this:
How to involve your users
- Start with user research
Before writing a single line of code, talk to your users. Conduct user interviews to gather feedback and understand their pain points. Share mockups to see how they react to the concept before committing to development.
- Validate design choices early
Use tools like Maze to test and refine your designs. This helps you catch usability issues early and make data-driven decisions before the feature is built.
- Beta Test with a Small Group
Once your Minimum Viable Product (MVP) is ready, run a beta test with a small test group. Beta testing bridges the gap between theoretical development and real-world application because what users say might not always match their actions in practice. It ensures the product is not only functional but also user-friendly and market-ready.
3. Balance internal requests with user needs— diplomatically
Oftentimes, new feature requests don’t stem from users. Some come from stakeholders, compliance teams, or internal teams with urgent business, changing compliance requirements, or technical needs.
And sometimes, those priorities don’t align with what your users actually want. So, how do you handle this without turning every meeting into a tug-of-war?
Adopt a negotiating approach centered around the end-user.
Find the sweet spot where internal goals and user needs overlap. Try to understand the rationale behind the request.
If a request doesn’t directly improve the user experience, can it be implemented in a way that still adds value?
The goal is to create a win-win scenario—where users stay happy, and the business moves forward.
4. Have a close feedback loop and fast iterations
The sooner you catch a problem, the less painful (and expensive) it is to fix.
That’s why close feedback loops and fast iterations are your best friends.
Make it second nature in the team to quickly and continuously gather, analyze, and act on feedback throughout the development cycle. In simple terms, test early and test often.
Even better, implement the Agile methodology as your safety net.
It ensures that the product evolves in alignment with real user input and minimizes surprises, keeping users on your side.
5. Post-release Actions
If a new feature affects existing usability, instant and clear communication is vital to minimize complaints. Announce the feature upfront and provide documentation like tutorials or an FAQ—never leave them in the dark.
If the feature DOES receive pushback after all the research, be accountable. Acknowledge the issue and provide an alternative while the team addresses it. This is how you show a commitment to resolving issues with your users.
But if the feature does well, time to plan for the future. Review the feature release process with your team to identify what worked well and could be improved.
Don’t forget to review user feedback and use that as the app’s future roadmap.
To kill or keep a poorly received feature?
How do you decide?
Use the metrics and target set in the beginning as a point of reference. They should guide your team in making design and technical decisions to achieve the goals.
Upon release, the metrics should be tracked regularly. If the target is unmet, the team should always try to differentiate between “the feature doesn’t work as expected” and “the feature is not needed.”
If it’s the latter, don’t be afraid to pull the plug.
Approach it like scientists.
Product development is a series of experiments: test, learn, adapt, repeat. So, as the product owner, you have to approach it in a scientific approach.
The best products aren’t perfect from day one—they evolve. Hypotheses need testing, and failure is just another data point.
A feature failing isn’t the issue; ignoring what it teaches you is. The lesson is to approach every launch with curiosity, measure the results, and tweak accordingly.
And if you need an extra set of hands who build great apps and help you make the right product and business decisions, don’t shy away from help.