In the last post I said domain fluency earns you the right to ask questions. So now I've earned that right. The question is, what do I actually do with it? So we get to the asking-questions bit. The gathering requirements part. Let's go.
The Question Rabbit Hole
If you Google "stakeholder interview questions BA," you'll get a tidy list of questions: What are your goals. What are your pain points. What does success look like, the whole nine yards. But the questions themselves don't come first.
Who You Ask Comes First
The order of conversations decides what you learn from any single one of them. And many BAs reverse this all the time. They book the executive sponsor first because it feels safer and more important, and then they spend the next six weeks slowly discovering that the executive's mental model of how the claims process works is two quarters out of date, and that everything they wrote down in that first meeting was based on what claims used to look like.
For me, here's the order I'd go with on this project, from first to last:
Frontline first. The agent who actually answers the FNOL calls at two in the afternoon on a Tuesday. They know what's broken in a way nobody upstairs does. Not what's supposed to happen, what actually happens.
Then the team lead. Someone who's been on the floor recently enough to remember, but is now thinking about throughput and queues and what the dashboard shows. They translate between the frontline and the rest of the org.
Then the claims adjuster on the other side of the routing. They receive whatever the agent passes along, and they'll tell you very quickly which routing decisions waste their time.
Then the executive sponsor. By the time I'm sitting in that office, I've got real ground-truth from three different angles. Now when the executive describes the problem they think they're solving, I can quietly check whether that lines up with what the people doing the work just told me. Half the time it doesn't match. And that mismatch is the most useful conversation I'll have all month.
The executive sponsor goes last.
With everything you've gathered from the ground up, you've earned the right to push back on the executive's assumptions. You only know more than them if you've talked to everyone else first.
Same Room, Same Role, Different Personalities
Two people can sit in the same chair, and the same opening question will land completely differently.
The senior adjuster who's been doing this for fifteen years and is mildly annoyed you're in their meeting needs a very different opener than the new agent who joined six months ago and wants to be helpful. Same goal. Same information you're trying to draw out. Different doors in.
The senior one usually wants you to prove you've done your homework before they'll give you anything real. So I'd open with something specific. "Walk me through what happens when a flood claim and a fire claim come in within an hour of each other. Which one wins, and how do you decide?" That tells them I've already done step 0.5.
The new agent usually wants permission to be honest. So I'd open softer and broader. "Tell me about the last call that frustrated you this week." That gives them room. They'll fill it.
And it cuts the other way too. My own personality is in the room whether I notice or not. I'm chatty and curious by default, which works well with the cautious ones who need warming up. It works less well with the no-nonsense veterans who'd rather I get to the point in the first thirty seconds. So I have to flex. Direct BAs have the opposite problem: they get great answers from the veterans and accidentally bulldoze the quieter people who needed two more beats before they were ready to talk.
There isn't a formula for this. You watch how they sit. You watch what they laugh at. You ask a small question first and see whether the answer comes back short or long. You adjust. The fixed list of questions you brought in with you can wait. So you're not just asking questions, you're studying body language, poise, expressions.
The Real World and Real People
Here's the part I have to be honest about, because I'm doing this in public and I want to be clear about what's hypothetical.
In an actual project, half the people I'd interview wouldn't be coherent. It happens because nobody in the building has ever asked them to put words on what they do. They've done the job for years, but the doing is muscle memory, not language. So when you ask them to articulate it, you get half-sentences, contradictions, tangents, "well, it depends, except sometimes it doesn't." A new BA writes that off as a bad interview and goes looking for a more articulate stakeholder.
I think that's a mistake. The mess is the most honest thing you'll hear all week. They're processing it out loud for the first time, in real time, in front of you. Your job is to sit in the mess with them. Ask the next gentle question. Repeat back what you think you heard, in your own words, and let them tell you what you got wrong. Eventually something clean falls out of it. Sometimes it takes two conversations.
I can't fully simulate that in a series of blog posts. When I write up the actual outputs from the stakeholder conversations, you'll see them tidied. In a real project they'd be five times messier on the way to that tidy version, and I'd have done five times the work to get there.
The next move, once all of those conversations are done, is taking that pile of contradictions and half-thoughts and turning it into something a decision-maker can act on. Which is where the business case starts.
Sayonara.
Once the conversations are done, you have a pile of contradictions and half-thoughts. Post three is about turning that pile into something a decision-maker can actually act on.
