Leading business analysts

The first mistake I made leading analysts was treating the role as a waiting room for product management.

It’s a common assumption and it’s wrong in a specific way. It produces a team where the strong analysts leave for product roles, the ones who stay feel like they failed, and nobody is left who is good at the thing analysts are for.

Analysis is a discipline — not a waiting room.

The distinction that actually matters

A product manager is accountable for whether something is a good idea. A business analyst is accountable for whether something is true.

Those are different jobs with different failure modes. A product manager fails by building the wrong thing. An analyst fails by describing the world inaccurately, which then causes somebody else to build the wrong thing. The second failure is quieter and usually gets attributed to the first.

Once you see the split, most management questions answer themselves. You don’t evaluate an analyst on delivery velocity, because they don’t control delivery. You evaluate them on whether the picture they gave you held up.

What the profession’s own body says is changing

IIBA’s 2026 trends work argues that business analysis is becoming a strategic leadership discipline rather than a documentation function, and that as AI moves from an automation tool to a decision partner, the need for human judgment, ethics and oversight goes up rather than down. They also put outcome-driven alignment in place of output-focused delivery.

Two caveats. IIBA is a membership and certification body, so a conclusion that the profession is becoming more strategic is one they have an interest in reaching. And "the role is becoming more strategic" is what every professional body says about every profession every year.

I think this one is right anyway, for a reason they don’t lead with. If a model can produce a plausible requirements document in a minute, the scarce thing is no longer the document. It’s knowing whether the document is correct, and being willing to say when it isn’t.

There’s a line from their recent work on agentic AI that I keep coming back to: courage is becoming a business analysis skill, meaning the willingness to tell an organisation it isn’t ready while everyone is under pressure to move fast.

That’s a management problem more than a hiring problem. Courage isn’t really an individual trait in an organisation. It’s a function of whether the last person who said something inconvenient is still respected.

What the job actually is

Protecting access. Analysts can’t verify anything without the people who know. Those people are busy, senior, and usually someone else’s report. Getting your analyst thirty minutes with the person who actually understands the legacy billing logic isn’t administrative work you do around the edges of leading. It is most of the job.

Protecting the time to check. The pressure is always to accept the first answer. A good analyst wants to confirm it against a second source, and that takes a day nobody planned for. This is the same defence I described in discovery on a committed roadmap, applied to a team rather than a project. If you don’t defend that day, you’ll get analysis that is fast and occasionally wrong, and the wrongness will surface in build.

Making inconvenient findings survivable. This is the one that determines everything else. When an analyst discovers the plan rests on something false, what happens to them? If the honest answer is that they get a difficult meeting and a reputation for negativity, you’ll stop hearing about problems within about two months, and you won’t notice it happening.

Setting the standard for what counts as verified. Analysts left alone will each develop their own bar. Some will treat a stakeholder’s confident assertion as fact. Deciding as a team what counts as confirmed, and writing it down, beats any template.

Giving the discipline somewhere to go. If the only promotion path leads out of analysis, you’re training people to leave. Senior analyst, lead analyst, principal — the titles matter less than whether depth is visibly rewarded.

How I evaluate an analyst

Not on documents produced. Documents are the output, and after a year of generative tooling they’re the cheapest part.

I look at whether their picture held up. Six months on, was the process actually as described? Counting documents is the coverage mistake in another costume: easy to measure, easy to move, and silent on whether anything was true. Did the edge cases they flagged turn out to matter? Did something appear in build that they should have caught, and if so, was it findable at the time.

I look at what they escalated and how early. The strongest analysts I’ve worked with raise things while they’re still cheap, in a way that’s specific enough to act on.

And I look at whether people volunteer information to them. That’s not a soft signal. Analysts who are trusted get told the awkward truth about how the process really runs, and analysts who aren’t get told the official version, which is often fiction.

On the AI question

I get asked whether the role survives. The recruiter-facing version of this debate has largely settled on a reframe I agree with: the work that disappears is the assembly, and the work that remains is the framing, the judgment and the accountability for what an automated output actually claims.

I’d put it more plainly. Generating a requirements document is now easy. Knowing that requirement three contradicts a regulatory constraint nobody mentioned isn’t, and it’s the whole job.

What that does change is the shape of a team. If assembly is cheap, you need fewer people doing assembly and more people who can verify. That is a smaller, more senior team, and pretending otherwise to protect headcount does the people on it no favours.

The thing I’d tell a new BA lead

Your analysts will tell you what they think you can hear. Everything else follows from what you do the first time one of them tells you something you did not want to know.

Common questions

What is the difference between a business analyst and a product owner?

A product owner is accountable for whether something is a good idea and for the priority order. A business analyst is accountable for whether the description of the current state, the constraints and the requirements is accurate. The failure modes differ: one builds the wrong thing, the other supplies a false picture that causes someone else to build the wrong thing.

How do you measure business analyst performance?

Not by documents produced, which is the cheapest part of the job now. Look at whether their picture of the world held up six months later, whether the edge cases they flagged mattered, how early they escalated problems, and whether colleagues volunteer information to them, since people who are not trusted get told the official version rather than the real one.

Will AI replace business analysts?

It replaces assembly rather than analysis. Producing a plausible requirements document is now inexpensive; determining whether it is correct, and being willing to say when it is not, is the part that remains. The practical effect is a smaller and more senior team, since fewer people are needed for drafting and more for verification.

How do you manage a team of business analysts?

Protect three things: access to the people who hold the knowledge, the time to verify a first answer against a second source, and the safety to report an inconvenient finding. Also define as a team what counts as verified, since analysts left alone each set their own bar.

Is business analysis a step towards product management?

It can be, but treating it that way as a manager produces a team where the strongest people leave and the ones who stay feel they failed. Analysis is a discipline with its own senior levels, and if the only visible promotion path leads out of it, you are training people to leave.

What makes a good business analyst?

Accuracy that survives contact with delivery, early and specific escalation, and enough trust that people tell them how a process really works rather than how it's documented. The professional body's recent framing adds courage: the willingness to say an organisation is not ready when everyone is under pressure to proceed.

How large should a business analyst team be?

There's no ratio I'd quote, and the honest answer has changed. As drafting becomes cheaper, the useful team is smaller and more senior, weighted towards people who can verify rather than produce. Sizing a team on document throughput will overstaff it.