The same job title, two different jobs
I read 201 business analyst postings. Fifty-nine of them never mention business analysis.
Chad Wambles · November 2026
I collected every remote business analyst posting LinkedIn showed me over a fifteen day window. Two hundred and one of them. Then I wrote a parser that reads each one and records which of forty-five professional capabilities it actually asks for, from writing user stories to querying data with SQL to running a UAT cycle.
I was looking for specializations. The common advice is to pick a lane: become the data BA, or the process BA, or the systems BA. I wanted to know how big each lane was.
That is not what the postings say.
What the market asks for
Start with the straightforward part. Across all 201 postings, here is what comes up most.

Nothing surprising. Process improvement and elicitation at the top, SQL in 35 percent of postings, dashboards in a quarter. If you have read business analyst job descriptions before, this is roughly the shape you would expect.
The surprise is what happens when you ask which of these travel together.
There are no specializations
I clustered the postings on their capability profiles, then tested whether the clusters were real. That second step matters more than the first, because clustering always returns clusters. Give an algorithm random data and ask for four groups and it will hand you four groups.
So I built a null: shuffle the data while holding every posting's total number of capabilities fixed and every capability's overall frequency fixed. That destroys which capabilities travel together and changes nothing else. Then cluster the shuffled version the same way and see whether the real data separates any better.
It does not. At three groups, four groups, five groups, with k-means, with Ward linkage, with average linkage, on raw counts and on length-normalised profiles, the real postings cluster no better than shuffled ones.
There is no data BA cluster. There is no process BA cluster. The advice to pick a lane is not supported by what employers write down.
What is there instead
One division does survive, and it is sharper than any specialization would have been.
Eight of the forty-five capabilities are the recognizable core of the discipline: writing user stories, writing acceptance criteria, planning UAT, maintaining traceability, refining a backlog, running sprint ceremonies, eliciting requirements, and mapping processes. Count how many of those eight each posting names, and the distribution does something distributions do not usually do.

Fifty-nine postings name none of the eight. Not one. No stories, no acceptance criteria, no UAT, no elicitation, no process mapping, nothing. Twenty-eight postings name six or more.
The middle, where most postings should sit, is empty. Three of eight should hold about thirty-seven postings and holds eighteen.

Employers either describe business analysis as a craft with named deliverables, or they do not mention it at all. Very few do it halfway.
It is not just that some postings are longer
The obvious objection is that detailed postings name more of everything and vague ones name less, so of course the counts spread out.
That is what the null controls for. It holds each posting's total capability count exactly where it was. A posting that named nine capabilities still names nine in every shuffle. The only thing that changes is which nine. The bundle still clumps, with the spread running roughly twice what chance gives.
So given how much a posting says, which things it says is not random. The eight travel as a unit.
The two groups differ on things outside the eight
There is a trap here I nearly walked into. If I split the postings by how many of the eight they name, and then show the two groups differ on those eight, I have proved nothing. That is arithmetic.
The real test is the other thirty-seven capabilities, which played no part in defining the groups. Seven of them still separate the two groups after correcting for having run thirty-seven tests.

Acting as product owner shows up in 57 percent of the craft-heavy postings and 5 percent of the thin ones. Modelling current and future state, 36 against 5. Documenting business rules, 32 against 4. Source-to-target mappings, 25 against 2.
Across everything, craft-heavy postings name an average of 14.3 capabilities and thin ones name 4.7. These are not the same document written at different lengths. They are descriptions of different jobs.
What this means if you are applying
The posting tells you which job it is, and it tells you in the first screen of text.
If it names stories, acceptance criteria, UAT and a backlog, someone who understands the discipline wrote it, and they will interview you on it. Prepare accordingly, and expect them to want roughly a year more experience than the other group asks for.
If it names none of those, the title is doing the work and the job underneath could be anything. That is not automatically a bad job. Plenty of them are at real companies with real budgets. But you are applying to a description that has not told you what the work is, and you should find that out before you invest much in the application.
What you should not do is sort these postings into specializations, because the postings do not sort that way. Sort them by whether the employer can describe the job.
What I am not claiming
This is one search. One keyword, remote roles only, a fifteen day window, and LinkedIn's own salary band filter applied. Postings outside those filters may look different.
Pattern matching is not reading. A capability counts when a posting uses recognizable language for it. A posting that implies UAT without naming it reads as a zero. I published every pattern so you can judge them yourself.
I left pay out of this. I had a result about it. Only ten of the twenty-eight craft-heavy postings disclose a salary, which is not enough to say anything, so I am not saying it.
Two hundred and one postings is small. The split is strong enough to show up clearly at this size, but the fine detail inside each group is not something I would lean on.
What I used
Everything that produced these numbers is published. The parser, the forty-five capability definitions with the exact pattern behind each one, and the statistical tests are in a repository you can run yourself. There are no language models anywhere in it. It is pattern matching and arithmetic, which means you can check every number rather than taking my word for it.
The one thing not published is the raw posting text, which belongs to the employers who wrote it.
Code and capability definitions: github.com/chadwambles/jobfit-engine



Comments