How to Start a Business Analyst Career From Scratch — With No Experience

Most beginners collect certifications and still can't prove they can do BA work.

Most beginners collect certifications and still can't prove they can do BA work. A practical roadmap: learn, simulate, build three real projects, and create evidence before you have the title.

Surya · 15 min read

Business Analysis

Scope Creep Is a Timing Problem, Not a Willpower Problem

The same change costs nothing in a requirements meeting and a full sprint once code exists to contradict it.

The same change costs nothing in a requirements meeting and a full sprint once code exists to contradict it. Scope creep isn't a discipline failure — it's what happens when nobody names the cost out loud at the moment the request arrives.

Surya · 3 min read

Business Analysis

What Nobody Tells a New Business Analyst

BA training teaches you to write a user story.

BA training teaches you to write a user story. It doesn't teach you who's allowed to approve it, how big it really is, or what to do when two stakeholders both think they're the priority.

Surya · 4 min read

Business Analysis

From Stakeholder Sentence to Acceptance Criteria

A vague request becomes useful only when behavior becomes testable.

Every requirement hides a user story. The BA's job is making the translation visible — and being honest about which parts you inferred.

Surya · 3 min read

Business Analysis

The Acronym Wall Every New Banking BA Hits

Acronyms are not knowledge. They are locked doors.

KYC, CDD, EDD, SAR — four acronyms that look interchangeable and aren't. Get the ladder wrong and the requirement you write is the one that fails.

Surya · 4 min read

Business Analysis

What Actually Happens Between a Jira Ticket and a Test Case

The gap between idea and test is where defects are born.

A ticket isn't a spec. Turning one into a tested, reviewed FSD takes a pipeline — whether a human runs it or an agent does.

Surya · 3 min read

Business Analysis

Why Jargon Is a Wall

Every unexplained acronym charges an entry fee.

Jargon isn't decoration, it's a gate — and a business analyst has to hold the door open on two sides of it at once.

Surya · 3 min read

Business Analysis

Why Jira Tickets Rot in Backlog

A backlog is not storage. It is a decay chamber.

Tickets don't die from neglect. They die from ambiguity about what would let them move — and no one owns fixing that.

Surya · 3 min read

Business Analysis

Writing Requirements That Survive Contact With Engineering

A good requirement still works after the meeting ends.

Why most business requirements fall apart in sprint planning, and how to write ones that don't.

Surya · 3 min read


**Core question:** how do you actually know when something is done?

## The metaphor: a handshake vs. a contract

A user story without acceptance criteria is a handshake deal. Both sides nod, both sides believe they agree, and both sides walk away with a slightly different picture of what was promised — which only becomes visible once the work is "done" and it doesn't match what either side remembers agreeing to. Acceptance criteria are the contract version of that same handshake: written down, specific, and checkable by someone who wasn't in the room when the deal was made.

 Callout type="insight" title="A shared assumption isn't a shared understanding" 
Two people can nod at the same sentence and picture two different outcomes. Acceptance criteria exist to force that gap into the open before the work starts, not after it ships.
 /Callout 

## Given / When / Then is the actual unit of "done"

The useful structure is a precondition, a trigger, and an outcome: *given* the account is locked, *when* the user requests a password reset, *then* a reset link is emailed and the lock stays in place until it's used. Each clause is independently testable — a QA engineer, a developer, and the original stakeholder can all check the same sentence against the same built feature and reach the same yes-or-no answer. That's the entire point: acceptance criteria aren't documentation, they're a test someone can actually run.

 Callout type="question" 
Could two different engineers, working independently, build testably identical things from this criteria alone? If the answer depends on both of them happening to guess the same unstated assumption, the criteria aren't finished yet.
 /Callout 

## Why this matters

"Done" isn't a feeling the team agrees on in a meeting. It's a checklist that was written before the work started, specific enough that no one — not the developer, not the tester, not the stakeholder — has to rely on memory to know whether it was actually met.



**Core question:** why does trade make sense even when one party is better at every single task involved?

## The metaphor: the surgeon and the secretary

