How to Handle Conflicting Feedback from Users and Sales
It’s a familiar situation. User research says people want the product to be simpler — fewer options, fewer steps, less to configure. Meanwhile, sales is asking for more configuration options, because the last three deals they almost lost came down to a prospect needing some specific setting that competitors offer, and you don’t.
Both groups are right, from where they’re standing. Users who are already using the product want it to be easier to use. Prospects who haven’t bought yet want it to do more before they commit. These aren’t contradictory facts about the world — they’re two different audiences with two different relationships to the product, and conflicting feedback from users and sales is less a problem to solve and more a permanent feature of the job.
A common version of this: a small B2B tool where user interviews were unanimous that the settings page had gotten cluttered, while sales was pushing hard for a bulk-import option because two enterprise deals had stalled without it. The instinct, in a case like that, is to treat it like a tug-of-war that needs a referee. It’s only when someone actually pulls the deal notes and finds the bulk-import request had only come up in those same two deals — both of which also had pricing objections — that the “sales wants more” signal reveals itself as thinner than it sounded, and the simplification work turns out to be the better bet by a wide margin.
Why users and sales often want different things
Existing users have already made the decision to use your product. Their experience is shaped by everything that’s accumulated since — every feature, every setting, every menu. From inside that experience, complexity is mostly a cost. More options usually mean more friction, more to learn, more ways to get confused. This is often what surfaces first in structured user interviews, where the same complaint about clutter tends to come up unprompted across otherwise unrelated conversations.
Sales, on the other hand, is mostly talking to people who haven’t decided yet, and who are often comparing your product against others’ features, feature-by-feature. In that context, “we don’t have X” is a real objection, even if X is something that, once added, would barely get used by anyone. The absence of a feature can lose a deal even if the presence of that feature wouldn’t meaningfully help anyone who already has it.
So when user feedback says “simplify” and sales feedback says “add more,” they’re not actually disagreeing about what’s good for the product in some abstract sense — they’re each accurately reporting what they’re hearing from the people they talk to. The conflict is real, but it’s not a contradiction. It’s two valid signals pointing in different directions because they’re coming from different points in the customer lifecycle.
A framework for weighing conflicting feedback from users and sales
When this comes up, the question that actually matters isn’t “who’s right” — it’s “which of these, if addressed, moves a number we care about more.” That reframes the conversation from a popularity contest between teams into something closer to a prioritization decision, which is more your territory anyway. A structured approach like the RICE scoring model is useful here precisely because it forces both sides of a conflicting request through the same evaluation, rather than letting whichever team argued more persuasively win by default.
It also helps to separate the feature being requested from the underlying need behind it, because these aren’t always the same thing, and conflating them is part of what makes the conflict feel so absolute. Sales might be asking for “an advanced settings panel with twenty new options,” but the underlying need might just be “the ability to handle this one specific configuration that came up in three deals.” Users asking for “simplify the product” might really mean “stop putting new options in the main navigation” rather than “remove capabilities entirely.” Once you get under the surface request, you sometimes find that what sales actually needs and what users actually want aren’t as opposed as the headline versions made them sound.
Start by trying to quantify each side, even roughly. How many existing users are affected by the complexity issue, and what’s the actual cost — are they making errors, contacting support more, or is it more of a “this would be nicer” preference? On the sales side, how many deals, over what time period, have actually been lost or stalled specifically because of the missing capability — not “a prospect mentioned it” but “this was a stated reason a deal didn’t close.”
Often, when you actually dig into the sales side of this, the picture is less dramatic than “we’re losing every deal because of this.” Maybe it’s come up in two deals out of fifty this quarter, and one of those deals had other issues too. That doesn’t mean the feedback is wrong — it means it’s one data point among many, not an emergency.
It’s worth noting that sales reps generally aren’t exaggerating on purpose when they say something is costing deals — from where they sit, a lost deal where a feature gap was mentioned often feels like a deal lost because of that gap, even if, on closer inspection, the deal had other problems too (budget, timing, a champion who left the company). This isn’t a criticism of sales; it’s just how attribution works when you’re close to something. The PM’s job here isn’t to dismiss that perception, but to look at it alongside everything else and see whether the pattern holds up across more than one or two cases.
Similarly, on the user side, “users want it simpler” can mean anything from “this is the top reason for churn” to “this came up once in a survey with low response rates.” Treating both kinds of feedback — vague directional sentiment vs. specific, attributable signals — as if they’re equally weighty is part of what makes this feel like an unsolvable conflict. Often, it’s not that the feedback conflicts; it’s that one side of it is much stronger evidence than the other, and that’s not always obvious at a glance.
When to trust the data over the loudest voice
Sales teams are, understandably, advocates for what helps them close deals — that’s literally their job, and it’s a useful perspective. But it also means sales feedback comes with a built-in bias toward “more” — more features, more flexibility, more things to say yes to in a deal conversation. That’s not a criticism; it’s just worth knowing it’s there when you’re weighing what you hear.
User feedback has its own bias, which is toward whoever’s currently engaged enough to give feedback at all. The users who fill out surveys or join interviews tend to be more engaged than average, which means their preferences might not represent your whole user base — including the much larger group of users who are quietly fine with things as they are, or who churned without saying why.
Neither bias makes the feedback useless. It just means neither “sales says” nor “users say” should be treated as a complete picture on its own. When you can, look for a third source that’s less filtered by who’s loudest — usage data from your metrics dashboard, support ticket volume and themes, win/loss analysis on actual closed-lost deals rather than anecdotes from a single rep. These tend to be slower to gather and less emotionally compelling than a frustrated Slack message from a sales lead, but they’re a lot more reliable for prioritization decisions.
There’s a useful test for whether a piece of feedback, from either side, deserves more weight: does it generalize? A single sales rep mentioning that one prospect asked about a feature is a data point about that rep’s pipeline. The same request showing up across multiple reps, in different deals, over a sustained period — that’s a pattern. Similarly, one user mentioning something in passing during an interview is different from the same theme surfacing unprompted across multiple, unrelated conversations. The volume and spread of a signal often matter more than how strongly any person expressed it.
Saying no to sales without burning the relationship
At some point, you’ll decide not to build something sales is asking for — at least not now, and possibly not ever in the form they’re picturing. How you communicate that matters almost as much as the decision itself. This is really the same discipline covered in the hidden cost of saying yes to every stakeholder request — sales is a stakeholder like any other, and the same tradeoff-first framing applies.
The least effective version of this is silence, or a vague “we’ll consider it for the roadmap” that everyone understands means no, but nobody says out loud. This doesn’t actually prevent the request from coming back — it just means it comes back later, often with more frustration attached, because the requester feels like they were brushed off rather than heard.
A better version explains the reasoning in terms that sales will recognize. “We looked at this, and over the last two quarters it’s come up in 2 of 50 deals — both of which had other blockers too. Given that, we don’t think this is the highest-leverage thing for us to build right now, compared to [whatever you’re prioritizing instead]. If it becomes a more frequent blocker, let’s revisit.” This doesn’t dismiss the feedback — it shows it was taken seriously, evaluated, and weighed against other things, which is honestly all most people are asking for, even when they don’t get the answer they wanted.
It also helps to give sales something in the meantime, if you can. Even if the full feature isn’t happening, is there a workaround, a smaller version, or talking points that address the underlying objection in a different way? “We’re not building X, but here’s how to position this when it comes up” gives sales something concrete to do with the conversation, rather than just a closed door.
Turning conflicting feedback from users and sales into a clearer roadmap
The long-term fix for this kind of recurring tension isn’t resolving it once — it’s creating a regular, visible process for weighing these signals against each other, so that “users vs. sales” stops being a recurring fight and starts being a routine part of how prioritization works.
Some teams do this with a recurring (monthly or quarterly) review where product, sales, and customer-facing teams look at a shared view of feedback themes — from users, from lost deals, from support — together. The point isn’t to resolve every tension in that meeting. It’s that everyone sees the same picture, understands why certain things get prioritized, and others don’t, and — over time — starts to internalize the kind of evidence that actually moves the needle, which tends to reduce the volume of “but a customer really wants this” requests that show up without context.
When the conflict is actually about timing, not direction
A version of this worth watching for: sometimes “users want simpler” and “sales wants more configuration” aren’t really in conflict about the destination — they’re in conflict about sequencing. A product can become both simpler for most users and more capable for power users or specific segments if those things are designed thoughtfully rather than treated as a single dial that only moves one way.
Progressive disclosure — where advanced options exist but are tucked away from the default experience — is the classic example. Most users never see the added complexity, but it’s there for the segment that needs it, including the prospect’s sales is trying to close. This doesn’t make the design work easier, and it’s not a free pass that resolves every version of this tension. But it’s worth checking, before assuming the two requests are fundamentally opposed, whether the real disagreement is about whether to build something or about how it should be exposed — because those are very different problems, and the second one often has more flexibility in it than it first appears.
Feedback Source Weighing
| Source | Frequency | Revenue Impact | Strategic Fit | Weight |
|---|---|---|---|---|
| User survey: “too complex” | Recurring theme, low response rate | Indirect (engagement, support load) | Aligns with simplification goal | Medium |
| Sales: missing config option | 2 of 50 deals this quarter | Direct, but limited deals affected | Conflicts with the simplification goal | Low-Medium |
| Support tickets: confusion on setup | High volume, growing | Indirect (support cost, churn risk) | Aligns with simplification goal | High |
| Win/loss analysis: feature gap | 1 of 12 lost deals analyzed | Direct, single deal | Neutral — isolated case | Low |
Conflicting feedback from users and sales isn’t a sign that something’s broken in how feedback gets collected. It’s just what it looks like when a product serves people at different stages of their relationship with it. The job isn’t to make the conflict go away — it’s to have a process solid enough that when it shows up, which it will, again and again, it doesn’t feel like a fight every time.
References
- Productboard — resources on customer feedback management for product teams
- Silicon Valley Product Group — writing on prioritization frameworks
- Gainsight — resources on aligning product and sales around customer feedback
