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

You want to become a Business Analyst.

So you open LinkedIn and search for jobs.

First role:

2 years of experience.

Second role:

3 years.

Then you find one called Entry Level.

Nice.

You open it.

It also wants experience.

And now you're probably thinking:

How am I supposed to get experience if nobody will hire me without experience?

Fair question.

And this is where a lot of people go in the wrong direction.

They start collecting things.

One course.

Then another.

Jira.

SQL.

Power BI.

Agile.

Maybe a certification.

Maybe three.

Six months later, they know more terminology.

But they still haven't shown anyone they can actually do BA work.

So here's the idea I want you to remember:

Don't try to look experienced.

Create evidence that you can analyse.

You can analyse a process, write requirements, map a system, practise stakeholder interviews and build a case study today.

You don't need a company to give you permission to start.

Your path can look like this:

Learn → Simulate → Build → Prove → Enter → Compound

Let's go through it.

---

First, what does a Business Analyst actually do?

Forget Jira for a minute.

Imagine you work for a bank.

Someone from the business comes to you and says:

"Customers are abandoning our loan application."

That's it.

That's the problem.

Nobody knows exactly why.

Management wants conversion to improve. Technology wants requirements. Operations has complaints. Compliance has rules. Customers just want the application to work.

So what does the BA do?

Start asking questions.

Where are customers dropping out?

Which customers?

What happens immediately before they leave?

What information are we asking them to provide?

Why do we need it?

Which systems are involved?

Which teams own those systems?

Are there regulatory requirements?

What happens when something fails?

What should happen instead?

Slowly, this:

"Customers are abandoning the application."

turns into:

Problem → Evidence → Root Cause → Requirements → Solution → Validation

That's Business Analysis.

You're taking something vague and making it clear enough for people to make decisions and build something.

If you remember only one definition of Business Analysis, remember this:

A good BA brings structure to ambiguity.

---

Please don't start with tools

I see beginners do this all the time.

They ask:

"Which BA tools should I learn?"

It's not a bad question.

It's just not the first question.

Let me show you why.

Imagine someone tells you:

"Some customers are being charged twice. Find out why."

Open Jira.

Now what?

Jira can't tell you why.

Neither can Confluence.

Neither can a BPMN tool.

Even SQL won't magically tell you what question to ask.

First, you have to think.

Which transactions are affected? When did this start? Is there a pattern? Which systems touch the transaction? Could a retry create a duplicate? What does the data show? What should happen according to the business rule?

Now SQL becomes useful.

Now process modelling becomes useful.

Now Jira becomes useful.

The tools support your analysis.

They are not the analysis.

So don't think:

Jira + SQL + Excel + Power BI + Certification = Business Analyst

Think:

Thinking + Business + Process + Data + Technology + Communication = Business Analyst

Then learn the tools that help you do those things.

---

So what do employers actually want?

Here's the good news.

For a beginner role, nobody sensible expects you to know everything.

But employers do need a reason to believe you can become useful.

Can you understand a business problem?

Can you ask sensible questions?

Can you map a process?

Can you work with basic data?

Can you understand how systems communicate?

Can you turn vague information into something structured?

Can you talk to both business and technology people?

And increasingly:

Can you use AI without asking it to do all the thinking for you?

That's what you're trying to prove.

Not:

"I know every BA tool."

But:

"Give me a messy problem and I know how to start making sense of it."

Big difference.

---

The roadmap I would follow

If I had to start from zero today, I'd keep it simple.

Learn → Simulate → Build → Prove → Enter → Compound

1. Learn

Understand how Business Analysis works.

2. Simulate

Practise solving realistic business problems.

3. Build

Turn that practice into complete BA projects.

4. Prove

Make your ability visible.

5. Enter

Use that evidence to get your first relevant role.

6. Compound

Add real-world experience and domain knowledge.

Most people try to go:

Learn → Get Job

That's why they get stuck.

The useful work is in the middle.

---

Stage 1 — Learn

You don't need to learn everything.

You need a foundation strong enough to analyse a problem without immediately reaching for a tool.

I'd focus on five areas.

1. Requirements

Understand the difference between:

Business Requirement — What outcome does the organisation want?

Stakeholder Requirement — What does a particular stakeholder need?

Functional Requirement — What must the system do?

Non-Functional Requirement — How well must the system perform?

Then learn epics, features, user stories and acceptance criteria.

But don't memorise definitions in isolation.

Take something real — for example, a banking app that cannot schedule payments — and ask:

What is the business objective?

Who needs the feature?

What should the system do?

What rules apply?

What could go wrong?

That's when the terminology starts becoming useful.

2. Processes

Learn flowcharts, swimlanes, As-Is, To-Be and basic BPMN.

The goal isn't beautiful diagrams.

The goal is to hear a messy ten-minute explanation and start seeing:

Actors → Steps → Decisions → Handoffs → Exceptions

The diagram is simply how you communicate that understanding.

3. Stakeholders

Get into the habit of asking:

Who uses this?

