Job titles in software product teams are confusing. The same title can mean different things at different companies, and different titles often describe nearly identical work. This ambiguity isn’t just a terminology issue — it directly affects hiring, collaboration, and how teams are composed.
Once you accept that titles vary, a more useful question emerges: what work actually has to get done, regardless of who carries the title? The product manager role becomes clearest when you look past labels and study three things in sequence: why titles vary, what the underlying spectrum of responsibility looks like, and where the PM sits within it. Each of those lenses reveals a different aspect of product management as a discipline.
This article works through all three. The conclusion is one most experienced PMs eventually reach: the unique difficulty of the product manager role isn’t the breadth of work, but the fact that PMs are accountable for outcomes they cannot directly produce.
Why Job Titles Vary So Much in Product Teams
Product team titles vary for a simple reason: the scope of work assigned to each person depends on organizational context.
A resource-rich enterprise can afford to hire specialists for every function. A single team might include a dedicated user researcher, a product analyst, a UX designer, a UI designer, and a PM — five separate people for what is essentially one product discovery and definition workflow. A lean startup, by contrast, may ask one or two people to cover all five functions. Neither setup is inherently right or wrong. What matters is whether the necessary work gets done, not how it’s divided across people.
Consider a restaurant kitchen. A Michelin-starred restaurant employs a sous chef, saucier, pâtissier, garde manger, and others — each with a narrow, specialized role. A neighborhood diner has one cook who handles everything. The quality of the food doesn’t depend on how many roles exist; it depends on whether every step of the cooking process happens reliably. Product teams work the same way.
This is why two people with the same title can have radically different day-to-day work. A “Product Manager” at a large enterprise may spend their week on cross-team coordination and stakeholder alignment. A “Product Manager” at an early-stage startup may write specs, run user interviews, manage the roadmap, and handle customer support tickets — all in the same week. Same title, different jobs. The title tells you almost nothing about the scope of work; the company context tells you almost everything.
The Spectrum of Role Scope: From Narrow to Broad
A more useful mental model is to stop treating job titles as fixed categories and start treating them as points on a spectrum of responsibility.
From narrow to broad scope
The same family of work shows up under different titles depending on how wide the role is drawn:
| Narrow scope | → | Broad scope |
|---|---|---|
| UI Designer | UX Designer | Product Designer |
| Frontend Engineer | Fullstack Engineer | Product Engineer |
As the scope widens, each role covers more of the end-to-end product development process. A UI designer focuses mainly on visual implementation. A product designer may own research, interaction design, visual design, and usability testing — all under one title. Neither role is “better”; they suit different team sizes and operating models.
A useful analogy is musicians. Some violinists specialize and play only the violin at the highest level. Others — common in small bands or chamber groups — play violin, viola, and piano. An orchestra benefits from specialists. A four-piece band benefits from multi-instrumentalists. The right scope depends on the size and shape of the ensemble, not on which approach is intrinsically superior.
The unchanging essentials
No matter how titles or scopes vary, there is a fixed set of work that has to happen for a product to succeed. These four phases are the constant.
| Phase | Goal | Core activities |
|---|---|---|
| Planning | Enable the team to do its best work | User research, data analysis, project/product planning, marketing and operations planning |
| Design | Turn ideas into excellent experiences | Design planning, design execution, usability testing |
| Development | Build planned and designed ideas with technical quality | Development planning, frontend/backend engineering, QC/QA |
| Marketing and operations | Deliver the work to customers in a way that creates real value | Marketing execution, business operations, data analysis |
Whoever owns each activity, the phases themselves don’t change. A tiny startup goes through all four; a large product organization goes through all four. The compression and distribution differ; the work doesn’t.
Think of it like filmmaking. A low-budget indie film and a Hollywood blockbuster both require a script, cinematography, editing, and sound. One person can wear all four hats, or hundreds of people can split them across departments — but the steps themselves can’t be skipped. Product development has the same structural property.
The Product Manager’s Unique Position
Once you accept the spectrum and the four phases, one role stands out as structurally different from the others: the PM.
Product management occupies an unusual position in the org. Unlike most roles, the PM is held accountable for outcomes they cannot directly control.
Designers control their designs. Engineers control their code. What, exactly, does a PM control?
PMs influence decisions, but they rarely make them alone.
- They depend on engineers to assess feasibility and build the solution.
- They depend on designers to produce a usable interface.
- They depend on leadership to approve resources and strategic direction.
- They depend on customers to validate that the solution actually solves the problem.
Every meaningful output the PM is responsible for is produced by someone else.
This dependency structure means PMs have to lead through influence rather than authority. The job isn’t to direct other people’s work — it’s to help other people succeed, and to succeed through them.
A useful analogy is a travel guide. A guide can’t order tourists around. But they can propose a route, share local knowledge, and solve problems when they come up — and by doing so, make the trip a good one. A great guide is the reason a group says, “that was the best trip I’ve ever taken.” A great PM is the reason a team ships the best product they’ve ever shipped, without ever issuing a command.
The “CEO behavior” anti-pattern
A common failure mode is the PM who acts like a CEO without having any of the actual authority. The phrase “CEO of the product” is often heard, and PMs sometimes take it literally — with predictable consequences. The pattern usually looks like this:
- Assigning work without context or resources. Telling the team to “just get started” before requirements are clarified or research is done.
- Avoiding direct problem-solving. When conflict arises or work gets stuck, waiting passively or escalating immediately, instead of having the direct conversation with the people involved.
- Blaming the team when things fail. Attributing project problems entirely to execution, without examining whether the strategy, requirements, or support were adequate.
These behaviors corrode trust and team cohesion. Worse, they block the feedback and collaboration that good product development depends on — which usually leads to a worse product, not just a worse team dynamic. The PM who claims CEO-style authority without doing CEO-style work tends to fail twice: at the relationships, and at the product.
Effective PMs treat their role as enabling the team’s success rather than commanding it. In practice, that means a set of concrete behavior shifts:
| Instead of… | Try this |
|---|---|
| Telling engineers what to build | Describe the problem and work on the solution together |
| Reviewing designs for approval | Share customer context so the designer can make good decisions |
| Setting deadlines unilaterally | Build the schedule collaboratively with realistic input from the team |
| Escalating problems when they arise | Resolve issues directly with the people involved |
When a project fails, the effective PM asks “what could I have done differently?” before examining anyone else’s contribution. This isn’t taking unfair blame. It’s maintaining the trust and psychological safety the team needs to do its best work — which is the only thing the PM can actually produce.
The right analogy here is a gardener. A gardener can’t order a flower to grow. They can prepare the soil, ensure enough sunlight and water, remove the weeds, and create the conditions for the plant to thrive on its own. PMs do the same for their teams. The work isn’t issuing commands. It’s building the environment in which good work becomes possible — and then trusting the team to do it.
Conclusion
The product manager role is best understood by separating three things: the title, the scope of work, and the underlying structural position. Titles vary widely across organizations. Scope sits on a spectrum from narrow to broad. But the essential work — planning, design, development, marketing and operations — doesn’t change.
What does change, for PMs specifically, is the relationship between responsibility and authority. PMs are accountable for outcomes produced by others. The failure mode is to compensate by acting authoritatively without the authority. The healthier path is to lead through influence: building shared context, removing obstacles, and creating the conditions in which engineers, designers, and the rest of the team can do their best work.
The next article in this series steps back to look at the product itself — viewing it as an organism rather than a collection of features, and tracing how decisions in one phase ripple through every other phase.
Leave a Reply