Where I'd actually start as the BA on this project.

Start with questions?

What does the business need? Who are the users? What should the system do? That's the reflex every BA is trained into, and of course it's important to ask questions. But to ask the right ones, you first need to know the domain.

Most BAs, at some point, have to learn the new world they've landed in before they can get to that first step of asking anything. Let's call it step 0.5.

So you might assume a Business Analyst starts by gathering requirements. We don't. We start by understanding the world we're about to walk into. The requirements come later, and they come easier, once you actually speak the language of the room.

Here's what that looked like.

The insurance lingo

The fictional company I'm working with is a mid-sized Canadian property and casualty insurer. Five hundred FNOL calls a day, each one taking an agent three to five minutes to triage by hand. They want to bring AI into that workflow. I'm the BA. And before I could be useful in a single meeting, I had to learn what any of that actually meant. So, the basics.

P&C stands for property and casualty (the insurance that covers your stuff and your liability, as opposed to your life or your health). Inside that, there are two worlds. Personal lines, which is your car and your home and your individual policies. And commercial lines, which is businesses insuring their buildings, fleets, and operations. A BA who walks into an insurance project and can't tell those two apart will spend the first three weeks being talked past. Someone says "commercial auto" in a meeting and moves on, and you're nodding along with no idea what just got decided.

Then there's FNOL. First Notice of Loss. It's the moment a customer first reports that something happened. A fender bender, a flooded basement, a break-in. That phone call is the FNOL, and it's the exact thing this project is about. Five hundred of them a day. The agent picks up, the customer's usually stressed, and they have to work out what happened, whether it's covered, and what to do next. Three to five minutes, five hundred times a day. You can see the problem without anyone explaining it to you, but only if you know what FNOL means in the first place.

The part that took me longest was the policy lifecycle. A policy moves through stages. It starts as a quote (the price you're offered before you commit). It becomes a bind (the moment cover actually starts). Then it sits in-force (active and live). Along the way the customer might make an endorsement (a mid-term change, like adding a new driver). If something goes wrong, that's the claim, which is where FNOL lives. At the end of the term it either renews or cancels. Quote, bind, in-force, endorsement, claim, renewal, cancellation. That's the whole arc, and every system and every stakeholder I talk to sits somewhere on it. Knowing where the FNOL call falls in that lifecycle tells me who I need to talk to, and what data already exists before the call even comes in.

Then I went looking to see whether anyone's actually doing this in the real world, because a hypothetical's only worth something if it's grounded in something real. They are.

Definity, a Canadian P&C insurer and the parent company of Economical and Sonnet, worked with Google Cloud and Deloitte to modernize exactly this kind of call workflow using Vertex AI. The reported result was around three and a half minutes saved per call, roughly forty percent of the average handle time. That's the same three to five minutes my fictional agents are losing on every call.

The tea of it

None of that is a requirement. I haven't proposed a single feature or drawn one workflow. All I did was learn the language, and step 0.5 is officially done. But look what it bought me. I can sit in a meeting now and actually know the difference between a claim and an endorsement. I can ask where in the lifecycle the data already lives, and a dozen sharper questions besides.

The people in that room have spent years inside this business, and the least you can do is learn enough of their world to ask an intelligent question.

Domain fluency is what earns you the right to gather requirements at all.

So that's where I start. With the language, before anything else.

And there's more to this than the tidy version I just gave you. In a real project the domain never sits still long enough to fit in a paragraph, and the same word means different things depending on which desk it's spoken from. You learn it slowly, in conversations, over weeks. For what it's worth, everything I just summarized here is a full day of reading up on insurance and watching a ton of videos. And it matters more than people let on.

The Project Management Institute has spent years pointing at poor requirements as one of the biggest reasons software projects fall over, and poor requirements are usually just a team that skipped step 0.5. So I'm not skipping it.

Once you know the language, the next move is obvious. You go and talk to the people who live it every day.

Sayonara.