Who owns it?

Who approves changes?

Who builds it?

Who supports it?

Who regulates it?

And one of my favourites:

Who gets the phone call when it breaks?

That question often reveals the real operational owner faster than an org chart.

4. Data

You don't need to become a data engineer.

But don't be afraid of data.

Learn Excel, basic SQL, tables, keys, joins, filters, aggregations and basic data modelling.

When someone says:

"System A says this trade succeeded. System B says it failed."

Don't think:

That's technical.

Think:

Interesting. What data does each system have?

5. Systems

You also don't need to become a developer.

Understand APIs, JSON, HTTP methods and status codes, databases, authentication, system integrations, and batch versus real-time processing.

If someone says:

"System A sends the order to System B through an API, but System B sometimes times out."

You should be able to ask:

What happens after the timeout?

Do we retry?

Could that create a duplicate?

How do we know whether System B processed the original request?

Notice what happened.

We are back to analysis.

---

Stage 2 — Simulate

This is where I want you to stop studying for a while.

Seriously.

Close the course.

Pick something you already use.

Let's take a UPI payment.

You probably use it without thinking.

Today, don't use it like a customer.

Use it like a BA.

Who is involved?

Customer.

Merchant.

Payment application.

Sending bank.

Receiving bank.

Payment network.

Now think about the happy path:

Payment Initiated → Authentication → Bank Validation → Processing → Confirmation

Easy enough.

Now make it difficult.

What if the PIN is wrong? The bank is unavailable? The request times out? Money leaves your account but the merchant gets no confirmation? You press Pay twice? The reversal is delayed?

Now you're thinking differently.

You're no longer studying Business Analysis.

You're doing Business Analysis.

Do this with an ATM withdrawal, Amazon return, Uber booking, Swiggy cancellation, Netflix subscription, bank transfer or flight booking.

You are surrounded by free BA case studies.

Use them.

---

Stage 3 — Build

Once you've done enough small exercises, build something properly.

And no, you don't need twenty projects.

I'd rather see three good projects than twenty projects you barely understand.

Build these three.

Project 1 — Improve a Process

Scenario

A company's customer onboarding takes seven days.

Your job:

Figure out why and improve it.

Create:

Problem statement, stakeholder map, As-Is process, pain points, root-cause analysis, To-Be process, business requirements, success metrics.

What are you proving?

I can understand and improve a process.

Project 2 — Define a Product Feature

Scenario

A banking app wants to introduce scheduled payments.

Create:

Business objective, scope, stakeholders, functional requirements, non-functional requirements, user stories, acceptance criteria, wireframes, business rules, exception scenarios, UAT scenarios.

What are you proving?

I can turn an idea into clear requirements.

Project 3 — Understand a System Integration

Scenario

An e-commerce platform wants to integrate with a new payment provider.

Map:

Customer, e-commerce application, payment service, bank, database, notification service.

Then think through:

System interactions, API requirements, data mapping, success responses, failure responses, timeouts, retries, duplicate prevention, reconciliation, UAT scenarios.

What are you proving?

I can think across systems.

Now imagine you're interviewing someone.

Now compare that with a candidate who only says:

"I've completed a Business Analyst certification."

The portfolio gives the interviewer something much more useful to discuss.

---

Stage 4 — Prove

If nobody has hired you yet, your projects have to do some of the talking for you.

Don't write this on your CV:

Knowledge of Business Analysis.

Show me.

Instead:

Created an As-Is and To-Be model for a customer onboarding process and identified five process bottlenecks.

Don't write:

Familiar with Agile.

Try:

Translated product requirements into user stories with testable acceptance criteria and exception scenarios.

Don't write:

Basic SQL knowledge.

Try:

Used SQL queries to validate transaction data and investigate discrepancies between expected and actual results.

One tells me what you've studied.

The other tells me what you've done.

Your portfolio doesn't need to be fancy

Please don't spend three weeks choosing fonts for your portfolio.

For every project, show five things:

The Problem — What was wrong?

Your Investigation — How did you approach it?

Your Artifacts — What did you create?

Your Recommendation — What would you change?

Your Reasoning — Why?

That final one matters most.

A weak portfolio shows documents.

A strong portfolio shows how you think.

---

Stage 5 — Enter

Now start applying.

But don't search only for Business Analyst.

Your first step might be called:

Junior Business Analyst, Associate Business Analyst, Functional Analyst, Systems Analyst, Business Systems Analyst, Product Analyst, Operations Analyst, Process Analyst, Implementation Analyst, Technology Analyst, Application Analyst, PMO Analyst.

Companies give similar work completely different names.

Read the job description and ask:

Will I analyse processes?

Will I work with stakeholders, requirements, systems or data?

Will I participate in testing or delivery?

If several answers are yes, pay attention.

Your first goal isn't the perfect title.

Your first goal is proximity to the work.

---

Pick a domain

Domain knowledge becomes an accelerator faster than most beginners realise.

Imagine two candidates.

