Before any developer writes code and before any tester runs a test case, three people have already been in a room arguing about what should be built, in what order, and by when. Meet the PM, the BA, and the PO — the architects of your backlog.
Learning Objectives
By the end of this lesson you will be able to:
- Explain the distinct purpose of each role: Business Analyst, Product Owner, and Project Manager
- Understand who to contact when requirements are unclear, when priorities shift, or when deadlines are at risk
- Recognise how all three roles interact with QA
Business Analyst (BA) — The Requirement Translator
The Business Analyst bridges the gap between what the business wants and what the development team can build. They sit in meetings with stakeholders, ask uncomfortable questions ("What does 'fast' mean? In milliseconds?"), and transform vague business needs into precise, testable requirements.
What a BA produces:
- Functional requirements documents
- Use cases and user stories
- Acceptance Criteria for tickets
Their relationship with QA: The BA writes the Acceptance Criteria. The QA engineer tests against them. If the AC is ambiguous, both parties suffer — so a good QA engineer reads every requirement looking for gaps before a single line of code is written.
Pro Tip: When you receive a ticket with unclear Acceptance Criteria, the BA is your first call. Never assume what "correct" means.
Product Owner (PO) — The Product's Champion
The Product Owner owns the product backlog — the master prioritised list of everything that needs to be built. They represent the voice of the customer and the business inside the development team.
What a PO decides:
- Which features go into the next sprint
- What the product vision is (the "north star")
- Whether a delivered feature actually meets business goals
Their relationship with QA: The PO ultimately accepts (or rejects) completed features. If you find a bug that doesn't violate the Acceptance Criteria but does violate common sense, it's the PO who decides if it's a real defect or "working as intended."
Common confusion: The PO is not the BA. The PO prioritises what gets built. The BA defines what it should do. They often work closely together, but they have distinct responsibilities.
Project Manager (PM) — The Schedule Guardian
The Project Manager ensures the team delivers on time, within budget, and within scope — the eternal triangle of project management. They don't define what gets built; they make sure it gets built.
What a PM manages:
- Sprint timelines and release dates
- Risk identification and mitigation
- Stakeholder communication (keeping executives informed without alarming them)
- Removing obstacles for the team
Their relationship with QA: The PM will ask QA for estimates on testing effort, status updates, and — most critically — for a "go/no-go" signal before a release. Your professional judgment directly affects whether a product ships.
Reality check: In smaller companies, one person often wears two or even all three hats. A "Product Manager" at a startup might be BA + PO + PM combined. That's normal. Understanding the function of each role matters more than memorising the org chart.
How They Work Together
Business Analyst → defines requirements
↓
Product Owner → prioritises requirements into a backlog
↓
Project Manager → ensures the team builds the backlog on schedule
↓
Developers + QA → build and verify it
When requirements are wrong, the BA is involved. When priorities shift, the PO decides. When the deadline is in danger, the PM acts.
Summary
| Role | Core Responsibility | Key output for QA |
|---|---|---|
| BA | Translates business needs into requirements | Acceptance Criteria |
| PO | Prioritises the backlog and owns the product vision | Sprint scope, acceptance decisions |
| PM | Manages timeline, risk, and stakeholder communication | Release schedule, go/no-go calls |
Now let's meet the people who actually build what these three decide on.