Diagnosing resistance before you persuade

"I have the data. I have the benchmarks. I don't understand why they won't move."

That's what a PM I work with told me after months of pushing for a change he was convinced would unlock significant impact. he was working on ranking for a marketplace, and had identified a gap in the information architecture that required changes to how the app's surfaces were designed.

The opportunity was real. Not just for user experience, but for what it could teach them about how their marketplace ecosystem actually behaved. he'd done the work. Quantitative data showing the gap. Industry benchmarks from analogous products. A clear hypothesis about the behavior change it would drive. By any reasonable standard, the case was made.

And the team he needed to move kept saying no.

They'd engage, ask questions, raise concerns, and then the next meeting would come around and nothing had shifted. he'd address one objection and another would surface. he started wondering if the data wasn't compelling enough, so he found more. he started wondering if he wasn't communicating it clearly enough, so he refined her narrative. he got a few allies to weigh in. Still nothing.

What he didn't realize yet was that he was playing the wrong game entirely.

The team on the other side had legitimate concerns: design principles they'd built around, historical research that pointed in a different direction. They weren't being difficult. They weren't ignoring the data. They had a different evidentiary threshold, and he hadn't figured out what it was yet. More importantly, he hadn't asked.

That's the part most people skip.

When we hit resistance, the instinct is to push harder. Better data. Stronger arguments. More senior advocates. But resistance is rarely about the quality of your argument. It's almost always about something the other side hasn't told you yet, and until you know what that is, you're persuading in the dark.

So what does it actually look like to diagnose before you persuade?

It starts with three questions. Not steps, not a sequence. Lenses. You look through all three at once, and what they reveal together tells you how to move.

What do they actually care about?

Not what they're saying in the meeting. What they care about. There's usually a difference. Objections that sound like "this conflicts with our design principles" often mean "we've been burned before and we don't want to own the fallout." Objections that sound like "the research doesn't support this" often mean "I don't have enough confidence in this outcome to stake my team's roadmap on it." Your job isn't to overcome the objection. It's to understand what's underneath it.

This requires a different kind of conversation than most people have with resistant stakeholders. Less presenting, more asking. Less defending your position, more getting genuinely curious about theirs.

Where do your goals actually overlap?

Most stakeholder conflicts feel like opposing forces. Your outcome versus their objection. But that framing is almost always wrong. The team my client was trying to move cared deeply about user experience and about building surfaces that actually worked. So did he. They weren't on opposite sides of the problem. They were approaching the same problem from different angles with different risk tolerances.

Finding that shared goal doesn't mean compromising on your outcome. It means reframing the conversation so you're solving together instead of debating against each other. That shift changes everything about the dynamic.

What would make yes feel safe for them?

This is the question most people never ask. They focus on making their case stronger. But resistance is usually not about the strength of your argument, it's about the risk of agreeing. What does saying yes cost them? What are they accountable for if this doesn't work? What do they need to see before they'd feel comfortable moving?

My client's breakthrough didn't come from better data. It came from changing what he was asking for. Instead of pushing for the full surface change, he proposed testing on a smaller, lower-stakes surface first. Same hypothesis. Same potential upside. A fraction of the risk. Suddenly yes was possible, because yes didn't mean betting the whole thing on an unproven idea.

He also built her own prototype and ran it with real users, generating the kind of behavioral evidence that spoke directly to what the other team needed to see. Not more of the same data. A different kind of proof, designed around their threshold, not hers.

---

My client eventually got her experiment up and running. The results showed exactly the behavior change he'd predicted, and the emotional response from users that the other team needed to see to believe it. The smaller surface became the proof of concept that unlocked the larger one.

But what happened next is the part worth paying attention to.

He didn't just win that one initiative. he became someone that other teams wanted to work with. Because he'd demonstrated something rarer than good ideas or strong data: the ability to understand what other people need in order to move, and to meet them there without abandoning what he was trying to accomplish.

Her scope grew. Not because he pushed harder, but because he got smarter about how influence actually works.

Most people treat stakeholder resistance as an obstacle between them and their outcome. The best PMs I work with treat it as information. What is this resistance telling me about what they need? What does yes have to look like for them? And is there a version of my ask that gets us both to the same place?

That reframe, from persuasion to diagnosis, is one of the highest-leverage shifts you can make as a PM. It doesn't just help you win individual battles. It changes how people experience working with you, which over time changes what you get invited to work on.

If you're hitting a wall with a stakeholder right now and you're not sure whether you're missing something, that's usually a signal worth paying attention to.