What Nobody Tells a New Business Analyst

A new BA's first weeks go fine on paper. They can write a user story, draft acceptance criteria, run a meeting. Then a stakeholder asks for something, and it turns out none of that preparation answers the questions that actually stall the work: who's allowed to say yes to this, how big is it really, and what happens when the person two desks over wants the opposite thing. Nobody teaches those three, because they aren't skills you can put in a training deck — they're things you only learn by getting them wrong once.

The org chart is the real onboarding

Every company has a formal org chart and a real one, and they're never the same document. The formal chart says who reports to whom. The real one says who actually has to sign off before a requirement can move — and that person is rarely the one in the meeting asking for it. A new BA takes a stakeholder's request at face value, writes it up, and finds out three days later that the actual decision-maker wasn't consulted and wants something different. That's not a communication failure so much as a missing map: nobody handed the BA a list of who owns what decision, so the BA has to rediscover it the expensive way, one redone requirement at a time.

Everything looks the same size until it isn't

Estimation is a skill that only exists in hindsight. A request that sounds like "just add a filter" turns out to touch four systems and a compliance review; a request that sounds enormous turns out to be one config change. A new BA has no internal calibration for this yet, because calibration comes from having been burned by the gap between how a request sounds and what it actually requires. The result is predictable: early estimates are either so padded that stakeholders stop trusting them, or so optimistic that the BA ends up explaining, mid-sprint, why the "small" thing isn't done.

Two stakeholders, one BA, and no instructions on what to do about it

Eventually two people who both have a legitimate claim on priority want different things, and say so in separate meetings the BA happens to be in. Training never covers this, because there's no clean answer — the correct move isn't to quietly pick a side and write the requirement to match, it's to surface the conflict explicitly, in writing, to whoever actually owns the tradeoff (see: the org chart problem above). New BAs default to picking a side, usually the side of whoever spoke last or most senior, because naming a conflict out loud feels like causing one. It doesn't. Not naming it just means the conflict gets discovered later, downstream, by whichever stakeholder didn't get what they wanted.

The vocabulary problem is real too, it just already has its own answer

A fourth struggle — not knowing the domain's jargon, or not knowing how to turn a vague sentence into a testable requirement — is just as common in the first months, but it's less a mystery and more a solvable mechanical skill. Why Jargon Is a Wall and From Stakeholder Sentence to Acceptance Criteria cover those directly. The three above are harder precisely because they aren't mechanical — there's no checklist for "figure out who really decides," only pattern recognition earned by getting it wrong.

The one-question check

Before treating a stakeholder request as ready to write up, a new BA should ask: "If I write this exactly as asked, who besides the person asking has to agree with it?" If the honest answer is "I don't know," that's the actual first task — not the requirement itself.