The Best Research Finding Is the One That Kills a Feature
Research isn't there to tell you you're right. Sometimes the most valuable thing it can say is "don't build this."
- Research
- Strategy
The Fuego Team
11.7.26
Most teams treat user research like a vote of confidence. The study comes back, it says users like the idea, and everyone moves on happy.
But the research that saves the most money usually isn't the kind that says yes. It's the kind that says no. No, users don't have this problem. No, this isn't how they'd use it. No, this won't change what they do.
That's not a failed study. That might be the best result you'll get all year.
Every feature costs more than it looks
A feature isn't a one-time cost. Once it ships, someone has to maintain it, support it, document it and design around it. It adds one more thing for users to learn and one more thing in the way of what they came to do.
Killing an idea before it's built saves all of that. Killing it after launch saves almost none of it, because by then it's in the product, someone's using it and removing it becomes its own project.
Why "no" is so hard to hear
Teams rarely set out to ignore research. The problem is timing and framing.
Research often gets brought in after the roadmap is set, the designs are done and someone has already promised the feature to a customer or a board. At that point, the study isn't really a question. It's a formality, and a "no" feels like a problem to manage instead of a result to act on.
The questions give it away too. "Would you use this?" almost always gets a polite yes. "How do you handle this today?" tells you whether the problem is real.
Make it safe to kill ideas
If you want research to be useful, the team has to be able to act on a no. A few things help:
- Research before commitment. Talk to users while the idea is still cheap to drop, not after it's on the roadmap.
- Ask questions that can prove you wrong. If no answer would change the plan, it isn't really research.
- Celebrate the kills. When a study stops a feature, call out the time and money it saved. Make "we didn't build that" a win.
- Keep a "not building" list. Write down what you decided against and why, so the idea doesn't quietly come back next quarter.
The Bottom Line
What building a local event taught us.
- 01
A "no" from research is a result, not a failure.
- 02
The cheapest time to kill a feature is before anyone builds it.
- 03
Ask how people work today, not whether they'd use your idea.
- 04
Make dropping an idea something the team celebrates.
Better products have fewer, better features
The best products aren't the ones that do the most. They're the ones that do the right things well. Getting there means saying no a lot, and research is how you know which nos to say.
So next time a study comes back and tells you not to build something, don't bury it. Thank it.
From research and strategy to design and development, we help teams create digital experiences grounded in real user needs.
Let's chatFAQ
View AllTreat it as a result, not a problem. If research shows users don't have the problem a feature solves, dropping or reshaping the feature before it's built saves design, engineering and maintenance costs. The earlier research happens, the easier it is to act on.
Before the team commits to building something. Research done early, while ideas are still cheap to change, can shape or stop a feature. Research done after the roadmap is set often becomes a formality.
People tend to say yes to be polite, and they're not good at predicting their own behavior. Asking how they handle a task today shows whether the problem is real and how big it is.
More than the build itself. Every shipped feature needs ongoing maintenance, support and documentation, adds complexity for users and makes future design harder. Removing it later is often its own project.