Untangling Product Roles: PM vs PO and Everyone They're Confused With

[
  {
    "__component": "shared.rich-text",
    "id": 360,
    "body": "If you’ve ever stared at a job spec wondering whether a Product Owner is just a Product Manager in disguise - or why one company needs a PM, PO, BA and a Program Manager for the same product - you’re not alone. The world of product roles is notoriously fuzzy. Titles overlap. Agile purists argue. And in the real world, teams just try to ship.\n\nThis post is your no-nonsense guide to what these roles really mean - not in theory, but in practice. We’ll break down the core responsibilities of Product Managers and Product Owners, explore where roles like Business Analyst, Project Manager, Product Marketing Manager, and Product Designer come in, and pull in real job descriptions from companies like Meta, Atlassian, and Google to show how it plays out in the wild.\n\n## 1. Why This Gets Confusing\n\nProduct development is a team sport, but the playbook varies dramatically by company. What one org calls a \"PM,\" another splits into two roles. Titles are used inconsistently across regions and industries, and sometimes they’re shaped more by HR conventions than actual job scope.\n\nSome common causes of confusion:\n\n- **Agile theory vs reality:** In theory, the Product Owner is a Scrum-specific role focused on backlog management. In practice, many companies use \"PO\" as a job title and give them strategic responsibilities.\n- **Company maturity:** Startups tend to favour generalist PMs. Enterprises split responsibilities across specialised roles.\n- **Location bias:** In the UK and Europe, \"Product Owner\" is more widely used; in the US, \"Product Manager\" is dominant.\n- **Org chart politics:** Some roles exist as stepping stones, legacy positions, or placeholders for more strategic functions.\n\n## 2. Defining Product and Product-Adjacent Roles\n\n**What is a Product Manager (PM)?**\nProduct Managers are responsible for defining the product vision and strategy. They focus on the \"why\" and \"what\" — why something needs to be built, and what the right solution looks like. PMs are typically outward-facing, engaging with customers, executives, stakeholders, and data to identify problems worth solving. They craft roadmaps, prioritise opportunities, and define what success looks like. A strong PM aligns business goals with user needs and empowers the team to build the right thing.\n\n**What is a Product Owner (PO)?**\nProduct Owners are responsible for delivering the product the PM envisions. They focus on execution — turning strategic goals into actionable user stories and sprint-ready tasks. POs manage the backlog, work closely with engineers day-to-day, write acceptance criteria, and ensure delivery stays on track. In Scrum, the PO is a defined role on the team, but in practice, it's often a title assigned to someone filling the gap between vision and implementation. Their superpower is clarity and responsiveness.\n\n### Other Product-Adjacent Roles Explained\n\nTo properly understand the ecosystem around PMs and POs, it's important to also define the adjacent roles that commonly get confused, blurred, or folded in. These aren't just job titles — they're critical functions that affect how smoothly product development runs. The following sections break down each of these roles clearly, starting with a narrative definition, followed by a structured comparison table to clarify responsibilities and collaboration points.\n\n**What is a Business Analyst (BA)?**\nBAs are the translators of business requirements. They gather detailed inputs from stakeholders and ensure the delivery team understands exactly what’s being asked. BAs excel in digging into edge cases, logic flows, and dependencies. In orgs without POs, they often step into that delivery detail gap.\n\n**What is a Project Manager?**\nWhile product roles define what to build, Project Managers make sure it gets delivered on time and on budget. They manage timelines, risks, and resource planning — particularly across dependencies. They are especially critical when delivering products that span multiple departments or cross-functional teams, as they take on the coordination role that keeps all moving parts aligned. Often underappreciated in Agile circles, but vital in high-stakes, multi-team environments.\n\n**What is a Program Manager?**\nProgram Managers are the glue across teams. They don’t own a product directly but ensure large, cross-functional initiatives stay coordinated. Think of them as orchestrating multiple PMs working toward a common business goal.\n\n**What is a Product Marketing Manager (PMM)?**\nProduct Marketing Managers are responsible for connecting the dots between the product and the market. Once the product is built, they ensure the right customers know about it, understand its value, and are compelled to act. PMMs own the go-to-market strategy, working on everything from messaging and positioning to competitor research and sales enablement. They collaborate closely with PMs to understand the product vision, and with sales and customer success teams to ensure consistent, compelling communication. As product organisations mature, this role becomes increasingly critical — especially for driving adoption, user education, and successful launches across channels.\n\n**What is a Product Designer?**\nProduct Designers are responsible for shaping the user experience of a product — not just its visual design, but how it works and feels. They explore user journeys, map flows, sketch early concepts, create wireframes and interactive prototypes, and run usability tests to validate solutions before engineering effort is spent. A good designer doesn’t just make things beautiful — they deeply understand user problems and constraints, working as a creative problem solver to craft functional, elegant solutions. In modern product teams, designers are partners to PMs and engineers from ideation through delivery, often influencing product direction as much as anyone on the team.\n\n**What is an Associate Product Manager (APM)?**\nAPMs are early-career PMs often placed on smaller features or tasks. It’s a training ground, and they usually report to a more senior PM or work alongside a PO. Great APM programs help grow well-rounded future PMs.\n\n**What is a Sales Engineer or Product Specialist?**\nThese are the frontline experts who bridge product and customer during pre-sales. They demo solutions, handle technical objections, and relay real customer feedback to PMs. Sometimes overlooked in product feedback loops — unfairly so.\n\n**What is a Product Analyst?**\nProduct Analysts specialise in making sense of product data — usage patterns, user behaviour, conversion funnels, and retention trends. They help product teams make informed decisions by transforming raw data into actionable insights. This role often sits at the intersection of product, data, and design, providing analysis to support discovery, prioritisation, and iteration. While not every team has a dedicated analyst, having one can be a game changer for evidence-based product development. They often work closely with PMs, designers, and marketing to uncover opportunities, measure outcomes, and spot problems early.\n\nHere's a quick reference table for other roles that often get conflated with PMs and POs:"
  },
  {
    "__component": "shared.rich-text",
    "id": 361,
    "body": "| Role                                     | Primary Focus                  | Common Activities                                      | Works Closely With              |\n|------------------------------------------|--------------------------------|--------------------------------------------------------|----------------------------------|\n| **Product Manager (PM)**                | Strategy, vision, customer needs | Define roadmap, prioritise features, stakeholder alignment | PO, Designers, PMMs, Engineers   |\n| **Product Owner (PO)**                  | Backlog ownership, sprint delivery | Write user stories, groom backlog, clarify dev requirements | PM, Devs, QA, BAs                |\n| **Product Analyst**                     | Product usage and insights     | Analyse funnels, retention, user behaviour             | PMs, Designers, Data Teams       |\n| **Business Analyst (BA)**               | Requirements, process detail   | Translate business needs into detailed specs           | PO, Dev, QA                      |\n| **Project Manager**                     | Scope, timeline, budget        | Scheduling, risk management, dependency tracking       | PO, Engineering                  |\n| **Program Manager**                     | Multi-team coordination        | Align cross-functional efforts across initiatives      | PMs, Leadership, Ops             |\n| **Product Marketing Manager (PMM)**     | Go-to-market strategy          | Messaging, launches, positioning, market research      | PMs, Marketing, Sales            |\n| **Product Designer**                    | User experience                | Wireframes, research, prototyping, usability testing   | PMs, Engineers, Users            |\n| **Associate Product Manager (APM)**     | PM support / training          | Smaller features, assist on research or tickets        | PM mentor, PO                    |\n| **Sales Engineer / Product Specialist** | Pre-sales technical context    | Demos, customer needs gathering, feedback loop         | PMs, PMMs, Sales                 |\n"
  },
  {
    "__component": "shared.rich-text",
    "id": 362,
    "body": "These roles all play a part in delivering a great product. But lumping them together under the “product” label dilutes their value and creates misalignment.\n\n## 3. The Core Distinctions\n### Product Manager vs Product Owner\n\nLet’s get to the heart of it: what’s the real difference between a Product Manager and a Product Owner?\n\n| Role                 | Focus                         | Responsibilities                                                                 | Core Outputs                                         |\n|----------------------|-------------------------------|----------------------------------------------------------------------------------|------------------------------------------------------|\n| **Product Manager (PM)** | Strategy, vision, customer needs | Define the \"why\" and \"what\"; create roadmap; prioritise based on business goals; speak to users and stakeholders | Product strategy, roadmap, validated problem statements |\n| **Product Owner (PO)**   | Delivery, team facilitation     | Own the backlog; write user stories; ensure the \"how\" is clear for the dev team; unblock implementation           | Groomed backlog, acceptance criteria, team alignment   |\n\n**PM = direction. PO = execution.**\n\nIn practice, the roles often overlap or blur. In smaller orgs, one person may do both. This was my experience working in startups, where I was often titled a Product Owner, and later a Product Manager as the organisation matured. Despite the change in title, I always covered both strategy and execution. In larger organisations, I worked solely as a Product Manager — there were no dedicated Product Owners or Business Analysts. As a result, PMs were still the primary liaison with developers, but the developers often wrote their own tickets based on conversations or rough direction. It was evident that product thinking was still emerging, and the concept of a PO — someone who owns the delivery layer and shapes sprint-ready work — wasn’t well understood or valued yet. That experience reinforced my belief that the role of either a PO or a BA is always necessary, whether as a distinct person or folded into another role, to ensure development teams are truly enabled to succeed."
  },
  {
    "__component": "shared.rich-text",
    "id": 363,
    "body": "### Product Owner vs Business Analyst\n\nWhile Product Owners and Business Analysts both support the delivery side of the product process, their focus and responsibilities differ.\n\n| Role               | Focus                             | Responsibilities                                                                 | Core Outputs                        |\n|--------------------|-----------------------------------|----------------------------------------------------------------------------------|-------------------------------------|\n| **Product Owner (PO)** | Backlog ownership, sprint execution | Define and prioritise backlog; act as point of contact for devs; clarify scope and unblock tasks | Groomed backlog, sprint-ready tickets |\n| **Business Analyst (BA)** | Requirements analysis, logic and process clarity | Gather and refine requirements; map process flows; handle edge cases and data rules | Process flows, detailed requirement docs |\n\nBAs thrive in environments where clarity and detail matter — think integrations, workflows, or high-compliance products. POs own delivery momentum and prioritisation. The two roles complement each other when paired, but in some orgs, the PO absorbs the BA function entirely, especially in a smaller organisation where teams are leaner and every role needs to stretch to cover delivery depth. Personally, I’ve never chosen roles that work with a BA, as my style of being a PO has always meant I cover most of the BA responsibilities. I write detailed stories that include edge cases, data flow considerations, and the technical implications of implementation. That’s just how I’ve always worked — and I’ve often felt that having a dedicated BA alongside me might result in overlapping effort or stepping on toes. That said, I think if you have a traditional PM who stays at the strategic or vision level, then a PM/BA pairing can work almost as well as a PM/PO combo. But in my view, a PM/PO combo is the star setup — because both roles are focused on ensuring that what we’re creating is genuinely the right thing to put out for the user or end customer."
  },
  {
    "__component": "shared.rich-text",
    "id": 364,
    "body": "### Product Manager vs Project Manager vs Program Manager\n\nThese roles are often confused because they all involve planning and alignment — but the scopes are quite different.\n\n| Role               | Focus                              | Responsibilities                                                  | Core Outputs                                 |\n|--------------------|------------------------------------|-------------------------------------------------------------------|----------------------------------------------|\n| **Product Manager (PM)** | Product strategy, customer outcomes | Define product vision, prioritise work, engage users/stakeholders  | Roadmap, goals, validated opportunities       |\n| **Project Manager**     | Scope, time, budget               | Coordinate tasks, mitigate risks, manage delivery timelines        | Project plans, Gantt charts, risk logs        |\n| **Program Manager**     | Strategic alignment, multi-team initiatives | Orchestrate cross-team work, align timelines and goals across programs | Initiative plans, reporting cadences          |\n\nPMs focus on building the right thing. Project and Program Managers ensure the thing gets delivered well — and when roles are clear, they’re powerful allies."
  },
  {
    "__component": "shared.rich-text",
    "id": 365,
    "body": "### Real-world examples of how companies structure product roles:\n- At **Atlassian**, Product Managers focus on product vision, user problems, and go-to-market plans. The title \"Product Owner\" is rarely used — PMs are expected to own both strategy and delivery, often working closely with engineers to manage execution.\n- At **Spotify**, the product team is famously decentralised into squads and tribes. Each squad has a PM who works closely with a Tech Lead. There’s no formal PO title — instead, squads are empowered to manage delivery themselves with heavy autonomy.\n- At **Amazon**, Product Managers are expected to be highly technical and customer-obsessed. POs are not formally recognised in most teams — PMs often write their own user stories and drive delivery end-to-end.\n- At **Salesforce**, PM and PO roles are more distinct. PMs handle roadmap, vision, and strategy, while POs (sometimes titled \"Technical Product Managers\") translate that strategy into stories and work with engineers closely during sprints.\n- At **Capgemini** and similar consultancies, you’ll often find Business Analysts and Product Owners embedded with delivery teams, while Product Managers sit client-side or further up in strategic roles. This reflects a more enterprise-style split of responsibility.\n- At **ING**, the Dutch bank, Product Owners are a standard part of their Agile delivery teams. They operate at the squad level, focusing heavily on backlog prioritisation, aligning delivery with the customer journey, and ensuring teams can move fast within regulatory constraints. PMs at ING are more rare, with POs handling much of the day-to-day decision-making and refinement.\n- At **Aviva**, Product Owners are widely used across digital teams. They act as the primary liaison between business stakeholders and engineering, with a strong focus on backlog clarity, customer journey alignment, and compliance. PMs exist too, though they’re more likely to focus on portfolio-level priorities and commercial direction.\n- At **BT Group**, you’ll find PMs, POs, and Project Managers all working in parallel. PMs define long-term product strategy and goals; POs translate those into sprints; and Project Managers drive delivery across multiple dependencies, particularly where physical infrastructure or legacy systems are involved.\n- At **Nationwide**, a typical Agile team will include both a PO and a BA. The PO owns delivery direction and prioritisation, while the BA handles requirement discovery and detailed acceptance logic. This pairing works well in regulated industries where stakeholder assurance and traceability matter."
  },
  {
    "__component": "shared.rich-text",
    "id": 366,
    "body": "## 4. Technical vs Non-Technical PMs and POs\nNot all PMs write code. Nor should they. But what does \"technical\" really mean?\n\nIn my experience, the definition of a \"**technical PM**\" varies by company. In some places, it refers to someone who comes from an engineering background, not necessarily someone who actively contributes code. In others, especially more mature or infrastructure-heavy environments, it simply means a PM who can operate effectively in technically complex domains — such as platform teams — even without writing code themselves.\n\nA technical PM in this context doesn't need to build the system, but they must be comfortable handling conversations around infrastructure, deployment, scalability, and architectural trade-offs. Personally, I’ve often found myself in these types of roles. I’ve always been able to follow and participate in discussions about things like Kubernetes clusters, polyrepo vs monorepo setups, or how to leverage CI/CD pipelines to support testing environments per feature. That interest and comfort allowed me to work effectively in high-tech teams long before I began actively developing in the last couple of years.\n\nSo while you don’t need to have a technical background, you do need to have a strong technical curiosity — and ideally a willingness to learn. \n\nA **non-technical PM** may come from UX, marketing, or general business backgrounds — or like me, from none of these. I originally didn’t have a technical background at all. While non-technical PMs may not always contribute to technical architecture, they bring deep user focus and strategic thinking. They're often strongest when paired with empowered tech leads — but in my experience, if you’re not coming from a technical background, a sustained technical interest is the bare minimum.\n\nBoth can succeed. The key is knowing the context:\n\n- In a product-led growth company, empathy and storytelling may matter more than tech.\n- In a company where the tech product is the software you are selling, your PM should know how to interpret an API response.\n\n## 5. How These Roles Work Together\n\n"
  },
  {
    "__component": "shared.media",
    "id": 63,
    "file": {
      "id": 115,
      "documentId": "sdblz148pwpz9956t1yvvtdk",
      "name": "product-roles-responsibilities-venn-pm-po-ba-pmm-designer.png",
      "alternativeText": "Venn diagram showing shared product responsibilities across team roles",
      "caption": null,
      "width": 1014,
      "height": 706,
      "formats": {
        "thumbnail": {
          "ext": ".png",
          "url": "https://res.cloudinary.com/dmkbljcg2/image/upload/v1747760489/thumbnail_product_roles_responsibilities_venn_pm_po_ba_pmm_designer_668349f75b.jpg",
          "hash": "thumbnail_product_roles_responsibilities_venn_pm_po_ba_pmm_designer_668349f75b",
          "mime": "image/png",
          "name": "thumbnail_product-roles-responsibilities-venn-pm-po-ba-pmm-designer.png",
          "path": null,
          "size": 4.52,
          "width": 224,
          "height": 156,
          "sizeInBytes": 4516,
          "provider_metadata": {
            "public_id": "thumbnail_product_roles_responsibilities_venn_pm_po_ba_pmm_designer_668349f75b",
            "resource_type": "image"
          }
        }
      },
      "hash": "product_roles_responsibilities_venn_pm_po_ba_pmm_designer_668349f75b",
      "ext": ".png",
      "mime": "image/png",
      "size": 50.42,
      "url": "https://res.cloudinary.com/dmkbljcg2/image/upload/v1747760489/product_roles_responsibilities_venn_pm_po_ba_pmm_designer_668349f75b.jpg",
      "previewUrl": null,
      "provider": "cloudinary",
      "provider_metadata": {
        "public_id": "product_roles_responsibilities_venn_pm_po_ba_pmm_designer_668349f75b",
        "resource_type": "image"
      },
      "createdAt": "2025-05-20T17:01:29.958Z",
      "updatedAt": "2025-05-20T17:01:29.958Z",
      "publishedAt": "2025-05-20T17:01:29.958Z"
    }
  },
  {
    "__component": "shared.rich-text",
    "id": 367,
    "body": "Let’s map it:\n- **PM** defines the customer problem and success criteria.\n- **PO** translates that into sprint-ready work.\n- **BA** fills in logic and edge cases.\n- **Designer** explores and validates solutions.\n- **Dev team** builds it.\n- **Project Manager** ensures it ships on time.\n- **Program Manager** ensures it aligns with bigger company goals.\n- **PMM** ensures customers know and want it.\n- **Sales/Product Specialist** gives feedback from the field.\n- When this works well, everyone is rowing in the same direction. When roles are unclear, it leads to duplicated effort, strategic drift, or delivery chaos.\n\n## 6. Common Misconceptions\n- \"A PO is just a junior PM\" — Not true. They have different scopes and operate at different levels of product execution.\n- \"BA and PO are the same\" — BAs focus on analysis; POs focus on prioritisation and delivery. The roles can complement each other, but they solve different problems.\n- \"Agile makes Project Managers obsolete\" — Only if you misunderstand both. Project Managers can still add critical value around risk, budget, and cross-team coordination.\n- \"Technical PMs must know how to code\" — Not really. In most environments, a technical PM is someone who can operate confidently in technically complex spaces - not someone writing code, but someone who can parse an API response, understand architectural diagrams, and ask the right questions during engineering discussions. If you're not from a technical background, you don't need to fake it — but you do need to be curious, open, and willing to build literacy over time."
  },
  {
    "__component": "shared.rich-text",
    "id": 368,
    "body": "If you're building product, your title matters less than your actual responsibilities. But understanding these roles is essential to hiring well, working well together, and advancing in your career.\n\nProduct isn't one job — it's a network of complementary roles. PMs and POs are the centre of that web, but they aren't the whole story. The best teams are clear on the boundaries, but even clearer on the collaboration."
  }
]