A surgeon might type faster than her own secretary — better at surgery *and* better at typing, no contest either way. But every hour she spends typing is an hour not spent in surgery, where her advantage over everyone else is enormous. The secretary's advantage over her at typing is small in absolute terms, but the surgeon's true cost of typing it herself is the surgery she gave up to do it. She hires the secretary anyway — not because the secretary types better, but because the surgeon's time is too valuable to spend on it.

 Callout type="insight" title="It's about opportunity cost, not skill level" 
Trade isn't decided by who's absolutely better at a task. It's decided by who gives up less by specializing in it — and that number can favor the person who's objectively worse at everything.
 /Callout 

## Same logic, whole economies

This is why trade between a highly advanced economy and a less advanced one still benefits both sides, even if the advanced one is better at producing everything it trades. It still gains by specializing in whichever good it gives up the least to produce, and trading for the rest — exactly like the surgeon and her secretary, just at a larger scale.

 Callout type="question" 
Before assuming you should do a task just because you're the best person available for it, ask: what's the opportunity cost of my time doing this, instead of the thing only I can do?
 /Callout 

## Why this matters

Being the best at something is not the same question as whether you should be the one doing it. Comparative advantage is the reminder that the right division of labor is about relative cost, not absolute talent — which is exactly why it keeps surprising people who only ever check who's "better."



**Core question:** what happens if you're right about the trade, but the person on the other side of it can't pay?

## The metaphor: lending a ladder to a neighbor vs. a stranger passing through

The ladder itself doesn't change. Who you lend it to does. Your reliable neighbor gives it back tomorrow without you thinking twice. A stranger passing through town might vanish before returning it, no matter how sturdy the ladder was. Counterparty risk is the same idea applied to a trade: it has nothing to do with whether your market view was correct, and everything to do with whether the entity on the other side of your contract can actually make good on it.

 Callout type="insight" title="Two separate risks, often confused" 
Market risk is about whether the asset moves the direction you expect. Counterparty risk is entirely different — you can be exactly right about the direction and still lose the full value of the trade if the other side defaults before paying you what they owe.
 /Callout 

## This is exactly why clearinghouses exist

A clearinghouse solves the ladder problem by turning every stranger into the same well-known neighbor. It steps into the middle of a trade and becomes the counterparty to both sides — the buyer no longer faces the seller's risk of default, and the seller no longer faces the buyer's. Both face the clearinghouse instead, which pools and manages that risk across its whole membership rather than leaving each trade exposed to whoever happened to be on the other side of it.

 Callout type="question" 
Before a trade, ask not just "will this move the direction I expect" but "if I'm right, can the other side actually pay me when it's due?" The first question is about the market. The second is about who you're actually trading with.
 /Callout 

## Why this matters

A trade isn't just a bet on price. It's also a bet on the solvency of a specific counterparty for however long the contract stays open — and that second bet is invisible until the day it matters, which is exactly when it's too late to do anything about it.



**Core question:** where do trades actually happen, and why does the venue change what the trade means?

## The metaphor: a farmer's market vs. a private phone call

An exchange is a farmer's market: every buyer and seller sees the same posted prices at the same stall, and the trade happens where anyone standing nearby could have watched it. **OTC** — over-the-counter — is a private phone call between two parties instead. The deal terms, and often the price itself, are known only to the two people who made it. Same goods can move through either channel. The venue decides who else gets to know what happened.

 Callout type="insight" title="Public price vs. private deal" 
An exchange trade creates a public price everyone can reference for the next trade. An OTC trade doesn't — which is exactly why complex, bespoke instruments (many swaps, structured products) trade OTC in the first place. No public stall would fit a deal this custom.
 /Callout 

## Same asset, different venue, different price

The exact same stock can move through both channels. Most shares trade on the exchange, at the visible posted price. But a large institutional block of that same stock might get negotiated privately instead — specifically to avoid moving the public price before the trade is even finished. Size and privacy, not the asset itself, often decide which venue a trade uses.

 Callout type="question" 
Next time you see a price quoted, ask: was this posted on an exchange, where anyone could have gotten the same number — or was it negotiated OTC, between two specific parties who agreed to it privately?
 /Callout 

## Why this matters

