When User Interviews Contradict Each Other

Last week, a founder I work with called me after a string of user interviews.

“They completely contradict each other,” she said. “One customer wants more automation. Another says we’ve already automated too much. One loves the new dashboard. Another says it’s overwhelming. What am I supposed to build?”

If you’ve spent any time in product, you’ve felt this. You do the right thing. You talk to customers. You gather feedback. And instead of clarity, you get noise.

At the same time, I’ve been watching other conversations unfold — PMs trying to escape dashboards with AI-powered Slack workflows, solo founders creating strict “default-no” rules to protect their roadmap, teams discovering that “simple” user stories aren’t simple once engineering starts building.

On the surface, these are separate threads. But underneath, they all orbit the same tension:

What do we do when reality refuses to be clean?

As someone who sits between customers and product teams every day, I’ve learned this the hard way: contradiction isn’t a research failure. It’s a signal that you’re finally close to the truth.

The Myth of the Consistent User

There’s a quiet assumption baked into a lot of product work: if we ask enough people the same question, the "right" answer will emerge.

Sometimes it does. Patterns matter. But more often than we admit, what emerges is complexity.

In a recent set of interviews for a B2B workflow tool, we heard three distinct perspectives on the same feature:

Operations leads wanted tighter controls and structured approvals.
Frontline users wanted fewer clicks and more autonomy.
Executives barely cared about the feature itself — they cared about reporting visibility.

All three were describing the same product. All three were frustrated. And all three were right.

This isn’t surprising when you zoom out. According to Nielsen Norman Group, even 5–8 user interviews can surface the majority of usability issues — but they also caution that different user segments will surface different classes of problems. In other words, inconsistency isn’t noise. It’s segmentation revealing itself.

The mistake isn’t that users disagree.

The mistake is assuming they’re supposed to.

What contradiction is actually telling you

When interviews diverge wildly, one of three things is usually happening:

You’re talking to different jobs-to-be-done. The surface persona might be the same. The underlying goal isn’t.
You’re seeing different levels of maturity. New users crave guidance. Power users crave speed.
You’re observing organizational tension, not product failure. Control vs autonomy. Speed vs compliance. Visibility vs simplicity.

When we treat these as product problems alone, we start patching features. When we treat them as ecosystem signals, we design more intentionally.

The Fragmentation Problem Isn’t Just About Tools

The post about AI-powered Slack workflows for PMs who hate dashboards resonated for a reason. Product work today is fragmented. Metrics live in one tool. Feedback in another. Roadmaps somewhere else. Support tickets in a different system entirely.

But here’s what I see from the customer side: our users are just as fragmented as our tools.

A single customer might interact with your product in three different modes in the same week:

As an individual contributor trying to move quickly
As a team member collaborating across functions
As a stakeholder reporting upward

If you interview them on Monday about speed, they’ll emphasize efficiency. If you talk to them on Friday after a compliance review, they’ll emphasize safeguards.

Neither answer is dishonest.

They’re context-dependent truths.

In fact, a Salesforce report found that 88% of customers say the experience a company provides is as important as its product. Experience is situational. It shifts based on pressure, environment, and stakes.

When we reduce research to static quotes, we flatten that dynamism.

As a Customer Success Lead, I’ve learned to ask one extra question in interviews and support calls:

“What was happening around you when this became a problem?”

That question changes everything. Suddenly we’re not debating features. We’re mapping context.

Scope Control Is Emotional, Not Just Strategic

The rise of “default-no” rules in solo SaaS is another response to contradiction. When feedback pulls you in ten directions, the safest move feels like narrowing the gate.

And to be clear — boundaries matter. Especially for small teams. According to CB Insights, 35% of startups fail because there’s no market need. But I’d argue a quieter percentage fail because they try to serve every need they hear.

Still, here’s the part we don’t talk about enough: saying no to feedback is emotionally hard.

When a customer takes the time to explain their pain, it feels personal. Especially in early-stage products where every user feels precious.

I once worked with a founder who kept a spreadsheet titled “Promises.” Every feature request was logged with the customer’s name beside it. Over time, that spreadsheet became a weight. Shipping anything felt like betraying someone else.

We reframed the conversation around three filters:

Is this a pattern or a person? (Have we heard this from multiple segments?)
Does this align with our core promise? (Or are we drifting?)
What problem does this solve beneath the request? (Sometimes the feature isn’t the answer.)

When we walked back through the spreadsheet with those lenses, more than half the requests weren’t “wrong.” They were just specific to contexts we weren’t built to serve.

The relief in that room was tangible.

Scope control isn’t about discipline alone. It’s about protecting clarity.

When “Simple” Stories Collapse Under Real Life

Another thread this week: “The Day Simple User Stories Stopped Being Simple.”

Every Customer Success person knows this moment.

A ticket comes in: “Just need a small tweak.”

Engineering estimates it at two days.

Two weeks later, we’re unraveling edge cases no one anticipated.

Why does this happen so often?

Because user stories are abstractions. Reality is layered.

A story might read: As an admin, I want to export a report so I can share it with leadership.

Straightforward — until you ask:

Which format?
With what permissions?
Filtered by which criteria?
For which regional compliance requirements?

What looked simple was actually sitting on top of policy, hierarchy, and workflow nuance.

This is where conflicting interviews and collapsing stories intersect. Users often answer based on their immediate mental model. Teams build based on a generalized one. The friction lives in the gap.

One practical shift we’ve made on my team is pairing every feature discussion with two artifacts:

A context map (who touches this, under what pressure?)
A failure map (where could this break in real life?)

It slows us down slightly at the start. It saves us months later.

The Real Work: Designing for Tension, Not Agreement

If there’s one pattern across all these conversations, it’s this:

We keep looking for alignment when what we actually need is navigation.

Alignment suggests everyone agrees. Navigation assumes they won’t.

In mature products, especially in B2B SaaS, tension is normal. Your product sits in the middle of competing incentives:

Finance wants predictability.
Operators want flexibility.
Leadership wants visibility.
End users want ease.

You are not designing for a single “user.” You are designing for a system of people.

And systems contain conflict.

The companies that handle this well don’t eliminate tension. They make it explicit.

They decide, clearly:

Who is this feature primarily for?
Whose friction are we willing to increase slightly to reduce someone else’s significantly?
What trade-offs are we consciously making?

That last question is the one we avoid most.

But in my experience, customers respond better to intentional trade-offs than to reactive sprawl.

I’ve had more trust-building conversations saying, “We built this for operations leaders, and we know it adds a step for frontline users — here’s why,” than pretending we can optimize for everyone simultaneously.

Clarity builds confidence. Even when the answer isn’t perfect.

Contradiction Is a Sign of Maturity

Early in a product’s life, feedback can feel unified. Everyone wants the basics to work.

As you grow, feedback fragments. That fragmentation isn’t decay. It’s depth.

It means people are integrating your product into real workflows, real hierarchies, real pressure.

Yes, it’s messier. Yes, it’s harder to roadmap. Yes, it forces uncomfortable prioritization.

But it’s also a sign that your product matters enough to be argued about.

As someone who lives in the space between what customers say and what teams can build, I’ve stopped fearing contradictory interviews.

Now, when I hear wildly different responses, I get curious.

What context is each person protecting? What pressure are they under? What outcome are they actually optimizing for?

When you answer those questions, the chaos starts to organize itself.

Not into a single clear directive.

But into something more honest: a map of tensions you can design around.

And that — more than unanimous interview quotes or clean dashboards — is what leads to products that survive contact with real life.