The role that sits at the intersection of technology, process, and people — and why it matters more now than ever.
"A Business Analyst's job is to close the gap between what an organisation thinks it needs and what will actually solve the problem."
— The Business Analyst Blueprint, by Joanne JonesThe job title doesn't tell you much. Job descriptions vary wildly. And the people doing it well rarely explain what they actually do — they just do it. Here's the honest version.
Every organisation builds the wrong thing at some point. A new system nobody uses. A process redesign that made things slower. A digital transformation that fixed the visible problem and created three invisible ones. A Business Analyst, properly positioned and empowered, is how you avoid that.
The role sits at the intersection of technology, process, and people. It requires forming views, testing assumptions, and occasionally telling a room full of people that what they're asking for won't achieve what they think it will. That's analysis. Everything else — the process maps, the workshops, the user stories, the requirements documents — is in service of that one function.
The most common mistake in early BA careers is treating every stakeholder request as a valid requirement. If someone says "I need a report showing all customer activity for the last 30 days," the BA response is not to start documenting the report spec. It's to ask: what decision are you trying to make with that information, and is this the best way to get it? A BA who asks that question is doing analysis. One who doesn't is just writing things down.
The activities that make up the work fall into a recognisable set. Here's a realistic mid-level BA week.
More varied than most roles. More relational than most people expect. Requires a kind of thinking that's different from both the technical work around you and the management work above you.
The edges of the role are where a lot of confusion and frustration happen. Here's what to get straight early.
A project manager owns the plan, timeline, budget, and overall delivery. A BA owns the understanding of what needs to be delivered and why. Conflating them usually means one of them is done poorly.
Your job is to define what the solution needs to achieve — not to decide how it's built. "The system must allow users to approve requests without leaving the dashboard" is a requirement. "We should use a modal pop-up widget" is a design decision that belongs to the product or technical team.
This misconception does the most damage. Documentation is a tool. The value of a requirements document is the shared understanding that came from producing it — not the document itself. A BA who's very good at writing but not at thinking and conversations is a very expensive typist.
Some people come in believing their job is to be an objective recorder — capturing what stakeholders say they want without filtering or challenging it. That is not analysis. Analysis requires forming views, testing assumptions, and sometimes telling a room that what they're asking for won't achieve what they think it will.
Depending on where you work and what you focus on, your day-to-day experience as a BA can look remarkably different from someone else with the same job title.
Something significant has shifted in the last few years. The BA skill set has become one of the most powerful foundations a person can build — not because it wasn't useful before, but because the world has changed around it.
"You are not learning how to fill a job. You are learning how to think — and thinking clearly about real problems is the most transferable, compounding, AI-resistant skill a person can build."
— The Business Analyst Blueprint, by Joanne JonesBA Hub gives you the tools, the projects, and Billie — a BA tutor who knows every framework and every interview question type. Find out where you stand in five minutes.