If you type "Business Analyst" into Google, you quickly land on definitions full of jargon. The BA is supposedly the link between the business and the tech side, the person who writes the functional specifications or bridges the gap between teams.
All of that is true, but it only tells part of the story.
A Business Analyst is, first and foremost, someone who tries to understand the problems an organization faces and helps find the right solutions.
In practice, they work with business teams, such as accounting, HR, sales or operations, but also with technical teams, such as developers and integrators.
They often sit between these different worlds. They have to understand everyone's constraints, ask the right questions, analyze needs and help teams move in the same direction.
But the role isn't just about translating requests from one side to the other. It also means questioning assumptions, exploring different options and helping verify that the planned solution really addresses the original problem, in collaboration with the other stakeholders.
And that's where the job gets interesting.
The real work starts before the solution
A project can run into serious trouble when the need hasn't been properly understood, questioned or validated upfront.
Imagine a team asks you to build a dashboard, automate an email or add a field to a form.
Your first reaction might be to start thinking straight away about how to deliver the request.
But is that really the right approach?
These requests often describe a solution someone has in mind. They don't always say which problem needs to be solved.
That's exactly where the Business Analyst comes in.
Why is this dashboard needed? What decision should it help make? Who is going to use it? How often? What problem are we facing today?
By digging a little, you may find that the dashboard doesn't address the real need, that the information already exists somewhere else, or that a process problem explains the situation.
The BA tries to understand what's behind the initial request. They can then help identify a different solution, sometimes simpler, better suited or cheaper.
It's a bit like going to the doctor. You don't prescribe a treatment without trying to understand the symptoms and where they come from.
In a project, this analysis phase lets you step back before diving into delivery.
Finding the right solution, not just the one that was asked for
The BA's work doesn't stop at understanding the need.
They also take part in thinking through the possible solutions.
That can mean mapping an existing process, exploring a tool already available on the market, comparing a custom build with an off-the-shelf solution, or weighing the expected benefits against the costs and constraints.
Sometimes you have to challenge certain habits, test several hypotheses against each other, or accept that the first idea isn't the best one.
To do this properly, you need to understand the business context, the technical constraints and the organization's goals.
The BA isn't there to automatically approve every request. They help make sure we're tackling the right problem, in the right context, with a relevant solution.
This mix of business, analytical and interpersonal skills is, in my experience, what makes the profile interesting and sometimes hard to find.
Common misconceptions about the job
"The BA is the one who writes the specs"
Functional specifications are part of the job, but they're only a way to formalize what has been understood and decided.
Before writing, you have to talk, observe, analyze, ask questions and sometimes explore several possibilities.
A well-written spec doesn't guarantee that the original need is relevant. You can perfectly document a bad idea.
So the point is to understand before you formalize.
"The BA is a project manager who doesn't manage the schedule"
The two roles are complementary, even if their responsibilities can overlap depending on the organization.
The project manager generally focuses on coordination, schedule, budget, risks and resources. The Business Analyst focuses more on understanding the need, analyzing processes and defining the expected solution.
In reality, the boundaries aren't always that clear. Some companies give several responsibilities to the same person, while others have teams and clearly distinct roles.
So the problem isn't that one role matters more than the other. It's mostly that a project can stay on schedule without anyone having really taken the time to check whether it's meeting the right need.
"The BA spends their days in Excel"
Personally, Excel makes up about 1 to 2% of my working time, and I mostly use it when certain constraints force me to.
That's my experience, not a rule that applies to every Business Analyst.
Excel can actually be very useful for analyzing data, comparing scenarios or testing hypotheses. The problem isn't using a spreadsheet, it's reducing the job to that tool.
The core of the work lies more in conversations, facilitation, process analysis and understanding needs.
A BA can spend time in Excel without it being a problem. On the other hand, producing spreadsheets without understanding the business problem they're meant to answer risks missing the point.
"The BA is just a stepping stone to product management or project management"
The job can indeed open doors to other roles. But it can also be a specialty in its own right.
Understanding needs, analyzing complex situations, facilitating conversations between very different people and connecting business challenges to technical constraints takes real expertise.
It's not simply a step to get through before doing something else. For those who like understanding problems, exploring possibilities and helping build relevant solutions, the job can be a full career path in itself.
What does a day in the life of a BA look like?
There's no such thing as a typical day.
You might start with a workshop with a business team, continue with the analysis of a process, explore a tool that could meet a need, then finish by preparing specs or clarifying a few points with the developers.
Some days are very focused on conversations. Others call for more research, thinking or documentation.
This exploratory side is what I find particularly interesting about the job.
It's not just about carrying out a request, but about understanding what's going on, identifying the possibilities and working out what could work in a given context.
That can mean discovering a new tool, testing several scenarios, reading documentation, browsing forums or reading feedback from other users to understand a solution's limits.
The BA sometimes has to play detective.
And the work doesn't always follow a straight line. A demo can raise new questions. A workshop can reveal that the need is more complex than expected. Exploring a tool can show that a feature already exists and that custom development isn't needed after all.
You then have to revisit some assumptions, adjust the analysis and sometimes rework the specs.
It's stimulating, but it can also be tiring. You regularly jump from one topic to another, with very different people, constraints and levels of detail.
One thing is certain: if you like understanding how things work, the job is rarely boring.
Why is the BA's role strategic?
An IT project can succeed technically and still miss its goal.
The developers may have built exactly what they were asked for, on time and according to the specs. Yet if the original request didn't address the real need, the result is likely to disappoint.
That's not necessarily a technical problem. It can be a problem of analysis, understanding or decision-making.
The Business Analyst helps reduce this risk by clarifying objectives, questioning assumptions and helping stakeholders make better-informed decisions.
Of course, they can't guarantee a project's success on their own. That also depends on the decisions made, the collaboration between teams, the resources available and many other factors.
But solid analysis can prevent you from spending time and resources on a poorly suited solution.
As organizations adopt new digital tools and automate their activities, this ability to understand problems and connect needs to solutions remains essential.
And with AI, what happens to the job?
Artificial intelligence can already speed up some of a Business Analyst's tasks: summarizing documents, structuring information, preparing a first draft of specs or exploring possible solutions.
But quickly producing a convincing document doesn't mean the need has been correctly understood.
Say a team asks an AI to write the specs for a new tool. The result may be clear, well structured and perfectly presentable. Yet if nobody has questioned the original request, the AI may simply formalize an unsuitable solution faster.
So the BA's role isn't only about producing deliverables. It's also about understanding the context, challenging assumptions, facilitating decisions and checking that proposals make sense in the reality of the organization.
AI can become a real lever to save time and explore more possibilities. But you still need to know when to use it, why, and how to evaluate what it produces.
That's precisely one of the topics I want to explore further: how to concretely integrate these tools into a Business Analyst's day-to-day work, without losing sight of the quality of the analysis and the relevance of the solutions.
Going further
The Business Analyst job is much broader than writing specs. It takes curiosity, rigor, strong analytical skills and a real understanding of both business and technical challenges.
In upcoming articles, I'll come back to the differences between being a BA at a startup and at a large company, the impact of AI, and the tools that can make our daily work easier.
Subscribe to the newsletter to regularly receive analyses, practical tools and ready-to-use prompts for your day-to-day work.