Business analyst job description

Two different jobs share this title. One turns business requests into something a team can build. The other writes SQL and produces reporting. Both call themselves business analyst, both will apply to your advert, and hiring the second when you needed the first leaves requirements unowned for a quarter before anybody names the problem. Below is a description for the first, and the screening that goes with it.

The job description

We are looking for a business analyst who can sit between a business owner who knows the outcome they want and a team that needs it specified. You will own requirements from the first conversation through to acceptance.

The remit

Elicit requirements from people who have a business to run and limited patience for meetings
Document current-state process including the workarounds nobody volunteers
Write requirements and acceptance criteria that engineering can estimate and argue with
Run user acceptance testing and own the defects that turn out to be misunderstandings
Maintain one definition of shared terms across teams that currently use them differently

What the job needs

Experience specifying work that was actually built, not only analysed
The ability to run a session where two stakeholders disagree and leave with a decision
Enough data literacy to check a claim about volume before designing around it

Signals we weight heavily

You have replaced a request with a better problem statement
You have written the shorter document deliberately
You have sat through acceptance testing and owned what came back

What a business analyst is actually accountable for

The deliverable is a document, which is why the role gets measured in documents. The outcome is that what gets built is what the business needed, and that the people who asked for it recognise it when it arrives.

Turning a request into a specification that survives the build without a daily stream of clarifying questions
Finding the process the organisation actually runs, which is rarely the one written down
Saying that a request does not solve the problem sitting behind it, and being listened to
Judging when a requirement is specified enough, between the two failure modes of ambiguity and over-specification
Holding two departments who describe the same thing differently to one definition

Four ways a business analyst hire looks right and is not

Every one of these passes a resume screen. Ladders eye-tracking study timed the average initial scan at just 7.4 seconds, which is long enough to check the four signals below and not long enough to check anything that would contradict them.

Looks right

A portfolio of thick requirements documents

Document volume measures effort, not clarity. A sixty-page specification that nobody on the build team read is worse than eight acceptance criteria an engineer argued with, because the first one creates the impression that the thinking was done. Ask which document was contested and by whom.

Looks right

Deep domain expertise in your industry

Domain fluency buys speed in month one and costs you in month six. The analyst who knows exactly how the industry currently works is the most likely to specify the existing broken process into a new system without asking why any of it exists. Weigh domain heavily only where the regulation genuinely takes a year to learn.

Looks right

Business analyst experience at a consultancy or systems integrator

In consulting, a requirement is a contractual deliverable, signed off at a milestone, after which it is somebody else who lives with it. In-house it is a live negotiation with people you will see again next sprint and who are entitled to change their mind. Strong consulting analysts make the transition, but the sign-off reflex takes a while to unlearn.

Looks right

SQL, dashboards and reporting on the same resume

The title covers requirements work and analytics work, and they are separate jobs with separate populations. A candidate strong at both is rare, and a candidate who is strong at reporting will happily accept a requirements seat and quietly gravitate back toward the data. Decide which job you are filling before the advert goes out.

What to ask for evidence of instead

Four questions, and what the answer actually tells you. Take these into your own process whether or not you ever talk to us.

Describe a requirement you got wrong, and the moment you found out.: What it tells you: Whether they were still around when the work landed. Analysts who hand over at sign-off will describe defects abstractly. The ones you want can name the acceptance session where it surfaced and what they had failed to ask.
Tell me about a process you documented that turned out not to be the process people actually followed.: What it tells you: Every organisation runs on undocumented workarounds, and finding them is the craft of this role. Listen for how they found out. The answer is almost always that they watched somebody work rather than interviewing them.
When did you tell a stakeholder that what they asked for was not what they needed, and how did that land?: What it tells you: Separates order takers from analysts. You are listening for the alternative they offered and whether they had the standing to be heard, which is partly about them and partly about how the previous company treated the role.
How do you decide a requirement is specified enough to hand over?: What it tells you: There is no correct answer, only a considered one. Candidates who say they specify everything have never worked with a team that can fill gaps, and candidates who say the team figures it out have never been on the receiving end of that.

How Continuity1 runs this funnel

The screening above is the job. These are the numbers it produces when a function owns it end to end, set against the published benchmarks for the same market.

1 in 3: Shortlisted candidates you meet who become the hire; Aligned engagements run nearer 1 in 2, distant ones nearer 1 in 10. The market takes about 180 applicants to make one hire, and that sifting lands on your team rather than ours.; Continuity1 tracked engagements
~3: Interviews your team sits in, per hire; Ashby puts technical roles at 17.6 interviews per hire across the whole process, up 52% since 2021. The rest of that load sits with the function, not with you.; Ashby talent-trends report
1 in 9: Accepted offers that ghost before joining; Indian employers report nearly 4 in 10 offers dropped. We lose 1 in 9.; nasscom community
95%: Offers that close inside your stated band; 20 of the last 21. A flat fee earns nothing from an inflated offer; a percentage of CTC earns more.; Continuity1 tracked engagements

Every brief becomes a success profile before sourcing starts, calibrated with the people who will manage the role. That calibration is the step most hiring skips, and it is why a shortlist either matches the job or matches the job advert.

You review a scored shortlist and make the calls. The filtering never lands on your calendar.

Share a role See the workings and the citations

Questions teams ask

Business analyst or product manager?

A product manager decides what is worth building and answers for the outcome. A business analyst makes sure what has already been decided is specified properly and works when it lands. If nobody in your company is doing the first job, a business analyst will not fill the gap, and they will get blamed for a prioritisation vacuum they were never given the authority to close.

Do we need someone from our domain?

Less often than the advert implies. Insist on domain when a regulatory or safety constraint genuinely takes a year to learn. Otherwise hire the person who asks the better questions, because the fastest way to freeze a bad process into new software is to hire somebody who already believes it is the right one.

Should the business analyst write user stories, or should engineering?

Whoever writes them, the acceptance criteria have to be argued over with the people building the thing rather than handed to them. The failure mode is a beautifully formatted backlog nobody ever contested, which reads as progress and produces rework.

How do we test for this in an interview?

Describe a real request from one of your stakeholders, deliberately badly, in two minutes, and then stop talking. The entire test is what they ask next. Candidates who start proposing a solution have shown you exactly what they will do on the job.