That meeting where everyone’s confused about who’s supposed to do what…

You know the scene. Sprint planning meeting. Someone mentions a bug that’s been sitting around for weeks. Everyone looks around the room like “whose job is this exactly?”

Product Owner thinks the Engineering Manager should handle it. Engineering Manager assumes the Scrum Master is tracking it. Scrum Master points to the Business Analyst. Business Analyst looks at the Project Manager. Project Manager shrugs.

And somewhere, a developer just wants to know if they should fix the damn thing or not.

1. The alphabet soup of roles (and why companies love creating them)

Let’s be real - most companies have way too many roles with overlapping responsibilities. But each one actually serves a purpose… when done right.

2. Product Owner (PO): The “What Should We Build” Person

Product Owners are basically the voice of the customer, except the customer isn’t in the room and probably doesn’t know what they want anyway.

What they actually do:

  • Stare at user feedback and try to figure out what features matter
  • Fight with stakeholders about priorities (spoiler: everything is “high priority”)
  • Write user stories that sound simple but hide complex edge cases
  • Say “no” to feature requests (the hardest part of the job)

Their superpower: Knowing what users actually need vs. what they say they want

Their kryptonite: When engineers ask “but HOW should this work exactly?”

3. Project Manager (PM): The “Are We There Yet” Person

Project Managers are like GPS for projects - constantly recalculating the route and telling everyone they’re running late.

What they actually do:

  • Track timelines that are always optimistic
  • Send status updates nobody reads but everyone expects
  • Manage budgets and resources (aka “we can’t hire more people”)
  • Be the bad guy when deadlines slip

Their superpower: Keeping chaos organized and making sure stuff actually ships

Their kryptonite: When scope creeps in through “small changes” that aren’t small

4. Business Analyst (BA): The “Why Are We Building This” Person

Business Analysts are like translators between the business world and the tech world. They speak both languages fluently.

What they actually do:

  • Figure out what the business actually needs (not what they think they need)
  • Document requirements in excruciating detail
  • Create flowcharts that make complex processes look simple
  • Ask “but what happens if…” for every possible scenario

Their superpower: Turning vague business requests into concrete technical requirements

Their kryptonite: When business users say “just make it work like the old system” but can’t explain how the old system works

5. Engineering Manager (EM): The “How Do We Build This” Person

Engineering Managers are like team captains who also happen to understand code. They’re stuck between keeping developers happy and keeping executives informed.

What they actually do:

  • Make technical decisions that won’t bite the team later
  • Fight for realistic timelines (usually unsuccessfully)
  • Help developers grow their careers and skills
  • Translate engineering complexity to non-technical people

Their superpower: Balancing technical excellence with business reality

Their kryptonite: When asked to estimate something that’s never been built before

6. Scrum Master (SM): The “How Are We Building This” Person

Scrum Masters are like referees in a game where half the players don’t know the rules and the other half are making up new ones.

What they actually do:

  • Run ceremonies that could have been emails (but actually serve a purpose)
  • Remove blockers (aka “meeting coordinator with a fancy title”)
  • Coach teams on agile practices
  • Shield developers from random interruptions

Their superpower: Making teams work better together

Their kryptonite: When organizations want “agile” but don’t want to change anything

7. The overlap problem (and why meetings get weird)

Here’s where it gets messy. In real life, these roles overlap more than anyone admits:

  • PO vs BA: Both gather requirements, but PO focuses on user value while BA focuses on business process
  • PM vs SM: Both track progress, but PM owns timeline/budget while SM owns team process
  • EM vs PM: Both manage delivery, but EM focuses on technical execution while PM focuses on project scope

8. What good role clarity looks like

Teams that have their act together usually work like this:

When a new feature request comes in:

  • BA figures out what business problem needs solving
  • PO decides if it’s worth building and prioritizes it
  • EM estimates technical complexity and resource needs
  • PM tracks timeline and budget impact
  • SM ensures the team has what they need to execute

When things go wrong:

  • SM identifies process issues
  • EM handles technical blockers
  • PM communicates impact to stakeholders
  • PO validates if the solution still meets user needs
  • BA documents lessons learned for next time

9. The reality check

Most companies don’t have all these roles clearly defined. Sometimes one person wears multiple hats. Sometimes roles are combined. Sometimes there’s just confusion.

The key isn’t having perfect role definitions - it’s making sure someone owns each responsibility and everyone knows who that someone is.

⚡ TL;DR

Good teams don’t argue about whose job something is. They figure out who’s best positioned to handle it and move on. Role clarity isn’t about building bureaucracy - it’s about building products that don’t suck.