What a Business Analyst Actually Does

Most people trying to become a business analyst cannot actually describe what one does, and that is not their fault. It is one of the most misunderstood roles in the whole of tech. The title comes in a hundred versions: business analyst, systems analyst, product analyst, functional analyst, and the job descriptions are so vague they could mean almost anything. So people picture the surface: piles of documentation, back-to-back meetings, something to do with spreadsheets. All of that appears in the job at times, and none of it is the job. If you are trying to break in, the first thing worth having is a clear, honest picture of what you are actually walking toward.

The job, underneath everything

Here is the one-line version I wish someone had given me early. A business analyst stands between the people who have a problem and the people who can build a solution, and makes each make sense to the other. That is it, underneath every framework and template you will ever learn. The business side usually knows something is wrong, or something is needed, but cannot express it in a way a technical team can act on. The technical side can build almost anything, but needs to know exactly what to build and why. The analyst is the bridge: the person who turns a vague business need into something clear enough to build, and turns technical realities back into language the business can make decisions with.

In practice that means understanding a problem deeply before anyone rushes to build, asking the questions that surface what people actually need rather than what they first ask for, writing it down clearly enough that nobody misreads it, mapping how work really flows and where it breaks, helping people who disagree arrive at what should be built, and checking afterwards that the thing that got built solved the real problem. Notice how little of that is about any single tool. The job is mostly clear thinking and clear communication, aimed at a technical world.

An example makes it concrete. Imagine a sales team that keeps missing its targets and asks for a shiny new tool to fix it. A weaker response simply builds the tool. An analyst goes and understands the problem first, and often finds the tool was never the real issue: perhaps leads are slipping because two systems do not talk to each other, or because nobody can see which deals need attention today. The analyst turns a vague ask, we need a new tool, into a clear and true statement of the actual problem, and only then helps decide what to build. That translation, from what people first say to what they genuinely need, is the heartbeat of the whole job.

The work also stretches across far more settings than the title suggests, which is part of why so many different people find a home in it. The same core job appears whether you are helping a bank redesign how it approves loans, a hospital improve how patient records flow, or a software team decide what to build next. The domain changes and the tools change, but the shape holds: understand the problem, define what good looks like, and make sure the right thing gets built. Learn the craft once, and you can carry it almost anywhere.

The skills that actually matter

There are two opposite myths about this role, and the truth sits between them. The first myth says you must be deeply technical, practically a developer. The second says the opposite, that a BA is a purely business person who keeps well away from the technology. Both are wrong. You do not need to write code, but you do need to be genuinely comfortable around technology, curious about how systems work, and able to talk to builders as a peer rather than a stranger.

The skills that carry the job are more human than technical: curiosity and the instinct to ask a better question, clear writing and clear speaking, comfort sitting inside a messy problem without panicking, the patience to understand something fully before solving it, and enough technical literacy to hold your own with an engineer. If you have those, the tools and templates are learnable in weeks. If you do not, no certification will paper over the gap.

It is worth being blunt about the technical question, because it stops so many people at the door. You do not need to code. You do need to be unafraid of technology: willing to learn how a system works, to sit in a conversation about databases or interfaces and follow the thread, to ask an engineer a question without flinching. Curiosity closes that gap far faster than any qualification. The analysts who struggle are rarely the ones who cannot code. They are the ones who are frightened of the technical world and keep it at arm's length, and it always shows.

Is this actually you?

Since you are deciding whether to point your career at this, here is an honest self-check. Read these slowly and notice which ones make you nod.

Do you enjoy understanding how things work and why, more than building them with your own hands?
Are you often the one who asks the question everyone else was thinking but did not say out loud?
Can you sit with a messy, unclear problem without rushing to force a tidy answer?
Do you like being the link between people, the translator who makes two groups finally understand each other?
Are you comfortable rarely being the one who builds the thing, and finding real satisfaction in making sure the right thing gets built?

If several of those landed, this role may fit you far better than you assumed. If they left you restless, that is genuinely useful to learn now, before you invest a year in it.

One honest warning

The worst reason to become a business analyst is that it looks like an easy side door into tech for people who cannot code. It is not easy, and it is not a fallback. Done well, it is demanding in its own way, all the harder because the work is invisible when it goes right. The best reason to choose it is the one that brought me here: the description above sounds less like a job you would tolerate and more like the way you already are. If that is you, the rest of this week is about getting you in. Tomorrow, we look at the experience you already have and have not learned to name.

There is also a quieter reason people wash out, worth knowing before you start. Some arrive expecting to be the decision-maker, the one whose plan gets built and applauded. The analyst is rarely that person. You shape the decision, and you shape what gets built, but you are usually not the one who owns it or takes the visible credit. If your satisfaction depends on being the star, this will quietly frustrate you. If it comes from seeing the right thing happen, whoever ends up holding the trophy, you will do well and last long.

Go out and be successful.

Oluwatosin Ogunkoya | Flotog BA Insights | www.flotogbainsights.com

Tomorrow: You Have More Experience Than You Think - Why the experience you already carry maps onto this job more than you realise.