A BA I respect told me last month that the five-question approach to requirements doesn’t work in her org. The questions are fine, she said. The problem is that her stakeholders refuse to answer them. They take the request as adversarial. They escalate. They go to her manager. They say “just build what I asked for, why are you making this hard.”
She’s not wrong about the problem. Most BA training assumes the stakeholder wants to collaborate on getting the requirement right. A meaningful number of real stakeholders don’t. They want their solution built. The questions feel like obstruction.
This piece is about what to do when the framework meets resistance. Not theory, not “build trust through active listening.” The actual moves.
Why the resistance exists
Before the tactics, the diagnosis. Stakeholders push back on the questions for four common reasons, and the right response depends on which one you’re facing.
One. They’ve already made the decision and the request is just delegation. The stakeholder isn’t asking for help solving a problem. They’ve decided what to build and are routing the work to you. From their perspective, the questions look like you’re refusing to do your job. The fact that the decision might be wrong isn’t part of their model — they made it, it’s done.
Two. They don’t actually know the answers. They proposed a solution because proposing a solution feels more authoritative than admitting they’re not sure what the problem is. The questions threaten to expose this. The resistance is defensive, not aggressive.
Three. They have political reasons that they can’t share. Sometimes the request exists because their boss wants it, or because a board member mentioned it, or because the team needs to be seen doing something. The “real” reason can’t be discussed openly, so they describe a fake reason and resist any probing that might break the fiction.
Four. They’ve been burned before by BAs who used questions to delay or refuse work. This is rarer but real. Past BA on the team treated every request as a chance to push back, never delivered anything, and the stakeholder learned to route around questions as a survival strategy.
The tactics that work are different for each. The mistake most BAs make is treating all resistance as the same and using the same approach against all four.
Tactic one: route the questions through the artifact, not the conversation
The most common mistake is asking the questions verbally, in real time, to the stakeholder’s face. This is the maximum-friction version. The stakeholder feels challenged, has to think on the spot, and any uncertainty in their answer feels like exposure.
Better: write the artifact yourself, with your best guess at the five answers, and send it to the stakeholder for review. Now the questions aren’t questions — they’re claims you’ve made about their request. They can correct your claims or leave them. The cognitive load shifts from “answer this BA’s interrogation” to “fix what they got wrong about my request.”
Example. Instead of asking the Sales VP, “Who specifically would use the customer health score dashboard and how often?”, you send her a one-pager that opens: “Based on our conversation, the primary user is you, for your weekly Friday account review. The CSMs would consult it secondarily but their existing spreadsheets handle most of the same view.” Now she either confirms, or corrects (“Actually, I want the CSMs to use it as their primary view”), or — most usefully — pauses, because seeing the claim laid out makes her realise she hadn’t actually thought about who the user is.
This works on three of the four resistance types. It doesn’t help with the political-reasons case, but the other three soften considerably when the questions become claims.
Tactic two: anchor on cost, not correctness
When a stakeholder believes they’ve already decided, “is this the right thing to build” is an attack on their decision. The argument doesn’t move them.
What moves them is cost. Specifically, the cost of being wrong in a way they didn’t see coming. Most stakeholders haven’t actually thought about what happens if their proposed solution doesn’t work as expected. The questions feel like obstruction; the cost framing feels like risk management, which is their language.
Concrete moves:
- “If we ship this and it doesn’t move the metric you care about, what’s our next move?” This forces them to consider failure scenarios without saying their idea might fail.
- “If three months from now this is shipped and nothing’s changed, what would we tell leadership?” Implicit: there’s a leadership-facing version of failure that’s worse than a leadership-facing version of slower delivery.
- “What’s the rough cost if we build the wrong thing and have to rebuild?” Quantifying makes the abstract risk concrete.
These questions get asked in the same conversation but feel less adversarial because they’re about consequences, not about whether the stakeholder thought hard enough.
Tactic three: give them a fast path out
The resistance often hardens because the stakeholder feels the questions will lead to weeks of delay. They’ve seen this pattern: BA asks questions, calls more meetings, drafts more documents, and three weeks later the request still hasn’t entered the backlog.
Counter it explicitly. Pre-commit to a timeline. “I need ninety minutes to validate this and I’ll have the artifact back to you by Tuesday. After that, we either start scoping or I tell you what changed and you decide.” The deal is: a tight, bounded analysis period in exchange for permission to ask the questions at all.
Most stakeholders accept this because the cost is small. Ninety minutes of analysis time plus three days of waiting is a much smaller ask than “answer my questions every time we talk.” The framework still runs; you just compress it into a defined window and trade speed for honesty.
Tactic four: escalate the right kind of disagreement
Sometimes the resistance is genuine and irreducible. The stakeholder believes the solution is right, you believe it isn’t, and the five questions haven’t moved either of you. At this point, the temptation is to keep arguing. Don’t.
Instead, write the artifact with both views included. “Stakeholder believes the correct approach is X for reasons Y. Analysis suggests Z for reasons W. Recommend X be built with explicit success criteria; if criteria aren’t met within Q time, we’ll revisit.” Send it up the chain to whoever owns the decision — usually the stakeholder’s manager or the product owner.
This isn’t going around the stakeholder. It’s surfacing a disagreement that the org needs to resolve. The BA who tries to win every requirements argument personally is the BA who burns out and leaves. The BA who escalates honestly, with both views fairly stated, gets a reputation for being trustworthy in conflict — which is the most valuable reputation a BA can have.
Important: this only works if the artifact is genuinely fair. If the “stakeholder’s view” section is a weak strawman of their position, you’ll be (correctly) seen as setting them up. Steelman their view. Then state yours. Then let the chain decide.
Tactic five: accept that some battles are not winnable
Sometimes the stakeholder will refuse the questions, refuse the artifact, refuse the cost framing, and refuse to be escalated. They have the political weight to insist that their request gets built as specified, and your job is to ship it.
In this case, the play is documentation, not argument. Write down what they asked for. Write down what you believed the risks were. Write down what success looks like and what failure looks like. Build the thing. When it ships and the outcome is bad, the documentation exists. When the question of “how did this happen” comes around, the answer is on the page.
This isn’t passive-aggression. It’s professional self-protection in environments where you can’t do the job correctly. The BAs who don’t do this get blamed for outcomes they had no control over. The BAs who do this build a paper trail that, over time, becomes evidence for the larger conversation about how this team makes decisions.
If the documentation pattern repeats more than two or three times, the real lesson isn’t tactical — it’s that this org doesn’t value the work you’re trying to do. That’s a career signal, not a requirements signal.
What the framework is really for
The five questions are not a debate-club tool. They’re not designed to win arguments with stakeholders who’d rather not have them.
They’re designed to make the thinking visible — to the BA, to the team, and to whoever later reviews how the decision was made. When a stakeholder refuses the questions, the framework still does work: it produces a record showing that the analysis was attempted and what happened. That record is valuable on the day, three months later, when someone asks why the feature didn’t work.
The point isn’t to convert every stakeholder. The point is to make sure the thinking happens somewhere — on the page, in the artifact, in the escalation, or in your private notes when you couldn’t do it any other way. The framework runs whether the stakeholder cooperates or not. The difference is just how loudly.
The next piece in this series looks at the specific case of stakeholders who outrank you and how to push back without breaking the relationship. Subscribe below to get it.