What a Business Analyst Really Does

Every quarter, in interviews, I get asked the same thing: ‘So, what exactly does a business analyst do?’ It’s not juniors asking. It’s HR. It’s friends from other professions. It’s my mom. Every time, I catch myself pausing for the first five seconds to choose my words. Because ‘formalizes requirements and coordinates stakeholders’ isn’t an answer. It’s noise.

The real answer is shorter and cruder. A Business Analyst, or just BA, is the person who stands between what the business wants and what development can deliver. They translate from one language to another, ensuring no one loses a week to rework. Not an architect. Not a project manager. Not a meeting secretary – though it sometimes looks that way from the outside. The difference isn’t apparent on a resume, but in one question: what do you do when business and development describe the same task in two different ways? If you have a concrete answer, you already understand the profession better than half the textbooks.

What a BA Really Does Every Day

Forget the job description. Here’s what a workday actually consists of.

You’re on a call. The client describes a problem using words that mean nothing to development — ‘make it more convenient.’ Your job is to turn this into three concrete questions. And not leave the call until you get the answers.

You read data. Not like a BI analyst – but to verify if what the client says matches what’s actually happening in the system. Often, it doesn’t.

You write a user story. A developer will read it in two weeks, without the context of the conversation. It must be understandable without you there.

You say ‘no’ to a new feature. Even if it just seemed brilliant on the call. Because it doesn’t solve the original problem – it solves the problem of whoever spoke the loudest.

A BA isn’t someone who knows the answer. It’s someone who first notices that the question is wrong.

Europe and North America Approach the Profession Differently

IIBA is the profession’s main certification standard. It emerged in Toronto in 2003. This isn’t a European story. North American. IIBA’s top certification, CBAP, requires a minimum of 7500 hours of actual business analysis experience over the past 10 years – meaning it validates what you’ve already been doing for years. The door’s closed to newcomers. You get in through ECBA instead – no experience needed there, but 21 hours of formal training over the past 4 years are required.

Europe has its own system – and not just one. In the UK, BCS (The Chartered Institute for IT) issues the International Diploma in Business Analysis: four modular exams – two foundational, one knowledge-based, one practical – plus an oral exam at the end. No minimum work experience is needed to start. Germany has a different story: IREB (International Requirements Engineering Board), founded in 2006, certifies not the entire BA role but specifically Requirements Engineering – through CPRE. The Foundation Level also has no experience requirements.

Three organizations – three different entry points. IIBA verifies accumulated experience. BCS and IREB build knowledge from scratch through exams, without prior work experience. Formally, there’s more than one path.

But beyond certifications, the difference is practical. In my experience, on the European market, employers are much more interested in a portfolio of real case studies than a certificate line on a resume. A certificate isn’t a pass. It’s confirmation that you already have the skills.

How People Actually Become Business Analysts

Textbooks paint one path: diploma, course, certificate, junior vacancy. In practice, there are more paths.

They come from business – like me, from the banking domain, without a single line of formal BA education at the start. They come from QA and technical support – people who have already talked to both development and unhappy users. They come from project management: a PM gets tired of holding requirement details in their head and consciously narrows their focus. They come through courses and self-study – the most vulnerable path. A course provides techniques. But it doesn’t give real-world call experience.

What all these paths have in common isn’t a diploma. It’s the same moment: someone once asked them to sort out confusion between departments. And they enjoyed sorting it out more than doing the actual work that created the confusion.

How to Know if it’s for You

Not a 20-question quiz with scores. Three honest markers.

You’re more interested in the question than the ready-made answer. Defining the task excites you more than implementing it. In this profession, definition is the main work.

You’re comfortable sitting in uncertainty. A requirement rarely arrives ready-made – it comes as three contradictory wishes. Your work begins with not panicking.

It’s more important to you that the solution is clear to all participants than that it is yours. Authorship of the idea isn’t the point. The best BA outcome is when the team is confident they all came up with the solution together.

Later in the blog, I’ll break down each entry path separately – what specifically to learn if you’re coming from QA, and what not to waste time on if you’re coming from business. It’s worth starting with one honest question to yourself: are you more interested in the question than the answer? If yes, keep reading.