What Does a Business Analyst Actually Do?
Forget the job descriptions. Here’s what the work actually looks like on a Tuesday afternoon.
Search “what does a business analyst do” and you’ll get some version of this:
“A business analyst acts as a liaison between stakeholders and technical teams to elicit, document, and validate business requirements in order to deliver solutions that align with organisational objectives.”
Technically accurate. Completely useless.
If you’re considering this career—or you’re mid-transition and still not entirely sure what you’ve signed up for—you deserve a cleaner answer than that. So here it is: the honest, jargon-light version of what a business analyst actually does, day to day, in the real world.
The One-Line Version
A business analyst figures out what a business actually needs and communicates that clearly enough for something to get built, changed, or fixed.
That’s it. Everything else is a detail.
Business Analysts are DOCTORS for the business
The Problem With “Requirements”
The word you’ll hear most in this field is requirements. As in: gathering them, documenting them, validating them.
But requirements don’t exist in the wild. Nobody hands you a neat list of what needs to happen. What you actually get is:
- A manager who “…needs a new system” but can’t tell you why the current one isn’t working
- A process that’s been done the same way for eleven years because nobody has questioned it
- Three stakeholders with three different ideas of what the end result should look like, none of whom have spoken to each other
- A technical team ready to build something—just waiting for someone to tell them what
Your job is to walk into that mess, make sense of it, and turn it into something actionable and profitable.
That’s not a glamorous description. It’s an accurate one. And for the right kind of person—someone who genuinely likes untangling complicated situations (like me)—it's also deeply satisfying.
What a Real Tuesday Looks Like
(…because the Mondays are not even anything to write about, YET!)
Here’s what my day could look like in a discovery phase of a project.
9:00am — Review notes from yesterday’s discovery session with a department head, usually from the notes made by the AI who attended the meeting. She told you the current invoicing process “takes too long.” You write down what she said, then write down what you think she actually meant, because they’re not the same thing. You identify three follow-up questions before you can move forward.
10:30am — You sit in on a meeting between the IT team and the finance department. They’re talking past each other. The developers keep asking about API integrations; the finance team keeps talking about month-end reports. You’re the only person in the room who understands both sides well enough to translate. You do that, quietly, and the meeting starts making progress.
12:00pm — You update a process map you started last week. It shows how an invoice currently moves through the business — every step, every handoff, every place it gets stuck. You’re building what’s called the AS-IS picture: what exists now, before anything changes.
2:00pm — You write up a set of requirements. A structured document that says, "Here is what the new process needs to do, here is who it needs to serve, and here are the constraints it has to work within." You write it in plain English because the people who need to approve it are not technical.
Get Elizabeth "Lady Bhie" Ekenimoh’s stories in your inbox
Join Medium for free to get updates from this writer.
Now you sit for lunch and keep getting prompts and notifications because a developer is returning tickets to you for a bug raised on a previous project where we have tested and are almost going live.
4:00pm — A stakeholder emails to say they’ve changed their mind about one of the requirements. You update the document, flag the impact of the change, and send a summary to the project lead.
That’s a business analyst’s day. Part detective, part translator, part diplomat, part writer. Everyone’s friend and enemy at the same time.
The Skills That Actually Matter
The job descriptions will tell you to know Agile, BPMN, JIRA, Confluence, Visio, SQL, and seventeen other things.
Some of that is useful. None of it is what separates good BAs from average ones.
What actually does is:
- Asking better questions. Most people accept the first answer they get. A good BA knows that the first answer is usually a symptom, not the root cause. “Why does that take so long?” is a more valuable question than “how long does that take?”
- Listening properly. Not waiting to speak. Not mentally drafting the next question. Actually hearing what someone is telling you — including what they’re not saying directly.
- Writing clearly. A requirements document nobody can understand is not a requirements document. It’s a liability. The ability to write precisely, without jargon, without ambiguity, is the single most practical skill you can build.
- Managing complexity without panicking. Projects get messy. Stakeholders contradict each other. Scope changes. Timelines shift. A BA who needs everything to be neat before they can move forward will not last long. The ability to sit with uncertainty while still making progress is what gets things done.
What being a BA is Not
Now that we have added some flesh around what a BA does, let’s talk about what we don’t do.
- It’s not a purely technical role. You don’t need to code. You may work closely with developers, but your job is to understand the problem clearly enough to brief them well—not to build the solution yourself.
- It’s not a project manager role. There’s significant overlap, and in smaller organizations the lines blur. But a PM manages delivery—timelines, budgets, and risks. A BA manages understanding—clarity, requirements, and alignment.
- It’s not a passive role. Some people come to BA from administrative backgrounds and expect it to be largely reactive—respond to requests, document what you’re told, and pass it on. It’s not. The best BAs shape problems, challenge assumptions, and push back on requirements that don’t make sense. You’re an active participant in how solutions get designed, not a scribe.
Why People Who’ve Never Done It Before Are Often Good At It
A lot of what makes a great BA has nothing to do with business analysis training.
It’s the teacher who knows how to read a room and adjust their explanation on the fly. The nurse who has to extract accurate information from a patient who isn’t sure what they’re describing. The retail manager who’s been solving problems with incomplete information since their first shift.
The formal frameworks—the methodologies, the documentation templates, and the industry vocabulary—those can be learned in months. The underlying capabilities that make the work possible take years to develop.
You may have already done the hard part without realizing it.
So, Is This the Right Career for You?
If you finish reading this and think that sounds exhausting, it might not be.
But if you finish reading this and think that sounds like what I’ve been doing for years but with a proper name for it, keep going.
The people who thrive in business analysis are the ones who are genuinely curious about how things work, who find it satisfying to bring clarity to confusion, and who don’t mind being the person in the room who asks the obvious question nobody else wanted to ask.
If that’s you, you’re already halfway there.
Keep reading…
