When I first heard the title Business Analyst, I assumed it was mostly documentation. You sit with stakeholders, they tell you what they want, you write it down neatly, and engineering builds it. That is roughly what I expected the job to be.
It is not really that. Here are the things I would tell myself if I could go back to the first week.
Nobody hands you the problem
I expected requirements to arrive as requirements. Mostly they arrive as frustration. Someone says a process takes too long, or that a report is wrong, or that a team keeps doing something manually. That is not a requirement yet. It is a symptom, and part of my job is working backwards from it to whatever is actually going on.
The first version of a request is almost never the real request. It is the version someone could articulate quickly while thinking about something else.
Writing is the smallest part of writing requirements
The document is the output. The work is everything before it: the conversations, the clarifications, the four times you re-ask the same question in slightly different ways because the answer keeps changing shape.
If I spend an hour on a requirement, maybe ten minutes of that is typing. The rest is trying to be sure I understood.
Being technical helps, but not in the way I assumed
I came from Computer Science, so my instinct was to reach for how something would be built. That instinct is useful. It means I can have a real conversation with engineers, and I can usually tell when something sounds harder than it is being described.
But it is also a trap. Thinking in solutions early makes you stop asking questions early. The technical background is most useful when I hold it back until I actually understand what we are solving.
Disagreement is information, not a problem
Early on, when two stakeholders described the same thing differently, my instinct was to smooth it over and pick the version that sounded most confident. That was a mistake. Two people describing the same process differently usually means the process genuinely works differently for each of them, and that difference is exactly the thing worth documenting.
You will be the one who notices the gap
A lot of the value of the role is unglamorous. It is noticing that nobody said what happens when the field is empty. Or that two teams are using the same word for different things. These are small at the requirement stage and expensive later.
You are allowed to not know
This is the one I would most want to tell myself. I spent the first few weeks trying to sound like I already understood things, because I thought that was what competence looked like. It is not. Saying "I don't think I've understood this properly yet, can you walk me through it again" has consistently been more useful to me than any answer I have pretended to have.
A good Business Analyst isn't the person who has all the answers. It's often the person who asks the question nobody else thought to ask.