Skip to content
RequirementsFirst
Go back
business-analysis

BA vs PO vs PM: the difference nobody writes about honestly

By Arun Mehta · 28 May 2026 · 6 min read


Search “BA vs PO vs PM” and you get the same article fifteen times. A neat table. The BA gathers requirements. The PO owns the backlog. The PM owns the roadmap and the market. Everyone has a lane. Everyone is happy.

I have worked as all three titles, sometimes doing identical work under different names depending on the company. The textbook table is not wrong exactly. It is just describing an idealised org that almost nobody actually works in. The honest version is messier, and understanding the mess is more useful than memorising the table.

The textbook version, stated fairly

To be fair to the standard answer, here it is at its best:

In a clean org, these are three people with three distinct jobs. The BA feeds the PO, the PO feeds the team, the PM sets the direction the BA analyses within.

This clean org is rare.

What actually happens

In real companies, the three roles collapse and merge based on factors that have nothing to do with the work itself.

In most Indian IT services companies, “BA” and “PO” are the same person with different titles for different clients. The client calls them a PO because that’s the Scrum word. The vendor calls them a BA because that’s the resourcing category. The person does both jobs. Whether they get to do any real PM-style direction-setting depends entirely on whether the client lets them near actual decisions, which usually they don’t, because the client keeps product ownership in-house.

In startups, one person is all three until around Series B. The founder or first PM does market research in the morning, writes stories at noon, and analyses a workflow problem in the afternoon. The titles only separate when the company is big enough to afford specialists. Before that, “PM” means “the person who owns whether this gets built and whether it works.”

In large product companies, the split is real but the power is not equal. The PM has the budget and the authority. The PO is often a junior PM in waiting, or a delivery-focused role with less strategic say. The BA, if the role exists at all, is frequently treated as documentation support rather than analysis leadership. The hierarchy is PM > PO > BA in influence, regardless of how the textbook describes their “equal but different” responsibilities.

The boundaries between the roles are drawn by org structure, budget, and politics. They are not drawn by any natural division of the work. The same task — “figure out whether we should build this and what it should do” — gets assigned to a BA, a PO, or a PM depending entirely on what the company calls its people and who controls the money.

The distinction that actually matters

If the titles are unreliable, what should you actually pay attention to? One question: who owns the outcome?

Not who writes the stories. Not who runs the standup. Not who has “product” in their title. Who is accountable when the thing ships and the metric doesn’t move?

This cuts through the title confusion immediately:

You can be called a Senior Product Manager and actually be doing PO-level delivery work because the real decisions happen above you. You can be called a Business Analyst and actually be doing PM-level work because your manager trusts your judgement and rubber-stamps your recommendations. The title is a salary band and a hiring category. The work is defined by what you’re accountable for.

Why this matters for your career

The practical reason to understand this: your title is a poor guide to your career growth, and “moving up” often means changing what you’re accountable for, not changing your title.

A BA who wants to become a PM doesn’t need to wait for a PM job to open up. They need to start owning outcomes — taking responsibility for whether a feature succeeds, not just whether the requirements were well-documented. The ones who do this get promoted into PM roles because they’re already doing the work. The ones who wait for the title stay BAs.

Equally, a PM who only does PO-level work — grooming backlogs, running ceremonies, never actually setting direction — will find their role precarious, because that work is more easily replaced or offshored than genuine direction-setting. The title protects you less than the accountability does.

The honest summary

The textbook table is fine as a starting vocabulary. But the truth is:

If you’re trying to figure out which role you want, stop comparing the definitions. Ask instead: how much of the outcome do I want to own, and how much ambiguity am I willing to absorb to own it? That question maps to the real work far better than any title comparison.

The person who understands this stops worrying about whether they’re “really” a BA or a PO or a PM, and starts paying attention to the only thing that compounds: a track record of owning outcomes that turned out well.


The next piece in this series looks at what actually changed about being a BA between 2020 and 2025, and what didn’t. Subscribe below to get it.


Share this post:

Get new posts by email

Notes on requirements, problem-framing, and the BA craft. No spam, unsubscribe anytime.


Next Post
INVEST and SPIDR both miss the point