Overview
Business analysis is the discipline of working out what an organisation actually needs before anyone commits money to building it. The role spans requirements, process design, data investigation and stakeholder negotiation, and its shape varies enormously between a bank, a consultancy and a software product company. It is one of the more accessible routes into technology from a non-technical background, and one of the easiest to plateau in. This guide covers the real work, the progression, and how to avoid becoming a scribe.
What a Business Analyst actually does
The persistent misreading of this role is that it is documentation — someone writes down what stakeholders say they want and passes it on. Good business analysis is closer to investigation: stakeholders describe solutions rather than problems, describe the process they believe exists rather than the one that runs, and disagree with each other without realising it. Much of the job is sitting with the people who do the work, watching what they actually do, and finding the exceptions nobody mentioned because they seem normal to them. There is genuine drudgery — reconciling conflicting definitions of the same field across three systems, chasing sign-off, maintaining a traceability matrix nobody reads until an audit. The analysts who matter are the ones who reduce the scope of a project by discovering that most of it was unnecessary.
A typical week
- •Running a workshop or elicitation session where the real task is getting two departments to admit they define the same term differently
- •Mapping an as-is process and finding the undocumented workaround that the whole thing actually depends on
- •Writing user stories with acceptance criteria specific enough that a developer does not have to guess
- •Querying the data directly to check whether a stated business rule is what the system actually does
- •Walking a solution through with developers and testers, then reworking the parts that were ambiguous once questioned
- •Chasing a decision or a sign-off that is blocking work, and managing the expectations of the people waiting on it
Cohesyve for candidates
Thinking about a Business Analyst role? Find out where your skills stand today.
Run a role-specific simulation, get a scored report on your actual gaps, and follow a learning pathway built from them. Free to start, no card required.
The career path
Junior Business Analyst
0-2 yearsYou support a senior analyst: taking notes in workshops, documenting as-is processes, writing straightforward stories and doing the legwork on data checks. The main growth is learning the domain and the systems well enough to ask a useful question.
Business Analyst
2-5 yearsYou run your own elicitation, own the requirements for a workstream, and are trusted in front of business stakeholders alone. You start challenging requests rather than only recording them.
Senior Business Analyst
5-8 yearsYou take on ambiguous, cross-functional problems where the scope is not yet defined and stakeholders conflict. You are expected to shape the solution approach, not just specify it, and to mentor junior analysts.
Lead or Principal Business Analyst
8-12 yearsYou work at programme level across multiple teams, set analysis standards, and are involved before funding decisions are made. Influence shifts from documenting a solution to shaping which problems get invested in.
Head of Business Analysis or Product / Consulting leadership
12+ yearsEither you run the analysis practice — capability, standards, hiring — or you convert the domain expertise into product ownership, transformation leadership or consulting. Most senior BAs eventually branch rather than continue upward in title.
The skills that matter
Requirements elicitation
Stakeholders volunteer solutions, not problems. The ability to interview past the stated request to the underlying need is the single skill that separates an analyst from a note-taker.
Process modelling
A clear as-is and to-be model, in a notation the business can actually read, exposes handoffs, duplicated effort and unowned exceptions faster than any amount of discussion.
SQL and data investigation
Being able to check a claim against the data yourself, rather than raising a request and waiting a week, changes both your speed and your credibility. It is the highest-return technical skill for a BA.
Writing precise acceptance criteria
Ambiguity in a requirement gets resolved by whoever is closest to the keyboard, usually incorrectly and usually late. Testable criteria are where rework is prevented.
Stakeholder management
Requirements conflict because interests conflict. Surfacing a disagreement early and driving it to a decision is more valuable than producing a document that papers over it.
Domain knowledge
In payments, insurance, clinical or logistics work, the regulatory and operational detail is the job. Deep domain knowledge is what makes a BA hard to replace and is the main driver of seniority.
How to break in
- #1
Move from an operational role in the business you already know — claims, underwriting, finance operations, customer service. Domain knowledge is the expensive half and you already have it.
- #2
Learn SQL properly and use it in your current job. Being the person in the team who can answer a data question is the most common way people get pulled onto a project.
- #3
Volunteer for the analysis work on a change project at your current employer, even unofficially, so you have a real process map and a real set of requirements to talk about.
- #4
Take a recognised certification — the BCS or IIBA routes — if you are entering from outside; it will not impress a hiring manager on its own but it gets a non-obvious CV past a screen.
- #5
Learn a modelling notation and a documentation toolchain properly so a work sample looks professional rather than improvised.
- #6
Apply to consultancies and graduate schemes if you are early career; they hire on aptitude, train the method, and give you exposure to several domains quickly.
What drives pay
Compensation varies too much by country, sector and company size for a single figure to be useful. These are the factors that actually move it.
Depth of domain expertise, particularly in regulated areas where a wrong requirement carries legal or financial consequence
Technical range — analysts who can query data, read an API contract and reason about integrations sit in a different bracket from those who only document
Whether you operate at project level or are trusted at programme and pre-investment level, where the decisions are larger
Sector and contracting model, with consultancy, contract and regulated-industry work priced differently from in-house permanent roles
Proximity to the commercial outcome — analysts on revenue-affecting change are valued above those maintaining internal process documentation
Where demand is heading
Demand is steady rather than fashionable, and it holds up because large organisations do not stop changing their systems. The nature of the role has narrowed at one end and deepened at the other: purely documentation-focused analysis is being absorbed into product and delivery roles and is increasingly automated at the drafting stage, while analysts who combine domain depth with data capability are consistently hard to hire. Regulated sectors, ERP and core-system migrations, and data platform programmes remain reliable sources of work. The honest read is that the title is not at risk but the narrow version of the job is, and the defence is technical range plus domain depth.
Roles this transfers to
Product Owner
Nearly the same skill set applied inside a delivery team, with backlog authority added. The most common next step for a BA in an agile organisation.
Data Analyst
Shared SQL, data modelling and stakeholder-question skills. The gap is statistical reasoning and visualisation rather than domain understanding.
Systems Analyst
Same investigative method pointed at systems and integrations rather than business processes. A natural move for BAs who gravitate to the technical detail.
Management Consultant
Process analysis, stakeholder interviewing and structured problem-solving are directly reusable. The gap is commercial framing and client-facing pace.
Common mistakes
Recording what stakeholders ask for instead of investigating why they asked for it
Writing requirements that cannot be tested, so ambiguity is discovered during UAT rather than during analysis
Producing volume — enormous documents that nobody reads — as evidence of thoroughness
Avoiding the data and relying on what stakeholders believe the system does
Staying in one system or one project type for so long that the expertise stops transferring to another employer
Treating conflicting stakeholder requirements as something to smooth over in wording rather than escalate for a decision
Frequently Asked Questions
Do I need to know how to code?
You do not need to write applications, but SQL is close to mandatory in most serious BA roles, and being comfortable reading an API specification or a data model materially widens the jobs you can take. It is the difference between describing a system and understanding one.
Is a BCS or IIBA certification worth doing?
It helps most when you are moving in from outside the field and need a CV to survive a screen, and it gives you shared vocabulary. It carries little weight against demonstrated project experience, so treat it as an entry aid rather than a career step.
What is the difference between a business analyst and a product owner?
A BA is typically accountable for understanding and specifying the need; a product owner is accountable for the backlog and for deciding what gets built next. In many organisations one person does both, which is why the titles blur, but the authority differs.
Is the role at risk from automation?
The drafting and documentation portion is genuinely being compressed. The investigative portion — noticing that two departments define a term differently, or that the documented process is not the one being run — is not, because it depends on access to people and context. Weight your development accordingly.
How do I tell whether my analysis skills are at the level a role expects?
Interviews for this role often test elicitation and precision through a scenario, and it is difficult to judge your own answers. Running a scored business-analysis simulation against a live job description shows you where you lose marks; Cohesyve includes three free assessments with a full report and a learning pathway.
Interview prep
Every stage of the Business Analyst hiring process, and how to prepare →
Practice
What a Business Analyst assessment tests, and how it's scored →
Explore another career
Cohesyve · Practice for candidates
Practise a Business Analyst assessment before the real one
Run the same AI job simulations companies use to evaluate applicants. You get a scored report showing where you're strong and where you're not, plus what to work on.
3
free assessments
$0
no card required
Full
scored report every run
Every
question type included
3 free assessments · No card required · Pro from $16/mo
For hiring teams
Hiring for a Business Analyst role? See how your applicants perform before you spend interview time.