One of the most confusing things about product management is that the title “Product Manager” can mean completely different things at different companies. I have seen PMs who write SQL queries all day and PMs who never open a database. PMs who own pricing and PMs who have never seen a revenue number. Same title. Different jobs entirely.
If you are trying to break into product management, this is disorienting. If you are a hiring manager, it is a recipe for mismatched expectations. This article maps the major product roles, what each one actually owns, and how they differ across company stages.
Product Manager (PM)
The core role. A PM owns the what and the why — deciding what to build, for whom, and why it matters. They do not own the how (that is engineering) or the when (that is a negotiation).
At a startup, a PM does everything: customer interviews, writing specs, prioritizing the backlog, analyzing data, coordinating launches. At a large enterprise, the role is more specialized — a PM might own a single feature area and spend most of their time aligning stakeholders.
The one constant across contexts: a PM is responsible for outcomes, not output. Shipping features is not the goal. Solving customer problems in ways that serve the business is the goal.
Product Marketing Manager (PMM)
PMMs own the story. While PMs figure out what to build, PMMs figure out how to explain it — positioning, messaging, competitive differentiation, and launch strategy.
The handoff between PM and PMM is one of the most important (and most neglected) partnerships in a product organization. A PM who ships a feature without involving PMM gets a technically correct product that nobody understands. A PMM who positions a product without understanding the PM’s intent gets beautiful messaging that misrepresents the product.
At smaller companies, the PM often handles both roles. This works until it does not — usually around the time you start losing deals because prospects cannot understand your value proposition in under 30 seconds.
Product Owner (PO)
The PO role comes from Scrum. In theory, the Product Owner manages the backlog, writes user stories, and ensures the development team always has clear work ahead of them.
Marty Cagan at SVPG has written extensively about this confusion — his piece on Product Manager vs. Product Owner describes how organizations conflate two very different responsibilities. In practice, PO and PM overlap significantly, and the distinction varies by company. Some organizations use them interchangeably. Others draw a clear line: the PM sets the strategy and the PO executes it in sprint-level detail. Neither approach is wrong — the important thing is that everyone on the team knows who makes which decisions.
In my experience, companies that have both a PM and a PO for the same product often struggle with unclear ownership. If you are setting up a product organization, pick one model and be explicit about decision rights.
Technical Product Manager (TPM)
Technical PMs own platform capabilities, APIs, infrastructure, and developer-facing products. They sit closer to engineering than to customers and often have an engineering background themselves.
The distinguishing feature of a TPM is who their “customer” is. For a traditional PM, the customer is an end user. For a TPM, the customer might be internal engineering teams, third-party developers, or data scientists. The work is less about user experience and more about system architecture, API design, and technical scalability.
If your company builds a platform that other products are built on, you need TPMs. If you are an aspiring PM with an engineering background, this is often the most natural entry point.
Growth PM
Growth PMs focus on acquisition, activation, and retention — the levers that drive user growth. They tend to be more data-driven than feature-oriented, running experiments at high velocity and making decisions based on statistical significance rather than customer interviews.
The Growth PM role is most common at consumer companies and product-led growth B2B companies where small improvements in conversion rates translate directly to revenue. At a company where growth depends on enterprise sales, you are less likely to see this role.
How Roles Change With Company Stage
At a 10-person startup, one person is the PM, the PMM, the PO, and half the growth team. At a 1,000-person company, these are separate roles with separate career ladders.
Understanding this is important for two reasons. First, if you are hiring, match the role to your stage. A PM from a large enterprise who is used to deep specialization may struggle at a startup that needs a generalist. The reverse is equally true.
Second, if you are building a career, know which skills transfer across roles. Customer empathy, communication clarity, and data literacy matter in every product role. Sprint planning skills are more PO-specific. Messaging and positioning are PMM-specific.
An Example: How DataBridge Structures Its Team
DataBridge, a fictional mid-stage B2B analytics company (80 employees), has three product squads. Each squad has a PM who owns strategy and customer research, and a PO who translates that into sprint-ready work. They have one PMM who covers all three squads — positioning, launch plans, and sales enablement. Their platform team has a TPM who owns the API and data pipeline. There is no Growth PM because their sales motion is enterprise-driven.
At 200 employees, they will probably split the PMM role into two and add a Growth PM for their self-serve tier. The structure evolves with the business.
How to Use With AI
AI can help you think through role design for your specific context.
Design a role matrix. Describe your company stage, product, and team size to Claude or ChatGPT. Ask: “What product roles do I need, and what should each one own? Where will responsibilities overlap?” The AI will surface common patterns and potential conflicts.
Write better job descriptions. Paste a draft JD into an AI and ask: “Does this describe a PM, a PO, or a PMM? Are the responsibilities clear and internally consistent?” Most job descriptions accidentally describe two different roles. AI is good at catching that.
The guardrail: AI can suggest role structures based on patterns. It cannot account for your company’s culture, politics, or the specific humans involved. Org design is ultimately about people, not org charts.
Why This Matters
Getting product roles right is a Platform-phase decision in the 5Ps framework with Product-phase consequences. If you hire the wrong type of PM for your stage, you get misaligned expectations and underperformance — not because the person is bad, but because the role does not match the work.
If you are an aspiring PM, understanding the full picture helps you target the right role for your strengths. If you are a hiring manager, it helps you write job descriptions that attract the right candidates. And if you are a PM trying to explain your job to your parents, you can now say “it depends on the company” with specificity.
What do you think? I would love to hear how your company structures product roles. Comments are gladly welcome.