The venue isn't a technical detail — it's the difference between a price the whole market can react to and a price only two people will ever see. Regulation, liquidity, and even how confidently you can trust a quoted number all trace back to which of these two a trade actually went through.



**Core question:** if no single authority sets a price, how does a price ever actually get discovered?

## The metaphor: not an announcement, a running poll

Every incoming order is a fresh vote about what an asset is worth right now, cast by someone willing to back their opinion with real money. Price discovery isn't a single event where a number gets declared — it's a running tally of a poll that never closes. The "current price" is just whichever vote most recently won.

 Callout type="insight" title="The price is a tally, not a fact" 
Nobody announces that a stock is now worth a different amount. The price simply reflects the latest vote in a poll that's been running continuously since the market opened — stable-looking only because the votes usually agree with each other.
 /Callout 

## News moves price precisely because it changes votes

New information doesn't move a price directly — it moves what buyers are willing to pay and what sellers are willing to accept, and the price shifts because the votes themselves changed. A sharp move after an earnings report isn't the market "reacting" in the abstract. It's thousands of individual votes flipping at once, and the tally updating to match.

 Callout type="question" 
When a price moves sharply, ask what information could have just changed enough people's votes at the same moment — that's usually easier to find than trying to explain the price move directly.
 /Callout 

## Why this matters

Treating a price as a fixed, authoritative number instead of a live poll result is where a lot of bad intuitions about markets come from. A price didn't get decided. It's still being voted on, right now, and it will keep changing the moment enough votes do.



**Core question:** what should be built first, when everything feels urgent?

## The metaphor: triage in an emergency room

An ER doesn't treat patients in the order they arrived. It treats them in order of what happens if they wait — a broken finger and a chest pain case might arrive at the same moment, but nobody seriously suggests treating them first-come-first-served. Prioritizing a backlog is the same triage, not a queue: the order tickets arrived in tells you almost nothing about the order they should be worked in.

 Callout type="insight" title="Loudest voice isn't most critical" 
"Urgent" and "important" get conflated constantly on a backlog. The stakeholder who escalates the hardest doesn't automatically have the item that costs the business the most by waiting — they just have the most confidence, or the most patience for meetings.
 /Callout 

## Value and effort are the only two axes that matter

Every item on a backlog can be placed on two axes: how much value it delivers, and how much effort it takes to deliver. High value, low effort items are the ones triage would send straight to the front — the equivalent of a five-minute fix that stops the bleeding. Low value, high effort items belong at the back regardless of who's asking, no matter how urgently they're asking for it. Prioritization frameworks (MoSCoW, weighted scoring, whatever the team uses) are just formal ways of forcing that comparison instead of letting whoever asks loudest win by default.

 Callout type="question" 
For any item near the top of the backlog, ask: what actually happens if this waits one more sprint, and who notices? If the honest answer is "nothing, and no one," it isn't triage-first — it just arrived first.
 /Callout 

## Why this matters

A backlog ordered by arrival time or by who complained most recently isn't prioritized — it's just a log. Real prioritization means being able to explain, for the item at the top, specifically what gets worse if it waits — the same way an ER can explain why the chest pain goes first, not just that it does.



**Core question:** why does the problem you solve matter more than how well you solve it?

## The metaphor: a doctor who prescribes before diagnosing

A patient walks in and says "I need antibiotics." A bad doctor writes the prescription. A good doctor asks what's actually wrong first — because "I need antibiotics" is already a diagnosis the patient made themselves, and patients are usually wrong about what's actually causing their symptoms. Stakeholders do the same thing constantly: "we need a dashboard," "we need a new system," "we need an approval workflow." Each one is a prescription arriving before anyone confirmed the diagnosis.

 Callout type="insight" title="The most expensive words in a requirements meeting" 
"We need a system that..." is already a solution. It skips the one question that would have told you whether it's the right one: what problem is this actually solving, and does the system even solve it?
 /Callout 

## The requested solution has already made three decisions

By the time a stakeholder names a fix, they've silently already decided its shape, its technology, and who's responsible for it — all before the actual problem was ever said out loud. Accept the request as stated and you've inherited three decisions nobody actually examined. Walk it back to the problem first, and some of those three might turn out wrong: the right fix might be a process change, not a system; a policy change, not a dashboard.

 Callout type="question" 
