Why Product Design Teams Build Features Customers Don’t Want
Quick answer: Product teams build features customers don’t want when roadmap decisions come from internal assumptions, one loud customer, or an informal conversation instead of structured customer research. The fix: invest in quality research before you invest in costly mistakes.
Somewhere in your organization right now, a team is scoping a feature that will ship on time, pass every acceptance criterion, and still fail. Not because of bad execution. Because nobody checked whether customers wanted the feature in the first place.
This is one of the most expensive — and most avoidable — patterns in product development. Teams are full of smart, motivated people who are very good at building things. What they’re often missing isn’t skill; it’s a clear, validated picture of the customer on the other end of the feature. Here’s why that keeps happening, what it costs, and how to build customer research into your product development process before it becomes a very expensive lesson.
The Real Cost of Product Design Without Customer Research
Building without research is expensive, and the data backs that up. An often-cited Standish Group analysis found that the majority of features built into software products are rarely or never used by the customers they were built for, meaning teams routinely pour months of engineering time into work that never earns its keep. Separately, research from CB Insights on startup and product failure consistently names “no market need” as the single largest cause of failure, ahead of running out of cash, hiring problems, or competition. In other words: it’s not usually the build that fails. It’s the assumption behind it.
That pattern doesn’t only show up in startups. Inside established B2B organizations, it shows up every time a roadmap gets prioritized around what leadership believes customers want, what a competitor just launched, or what internal stakeholders are asking for — instead of what real customers have actually said, in their own words, about their own problems.
This is where product development research earns its keep. Done early, it’s the cheapest insurance a product team can buy. Done after launch (in the form of a support ticket, a churn conversation, or a feature nobody adopts) is a lesson paid for in engineering hours, missed roadmap opportunity, and credibility with the customers who told you, one way or another, that you’d missed the mark.
The Problem Isn’t Instinct. It’s What the Instinct Is Built On
Product teams aren’t guessing randomly. But they may be working under the idea of “this worked before, so it’ll probably work again.” The trouble is that “worked before” is making a lot of assumptions without data. A product that succeeds with one audience, in one category, under one set of conditions, is believed to be true for all. Next thing you know, the roadmap moves forward on an assumption, not on anything a customer actually wants.
It’s not a bad instinct. It’s just not evidence. And the two get confused.
A Product We Talked a Client Out Of Building
A large healthcare company came to us for a project. Having built a successful software product and app in one healthcare category, they set their sights on a second category.
“They thought the payers and their members would want this particular product,” Noël Adams, founder and president of Clearworks, says. “They’d had tremendous success with something similar in another category, so they hoped it would translate. They hired us to talk to their potential clients and test the product concept.”
The research told a different story.
“People didn’t want that particular product. It wasn’t a real pain point for them and not a problem they needed to solve. They also didn’t think it would be successful with their members.”
What happened next is the part worth paying attention to. “The client was really open to that feedback, and honestly glad they’d made the investment in the research,” Adams says. “They went to the senior team that makes the call on the product roadmap and said, we advise against developing this. Because they’d brought us in early, before the product was fully built, they were able to halt development without a full investment and instead look at some of the other ideas that had come out of the research. Not this, but this: here’s what we think might actually be worth pursuing next.”
While “building first, testing later” is a familiar pattern, it can be a costly rework if you skip doing the research first.
“Sometimes when you do research, clients don’t want to hear that the idea doesn’t resonate,” Adams says. “But if you’re open to that feedback, you can save yourself a lot of time and money.”
The Danger of Building for Your Loudest Customer
Not every flawed roadmap decision comes from a big strategic assumption. Sometimes it comes from something smaller: one persistent customer, or one persuasive voice on the sales team.
“You could wind up developing something that one customer wants and no one else does,” Adams says. “Unless you’re in a services business where someone’s paying you to custom-build something, that’s a very expensive way to do product development. It’s costly, it can turn off other customers, and it can take your resources down a path that isn’t the right one.”
The request itself isn’t the problem. Treating it as representative of everyone is.
| Signal | What it tells you | What it doesn’t tell you |
|---|---|---|
| One customer’s feature request | What that customer wants, right now | Whether it’s a shared pain point, or worth paying for |
| A handful of sales-team asks | Where deals might be stalling | Whether it’s the real blocker, or one buyer’s preference |
| Structured customer research | What a representative group of customers need — and will pay for | Whether what you learn will last. Continue researching, continue adjusting. |
The One Question Every Roadmap Item Should Answer First
Asked what a product team should be able to answer before anything goes on the roadmap, Adams kept it simple.
“I just think, in general, they should be able to identify who their customers are and what they are trying to achieve,” she says.
It sounds almost too basic to state. In practice, it’s the question most roadmap debates skip past entirely. Instead, teams argue about the feature before they’ve aligned on who they are building for.
“I Had Lunch With a Customer” Isn’t Customer Research
Adams’s biggest flag for product leaders isn’t that teams avoid talking to customers; it’s that they mistake talking to customers for conducting research.
“I don’t know that product teams have a misconception about customer feedback, other than sometimes thinking, I had lunch with a customer, I know what they want — they told me how they’re feeling,” she says. “It’s always great to have lunch with customers, have conversations with customers. But understand the difference between having a conversation with a customer and doing real research.”
That difference is structural, not just a matter of effort:
| Aspect | Casual customer conversation | Structured customer research |
|---|---|---|
| Purpose | Relationship-building, informal check-in | Uncovering real needs, pain points, and willingness to pay |
| Questions | Unplanned, often closed-ended | Built in advance around an open-ended discussion guide |
| Depth | Stops at the first answer | Probes past the first answer to get to the real one |
| Who’s represented | Whoever you happen to talk to | A deliberately chosen, representative group |
| Main risk | Mistaking one opinion for a pattern | Low — findings are tested, not assumed |
“We’ve coached product teams on how to interview customers,” Adams adds. “What questions to ask, how to structure a discussion guide, how to ask open-ended instead of closed-ended questions, how to probe more deeply when you get a surface-level answer. It’s not about turning everyone into a researcher — we still encourage product teams to have conversations with customers, always. It’s about knowing the difference between a casual conversation and a structured research project, and using each one for what it’s actually good for.”
How to Build a Roadmap Customers Actually Want
Pulling this together, a few practices separate teams that catch a bad idea early from teams that find out after launch:
- Start with a discussion guide, not a hunch. Decide what you’re trying to learn before you talk to anyone — not just which questions to ask, but what you’d do differently depending on the answer.
- Ask open-ended questions. Closed questions confirm what you already believe. Open ones surface what you didn’t know to ask.
- Probe past the first answer. The real insight is rarely the first thing a customer says — it’s the “why” behind it.
- Test the concept before you build it. A structured concept test, run while an idea is still inexpensive to change, is the difference between adjusting a plan and writing off a launch.
- Bring the customer’s actual voice back into the room.
“There’s nothing more telling than actual quotes, video, and stories from real customers to change how people think,” Adams says. “That’s why we encourage clients not just to do the research, but to use it internally — to show stakeholders what customers really want, in their own words.” A senior team is far more likely to change course after watching a customer say something plainly than after reading a slide of survey statistics.
Frequently Asked Questions
Why do product teams keep building features customers don’t want?
Because roadmap decisions often come from internal assumptions, one vocal customer, or a casual conversation, rather than structured research. Without a discussion guide, open-ended questions, and follow-up probing, teams mistake surface-level feedback for real customer understanding.
What’s the difference between customer feedback and customer research?
Customer feedback — a comment over lunch, a note from sales — tells you what one person said in the moment. Customer research uses a planned, open-ended discussion guide with a representative group to uncover what customers are actually trying to achieve, and whether they’d pay to solve it.
What question should every product team answer before development starts?
Who is the customer, and what are they trying to achieve? If a product team can’t answer both, specifically, the feature isn’t ready for the roadmap.
Why is it risky to build a feature because one customer requested it?
A single request may not represent the broader customer base. Building around one voice can be expensive, pull resources from features more customers need, and in some cases turn off the rest of your users.
How can product teams validate an idea before building it?
Test the concept with real customers before development begins, using structured qualitative research rather than informal conversation. It’s far cheaper to learn “no” during a concept test than after a launch.
We’d rather talk about you.
If your roadmap is running more on assumption than evidence, let’s talk about what a structured concept test, a Customer Advisory Board, or even a handful of well-run interviews could tell you before you build. Reach out →
Share this blog post:
