PO vs PM vs BA: what is the difference?
How PO, PM and BA really differ, how the lines move between outsourcing firms, product companies and startups in Vietnam, and how to read a job description to see which role it actually is.
Written by Phan Lam Duy Khoi
Product Owner is an accountability in Scrum: the person accountable for maximising product value and ordering the backlog. Product Manager and Business Analyst are job titles: a PM usually owns why and what to build, a BA clarifies needs and requirements, but where the lines fall depends on the company.
Three job ads, three titles, one kind of job?
You have worked in QA for two years and want to move into product. Tonight you save three job ads. The first says “Product Owner” at a company that builds software for overseas clients, and asks you to write specifications and meet the client every week. The second says “Business Analyst” at a company with its own product, and asks you to manage the backlog and choose features for each sprint. The third says “Product Manager” at a five-person startup, and asks you to talk to customers, write user stories and track the numbers.
This is an illustrative situation, but it matches how many people feel when they start looking: the title says one thing and the description says another. You are not sure what to learn, which ad to apply for, or what the daily work would actually be.
This article separates three ideas that often get mixed up, shows how the lines move between types of company, and gives you a checklist for reading job ads by the real work instead of the title. If you are not yet sure what a PO's day looks like, start with What a Product Owner actually does every day.
Why are PO, PM and BA so easy to confuse?
First, the three names are not the same kind of thing. Product Owner (PO) comes from Scrum. The 2020 Scrum Guide calls the PO one of the three accountabilities of a Scrum Team. The PO is accountable for maximising the value of the product the team produces, and is one person, not a committee. Product Manager (PM) and Business Analyst (BA) are job titles, with no single rulebook defining them.
Second, the work genuinely overlaps. IIBA, the professional association for business analysts, defines business analysis as enabling change in an organisation by defining needs and recommending solutions that deliver value. IIBA itself lists Product Manager and Product Owner among the titles that do business analysis work. In other words, good POs and PMs analyse, and good BAs think about value.
Third, every company divides the work its own way. A Scrum.org article on PO and PM notes that in larger companies the PM often handles market research and strategy while the PO focuses on the backlog and the development team. The same article warns of a common failure: limiting the PO's authority until they become a backlog administrator.
In Vietnam the picture has more layers, because several company models sit side by side: outsourcing firms building for overseas clients, companies with their own product, startups, and large organisations, including some banks, that use Agile in some teams. The same “PO” label can hand you very different work in each.
How do Product Owner, Product Manager and Business Analyst differ?
The table describes the core of each role when the roles are clearly split. In practice one person may cover two or all three, but knowing the core helps you see which role you are really doing.
| Criterion | Product Owner | Product Manager | Business Analyst |
|---|---|---|---|
| Focus | Product value sprint by sprint, the order of the team's work | Why and what: market, strategy, product direction | Needs and requirements: current state, processes, business rules |
| Typical outputs | Product Goal, ordered backlog, user stories, acceptance criteria | Vision, roadmap, market analysis, business goals | Specifications, process diagrams, use cases, user stories |
| Works most with | Developers, designers, internal stakeholders | Leadership, sales, marketing, customers | Clients or business teams, developers, QA |
| Main decisions | Backlog order, scope of each release | Product direction, which market, which problems are worth solving | Usually recommends, rarely makes the final call |
| Judged by | Whether what shipped created value | Business results and product growth | Whether requirements were right, complete and clear enough to avoid rework |
The row to remember is “Main decisions”. A BA usually clarifies and recommends. A PO decides the order and is accountable for value. A PM decides direction at a wider level. When you read about a role, ask what that person gets to decide, because that is where the three differ most.
Where does the line fall in different companies?
These are common patterns, not rules. Two companies of the same type can still split the work differently, so always check in the interview.
- Outsourcing firm: The client usually holds product decisions. The vendor's “PO” often works close to a BA: taking requirements, writing specs, guarding the contracted scope.
- Product company: It owns the product, so the PO or PM really decides priorities. At scale, the PM handles strategy, the PO the backlog, and a BA supports requirements.
- Small startup: One person often does all three: talks to customers, picks work, writes stories, reads the numbers. The title could be anything.
- Large enterprise or bank: BA is often a long-standing role. PO appears with an Agile transformation, sometimes as a renamed BA while decisions stay higher up.
For career switchers, no type is clearly better. Outsourcing trains you to clarify requirements and work with clients. A product company teaches you to make decisions and measure results. A startup lets you do everything, with less guidance. What matters is knowing what you will learn there.
How do you read a job description to find the real role?
One simple approach is to read the job description in four steps and ignore the title until the end.
- Hide the title: Read the responsibilities as if the role had no name
- Mark the verbs: Write, analyse, decide, set strategy
- Find who decides: Who sets priorities, who sets scope
- Find the measure: How success is judged
If the ad does not say who decides or how success is measured, write it down as an interview question.
When marking verbs, notice which group appears most. Phrases like “gather requirements”, “write specifications”, “map processes” and “confirm requirements with the client” point to BA work. Phrases like “manage and order the backlog”, “write user stories and acceptance criteria”, “work daily with the development team” and “join sprint planning” point to a PO. “Build the roadmap”, “market research”, “pricing” and “own business metrics” usually belong to a PM.
Finding who decides matters most. If the ad says “work with the client to finalise requirements”, the client decides. If it says “report to the Head of Product, who sets priorities”, the decision may sit above you. The Scrum Guide says that for a PO to succeed, the whole organisation must respect their decisions. If the ad shows nothing you get to decide, the role may be closer to BA than its title suggests.
Example: analysing the three ads
Back to the three ads you saved. The table is an illustrative analysis of fictional ads.
| Job ad | Signals in the description | Who sets priorities | Real role is closest to |
|---|---|---|---|
| Product Owner, outsourcing firm | Write specs, weekly client meetings, manage requirement changes under the contract | The client | BA, plus scope management |
| Business Analyst, product company | Manage the backlog, choose sprint features, follow feedback after launch | This role, with the team lead | PO |
| Product Manager, five-person startup | Talk to customers, write user stories, track numbers, propose direction | This role, with the founder | PM, PO and BA combined |
After the analysis, your ranking may flip. If your goal is to learn how to set priorities, the “Business Analyst” ad at a product company may be closer to PO work than the ad that literally says “Product Owner”. If you want to build requirement skills first, the outsourcing role is a sensible stepping stone.
Do not write any ad off too quickly either. A PO role at an outsourcing firm can still carry real authority if the client trusts the team. The table gives you questions to ask, not the employer's answers.
Should you choose PO, PM or BA?
No role is above another. The better question is what you want to be accountable for. Go through these questions in order and stop at the first one you answer “no”.
You want to work close to the product and the development team
- Do you enjoy turning a vague request into a precise description? QA, design or operations may suit you better. Try a small project before deciding.
- Can you handle ordering work and saying no to people? BA is a sensible start: you clarify and recommend, someone else decides.
- Do you want to answer for results after launch? A BA role in an Agile team, or one supporting a PO, is a sensible step: you make small calls and build up your comfort with data.
- Do you want to think about market, strategy and business results? PO fits best right now: set priorities with the team and measure value release by release.
PM is worth aiming for, usually after experience as a PO or doing product work in a startup.
If you come from design, much of the problem-framing skill is already there; From designer to Product Owner covers what to add. If you come from BA, the hardest part is usually prioritising when everything is urgent and saying no without damaging relationships.
Checklist for analysing a job ad
Copy this checklist into your notes and fill in one copy per ad. The last part lists interview questions for anything you could not fill in.
Ad: [company or ad reference] | Advertised title: [ ] 1. Type of company [ ] Outsourcing [ ] Product company [ ] Startup [ ] Large enterprise [ ] Unclear 2. Most frequent verbs (copy 5 phrases) - - - Leans towards: [ ] BA (clarify, specify) [ ] PO (backlog, sprint, team) [ ] PM (strategy, market, metrics) 3. Who decides [ ] Who sets priority order: [ ] Who sets the scope of each release: [ ] Who this role reports to: 4. Measure of success [ ] Does the ad say how success is measured: [ ] Is it about finishing work, or results after launch: 5. Who you work with daily [ ] Clients [ ] Developers [ ] Leadership [ ] Sales, marketing [ ] Operations Conclusion: the real role is closest to [ ], and differs from the title in [ ]. Interview questions (for the empty boxes): - When two requests are equally urgent, who decides which goes first? - Could you describe a recent decision someone in this role made? - After a feature ships, how does the team know it succeeded? - How does someone in this role usually spend a week?
“Describe a recent decision” usually tells you the most. If the interviewer can recall a time this role dropped a feature or reordered the backlog, the authority is real. If the answer is all documents and meetings, the role may lean towards BA.
Common misunderstandings
- Choosing by title. “Product Owner” in an ad does not guarantee you will set priorities. Read the responsibilities and ask who decides.
- Assuming PM is above PO, or PO is above BA. In many places they are three different accountabilities, not three rungs of a ladder. Some companies have PMs managing POs; others do not.
- Thinking BAs only write documents. A good BA understands why a requirement exists and recommends solutions that deliver value. That is also a strong base for moving into PO work.
- Getting a certificate before understanding the work. A certificate can help you learn the framework, but employers usually ask how you clarified a problem and made a decision. A small case study with clear reasoning helps you answer that.
- Skipping writing skills. Whatever the role, you still need user stories and acceptance criteria clear enough for the team to build from.
Summary
- Product Owner is an accountability in Scrum: maximise product value and order the backlog. PM and BA are job titles.
- The core difference is decision rights: a BA clarifies and recommends, a PO decides order and answers for value, a PM sets wider direction.
- The lines move by company type: outsourcing firms, product companies, startups and large enterprises split the work very differently.
- Read job ads in four steps: hide the title, mark the verbs, find who decides, find the measure. Ask about anything left blank in the interview.
- Choose a role by what you want to be accountable for, not by its name.
I am writing more PO situations in this same format, with templates you can use straight away. If you would like the next one by email, subscribe to the newsletter below.
Frequently asked questions
Is Product Owner a job title?
In the Scrum Guide, Product Owner is an accountability, not a job title: the person accountable for maximising product value and managing the backlog. In practice many companies also use it as a title, so the same name can describe quite different jobs.
Can a Business Analyst become a Product Owner?
Yes, and it is a common move because BAs already clarify requirements, write user stories and work closely with developers. What they need to add is making priority calls, saying no, and answering for results after launch.
Should a beginner choose PO, PM or BA?
Choose by what you want to be accountable for, not by the title. If you enjoy clarifying and describing precisely, BA fits; if you enjoy ordering work with a delivery team, PO fits; if you enjoy market, strategy and business outcomes, PM fits.
Sources to check
Related articles
- Your first 30 days as a Product Owner: what to do each week: A four-week plan for a new PO: listen and map, understand users and metrics, own a small slice of the backlog, then make a first decision and agree expectations with your manager.
- Can you be a Product Owner without coding?: A PO does not need to write code, but does need enough technical literacy to ask good questions, respect the Developers' ownership of “how”, and talk about trade-offs clearly.
- From BA, QA or developer to Product Owner: what to learn?: Which BA, QA and developer strengths carry over to the PO role, which blind spots to watch, and how to build PO experience inside your current job.
- Product Owner interview questions: answer with real situations: The kinds of questions in a PO interview, how to answer with a concrete situation, what to do when you do not know, and what to ask the interviewer.