Next time a request arrives starting with "we need X," ask what happens today without X. The gap between those two answers is the actual problem — X was just someone's first guess at closing it.
 /Callout 

## Why this matters

A solution chosen before the problem is understood tends to treat the stated symptom while leaving the underlying cause untouched. It still gets built, on time, to spec — and it still doesn't fix anything, because nobody ever confirmed it was aimed at the right target in the first place.



**Core question:** how do you give a model access to information it never studied, without retraining it from scratch?

## The metaphor: an open-book exam vs. a memorized one

A model that was trained on a fixed dataset is taking a closed-book exam — it only knows what it studied before the exam started, frozen at that point. **RAG** — Retrieval-Augmented Generation — is an open-book exam instead: at question time, the model gets handed the specific pages relevant to *this* exact question, pulled fresh from a library it never had to memorize. It doesn't need to know everything in advance. It just needs to know how to look up the right page and read it.

 Callout type="insight" title="The model doesn't change — only what it's shown does" 
RAG doesn't retrain the model at all. It changes what gets placed in front of it at question time, which is exactly why it's the easy way to keep answers current: add a new page to the library, and it's searchable immediately, with no retraining required.
 /Callout 

## The default for anything that changes, or shouldn't be memorized

This is why RAG is the standard choice for internal company documents, this week's data, or anyone's private files — a closed-book exam can't cover material that didn't exist when the studying happened, no matter how good the studying was. Fine-tuning a model's weights is for teaching a stable style or skill. RAG is for handing it facts that are still changing, or that were never meant to live inside the model itself.

 Callout type="question" 
Before assuming a model should just "know" something, ask whether it's actually stable, general knowledge worth memorizing — or something that should be looked up fresh every time because it changes, it's private, or it's simply too large to bake in.
 /Callout 

## Why this matters

The instinct to fix a knowledge gap by retraining the model is usually the expensive, slow answer to a problem RAG solves in minutes. Most "the model doesn't know X" problems aren't training problems at all — they're retrieval problems, solved by handing over the right page instead of trying to make the model memorize the whole library.



**Core question:** should every decision get the same amount of deliberation?

## The metaphor: one-way doors and two-way doors

A one-way door only opens in one direction — walk through, and there's no walking back. A two-way door is different: if it turns out to be the wrong room, you just walk back through and try another. Decisions work the same way. Some are one-way doors, where a wrong call is expensive or impossible to undo, and deserve careful, slow, well-consulted deliberation. Most are two-way doors, where being wrong just costs a course correction — and treating them like one-way doors is where a lot of organizational slowness actually comes from.

 Callout type="insight" title="Most decisions get treated like the rare ones" 
Endless meetings and sign-offs for a decision that's trivially reversible aren't carefulness. They're slowness borrowing the appearance of diligence from the rare decisions that actually deserve it.
 /Callout 

## The real skill is sorting, not deciding

Before deliberating on a decision at all, the first move is classifying it: can this be undone cheaply if it's wrong? If yes, decide fast, often by one person, and correct course later if needed — the cost of being wrong is low, so the cost of deciding slowly is pure waste. If no, slow down deliberately and gather more information first, because there's no "try again" available once you're through that door. The speed of a decision should match how reversible it is, not how big or important it feels in the moment.

 Callout type="question" 
Before scheduling another meeting about a decision, ask: if we're wrong, how expensive is it to reverse? If the honest answer is "trivial," the meeting is already costing more than the decision itself.
 /Callout 

## Why this matters

Organizations don't usually get slow because people are lazy. They get slow because every decision gets sorted into the "irreversible" bucket by default, out of caution — and caution applied to a decision that was never actually risky isn't caution. It's just cost, dressed up as prudence.



**Core question:** why do good decision-makers treat a coin flip completely differently from a genuinely unknown future?

## The metaphor: a labeled deck vs. an unlabeled one

**Risk** is a deck of cards where you know exactly what's in it — you might not know which card comes next, but you know the odds. Insurance, casino games, and most everyday probability puzzles are risk: the deck is labeled, even if any single draw is uncertain.