Both understand requirements. Both know SQL. Both know Jira.

The job is in investment banking.

Candidate A knows generic Business Analysis.

Candidate B understands orders, trades, execution, clearing, settlement, positions and market data.

Who can become useful faster?

Probably Candidate B.

So pick something: banking, capital markets, insurance, healthcare, e-commerce, telecom, logistics, SaaS or manufacturing.

Then learn:

Who are the actors?

What language do they use?

What are the major processes?

What systems are involved?

What usually goes wrong?

What rules or regulations matter?

You don't need to become an expert.

You just need to reach the point where people in that industry stop sounding like they're speaking another language.

---

And yes, learn to use AI

This is one place where starting today gives you a genuine advantage.

You have an endlessly available practice partner.

Don't waste it by doing this:

"Write a BRD for a banking application."

AI gives you twenty pages.

Great.

What exactly did you learn?

Instead, try:

"You are the Operations Manager of a digital bank. Customers are complaining about failed payments. I'm the Business Analyst investigating the problem. Stay in character. Don't give me the requirements. Only answer the questions I ask."

Then interview it.

Ask questions. Miss something. Discover it later. Ask better questions.

That's practice.

Then write the requirements yourself and ask AI:

"Act as a Senior Business Analyst reviewing my requirements. Find ambiguity, contradictions, hidden assumptions, missing edge cases and requirements that cannot be tested."

Now AI is useful.

It's exposing holes in your thinking.

Use AI to make your thinking stronger, not to avoid thinking.

---

Do you need certifications?

They can help.

They give you structure, terminology and a little extra credibility.

But a certificate and capability are not the same thing.

Imagine an interviewer asks:

"Transactions are disappearing somewhere between two systems. How would you investigate?"

Your certificate can't answer.

You have to.

So if time is limited, I'd go:

Learn → Practise → Build → Certify

Not:

Certify → Certify → Certify → Apply

---

Give yourself 90 days

Don't turn this into a two-year preparation project.

Give yourself three focused months.

Days 1–30 — Learn

Focus on BA fundamentals, requirements, user stories, acceptance criteria, process modelling, stakeholder analysis, Agile, SDLC, UAT, SQL basics and API basics.

One rule:

Never learn something without applying it to an example.

Days 31–60 — Build

Create:

Project 1 — Process Improvement

and

Project 2 — Product Requirement

Build them, inspect what's weak, then improve them.

Days 61–90 — Prove

Create:

Project 3 — System Integration

Then build your portfolio, rewrite your CV, improve LinkedIn, practise interviews, talk to people already doing the job and start applying.

Keep learning.

But stop hiding behind learning.

---

Build your first BA portfolio project today

Pick one process you already understand: a UPI payment, ATM withdrawal, Amazon return, Uber booking, Swiggy cancellation, bank transfer or flight booking.

Then create one small but complete case study.

Use this structure:

1. Problem — What is happening, and why does it matter?

2. Context — What product, process or system are you analysing?

3. Stakeholders — Who uses it, owns it, supports it, builds it and regulates it?

4. As-Is Process — What happens today from trigger to completion?

5. Evidence — What observations, sample data, complaints or assumptions are you working with?

6. Pain Points and Root Cause — Where does the process fail, slow down or create confusion? What might be causing it?

7. To-Be Process — What should happen instead?

8. Requirements — Write the business, functional and non-functional requirements.

9. User Stories and Acceptance Criteria — Turn the most important requirements into testable behaviour.

10. Exceptions — What happens when something fails, times out, duplicates or arrives in the wrong state?

11. Data and Systems — What information moves between which systems?

12. UAT Scenarios — How would you prove the change works?

13. Success Metrics — What would improve if your recommendation worked?

14. Your Recommendation — What would you change first, and why?

That's enough for a real portfolio project.

Not a fictional claim of experience.

Evidence of how you think.

Want a structure you can just fill in instead of building this from scratch? Download the free BA Portfolio Project Template → — the same structure above, already laid out for you to copy for every project you build.

---

The whole roadmap in one picture

If you forget everything else, remember this:

Learn → Simulate → Build → Prove → Enter → Compound → Learn again

Your first project makes the second easier.

Your first interview makes the next easier.

Your first year of experience makes the second year more valuable.

Eventually, the problem you started with —

"Nobody will hire me because I don't have experience."

— starts disappearing.

Because now you have evidence before you have the title.

---

One last thing

A lot of people think their Business Analyst career begins when someone finally puts Business Analyst next to their name.

I don't think that's true.

It starts the first time someone gives you a vague problem and you don't leave it vague.

You ask another question.

You map what is happening.

You look at the data.

You find the assumptions.

You think about what could go wrong.

And eventually you turn:

"We have a problem."

into:

"I think I understand what's happening."

That's the work.

So don't spend the next six months trying to look experienced.

Start doing the work.

Because your first BA job should not be the first time you do BA work.

If you want to point that thinking at capital markets specifically, the Capital Markets Business Analyst Roadmap → picks up from here.