Resistance is not the obstacle. It is the clearest requirements document you will get for free.
A downstream report broke during testing, three months into a program that was otherwise on track. The number behind it had been wrong for years, quietly corrupting billing data nobody had traced back far enough to notice. The person who could have stopped it had already tried. In a requirements workshop months earlier, she had flatly refused to let a single field get cut from the new design. Nobody on the project team could find a use for it. Two people gently suggested she let it go. She would not move, so the team noted her as resistant, worked around her, and kept the agenda moving.
That field was the only place a specific reconciliation number lived, the one she pulled by hand every month to catch a billing error nobody else knew existed. She had not been resisting change. She had been protecting the one piece of the current process that actually worked, and nobody had asked her why it mattered before deciding it did not.
Resistance is data, not a problem to manage
Most of what gets labeled resistance is not opposition to change itself. It is a person telling you, in the only language available to them in that moment, that the proposed future does not yet account for something they know to be true. Treating that as a behavior to overcome, something to manage with better change communication or more stakeholder buy-in sessions, throws away the most specific input you are going to get. It is the same instinct behind treating a process gap as a failure to correct instead of information about how the system actually works: the reaction contains the requirement, if you are willing to ask instead of push past it.
This reframe changes what a requirements conversation is for. The goal stops being persuasion, getting the room to agree with the design, and becomes discovery, finding out what the pushback is protecting before deciding whether it still needs protecting.
Telling protective resistance from comfort resistance
Not every objection is a hidden requirement. Some really are just discomfort with change, and pretending otherwise wastes just as much time as ignoring the ones that matter. The two look identical in the room. They sound different the moment you ask one follow-up question: “What would actually break, for you or for someone downstream, if we did this anyway?”
- If the answer is specific, a report, a reconciliation, a downstream team, a regulatory check, a manual workaround for a known defect, you are looking at protective resistance. Treat it as a requirement that has not been written down anywhere yet, because it hasn’t. It has only ever lived in one person’s head and their weekly routine.
- If the answer is vague, “it just feels risky,” “we’ve always done it this way,” “I’m not sure, it just seems wrong,” you are looking at comfort resistance. That is real too, and worth acknowledging directly, but it is a change-management conversation, not a requirements one.
The test is not whether someone can articulate their objection well in the moment. Plenty of people who are protecting something real are bad at explaining why on the spot. The test is whether a concrete consequence exists at all, findable or not yet found. That is what step two, below, is for.
Where this shows up, and what to actually do
The pattern repeats across every phase of a program. Each phase needs a specific action, not just a reframed question.
- Requirements validation. Pushback on removing a field, a step, or an approval is rarely about the field itself. Before the decision gets made, not after, trace it: who consumes this today, by name, and what do they use it for. Do not let “we couldn’t find a use for it” stand in for “we asked the person who uses it.”
- Current-state mapping. When someone insists the documented process is wrong, do not note it and move on. Schedule a short, dedicated follow-up with that person specifically, walking the actual steps they take, in order, including the parts that feel too obvious to mention.
- Future-state design. When a stakeholder pushes back hardest on a proposed future workflow, the fix is not a better explanation after the fact. It is bringing that person into the design conversation itself, before the workflow is finished enough to defend, starting from their own picture of success rather than presenting one already built.
A three-step response, not a slogan
When resistance shows up in the room, run it through the same three steps every time:
- Ask what it protects. “What would break, for you or downstream, if we did this anyway?” Ask it plainly, without defensiveness, and let the silence sit if it takes a moment to answer.
- Verify the answer instead of taking it at face value or dismissing it. Trace the field, interview the downstream consumer, pull the report, check the regulation. This is the step teams skip most often, either accepting the objection uncritically to avoid conflict, or waving it off to keep the agenda moving.
- Decide, and document the reason, not just the outcome. Keep it as-is, redesign around it, or consciously retire it, but write down why, in terms of what was verified in step two.
The stakeholder who won’t let go of a requirement is usually the one who understands the current state best.
What this is not
This is not a mandate to keep every field, step, or approval anyone objects to. It is not a script for winning an argument, and asking “what does this protect” as a rhetorical move, without actually verifying the answer, is worse than not asking at all, because it trains people to stop bringing concerns forward. It is also not a reason to skip the harder comfort-resistance conversations by relabeling them as protective. The three-step process above only works if step two is real, if you actually go check, rather than accepting or dismissing what you hear in the room. It is the same discipline behind building real shared understanding instead of just sending more updates.
The stakeholder who pushes back hardest in a requirements session is frequently the same one who, three months later, would have told you exactly where the future state was about to break, if anyone had asked what success looked like to her before deciding what to build.
More essays like this one live on the Between Mondays articles page.
Further reading: the American Psychological Association and the Project Management Institute both publish on the psychology of resistance and requirements practice.
Frequently asked questions
Why should a leader treat stakeholder resistance as data instead of a problem to overcome?
Because resistance is often a person telling you the proposed future does not yet account for something they know to be true. Treating it as a behavior to manage with more persuasion throws away the most specific requirements input you are going to get.
How can you tell protective resistance from simple discomfort with change?
Ask what would actually break, for them or someone downstream, if you did it anyway. A specific answer, a report, a reconciliation, a regulatory check, signals protective resistance. A vague answer, like it just feels risky, signals comfort resistance instead.
What should you do when a stakeholder pushes back during a requirements workshop?
Trace it before the decision gets made: find out who consumes the field or step today, by name, and what they use it for. Do not let an inability to find a use for something stand in for actually asking the person who uses it.
What is the three-step response to resistance in a working session?
Ask what it protects, verify the answer instead of accepting or dismissing it at face value, then decide and document the reason, not just the outcome, so the next person can find a real answer instead of guessing.
Does treating resistance as a signal mean every objection should be honored?
No. Some resistance really is just discomfort with change, and that is a change-management conversation, not a requirements one. The three-step process only works if the verification step is real rather than skipped in either direction.