**Uncertainty** is a deck where you don't even know what's in it — new categories of cards you've never seen, or cards that don't exist yet. Launching a genuinely new product, predicting a novel technology's effect on a market, forecasting a one-off geopolitical event — these aren't risk. There's no stable deck to calculate odds from.

 Callout type="insight" title="Confusing the two is the actual mistake" 
Treating uncertainty as if it were risk — assigning confident percentages to things that are fundamentally unknowable — is where most bad forecasts come from. The math looks rigorous. The deck was never labeled.
 /Callout 

## Why this distinction changes behavior

Under risk, the right move is to calculate expected value and act on it — the odds are real, so trust the math. Under uncertainty, the right move is different: build in optionality, run small reversible experiments, and stay able to change course, because no calculation can tell you the "true" odds of something that's never happened before.

 Callout type="question" 
Before trusting a forecast, ask: is this a labeled deck, or an unlabeled one? The confidence in the delivery tells you nothing about which one it is.
 /Callout 

## Why this matters

Good decision-makers don't have better crystal balls. They're just more honest about which situations are a labeled deck and which ones aren't — and they stop demanding false precision from the ones that aren't.



**Core question:** why does a price settle where it does, instead of anywhere else?

## The metaphor: two crowds pushing on a door

Picture a door with people pushing from both sides. On one side, buyers push harder the cheaper the price gets — more people want in at a bargain. On the other side, sellers push harder the more expensive it gets — more people are willing to sell if the reward is bigger. The door settles wherever the two pushes exactly cancel out. That resting point is the price.

Push either crowd harder — more buyers show up, or sellers become scarcer — and the door slides to a new resting point. Nobody decided the new price. It's just where the pushing balances again.

 Callout type="insight" title="Price is a byproduct, not a decision" 
No single person sets the market price of wheat, oil, or a stock. It emerges from thousands of independent pushes finding their balance point — which is why prices can shift overnight without anyone "deciding" to change them.
 /Callout 

## Why shortages and gluts are the same phenomenon

A shortage is just the door stuck too far toward the buyers' side — the price is artificially low, so more people want in than the sellers' side can supply. A glut is the mirror image: price stuck too high, sellers piling up with no buyers pushing back. Both are the same mechanism, just displaced from the balance point — usually by something external holding the price fixed (a price cap, a subsidy, a shock to supply).

 Callout type="question" 
Next time you see a shortage in the news, ask: is demand suddenly rising, or is something stopping the price from finding its natural balance point?
 /Callout 

## Why this is worth understanding

Once you see price as a balance point rather than a fixed fact, a lot of economic behavior stops being mysterious: why gas prices spike during shortages, why concert tickets get scalped, why a heatwave moves the price of ice cream. It's always the same two crowds, pushing.



**Core question:** out of everything an organization *could* build, why does it build this instead of that?

## The metaphor: a scale, not a checklist

A business case isn't a list of reasons something is good — almost anything can be justified with a long enough list of upsides. It's a scale, with cost and risk on one side and value on the other, built to be checked *against a specific alternative*: doing nothing, or doing the next-best thing on the list. A business case that never names its alternative isn't really a case for anything — it's just enthusiasm.

 Callout type="insight" title="The real competitor is usually 'do nothing'" 
Most business cases quietly compare an idea to nothing at all, when the real competition is every other initiative fighting for the same budget and the same engineering time this quarter.
 /Callout 

## The four things a real business case answers

- **What changes if we do this?** — the measurable outcome, not the feature list.
- **What does it cost, including the cost of *not* doing something else?**
- **What has to go right for the value to actually show up?** — the assumptions the case is quietly resting on.
- **How would we know, after the fact, whether it worked?**

 Callout type="question" 
If you can't answer the fourth question before the project starts, ask whether anyone will actually check afterward — or whether "success" will just be declared by default.
 /Callout 

## Why this matters

The organizations that build the right things aren't the ones with the best ideas — everyone has good ideas. They're the ones that can weigh ideas against each other honestly, using the same scale every time, instead of whichever argument was pitched most persuasively in the room.


Business Analysis essays

Business Analysis