The Role and Scope of Responsibility of the Product Manager

Why we start from the premise that a PM is "not a mini-CEO"

The "mini-CEO" metaphor often used to describe a product manager emphasises the breadth of authority, but at the same time it blurs the actual boundaries of decision-making. A CEO holds the final authority over capital allocation and personnel, but a PM holds neither. What a PM does hold is the authority to decide "what problem this product should solve" and "which initiative to tackle first," while the allocation of the engineering and design resources that execute on it is the domain of engineering managers and design leads.

In his book INSPIRED, Marty Cagan writes that a PM's value lies not in the extent of their authority but in the ability to understand the three constraints of customer, technology, and business simultaneously, and to discern a product that is feasible, loved by users, and viable as a business. If you leave the locus of authority ambiguous and treat the PM as "the person who decides everything," the team concentrates responsibility on the PM, and as a result the PM themselves becomes a bottleneck.

The scope of responsibility a PM actually holds

What they do hold

What a PM is primarily responsible for can be organised into three things. First, defining problems and prioritising them. Second, designing the validation of whether an initiative will have an effect on both users and the business. Third, interpreting the metrics after release and proposing what to try next. None of these is so much about "deciding" as it is work closer to "assembling the material needed to decide, and making a proposal grounded in evidence."

What they do not hold

On the other hand, the evaluation and hiring of engineers, the selection of technical architecture, and the operational rules of the design system are, in most organisations, outside the PM's authority. Budget-execution authority, too, generally sits with the founders or the finance department, except at seed-stage startups. There are occasions when a PM has input on these, but that is overstepping, not a part of the job definition. The less a team has put its scope of responsibility in writing, the more easily this boundary breaks down.

Moving back and forth between discovery and delivery

A PM's week divides broadly into two modes. Discovery is the activity of validating "whether the thing we should build is right" cheaply and quickly through prototypes and user interviews. Delivery is managing the process of actually developing and releasing a validated idea. Cagan advocates a way of thinking called "dual-track agile" that runs these two in parallel, recommending that discovery for the next initiative proceed alongside the delivery sprints.

On teams where this back-and-forth is not happening, only delivery keeps turning, and the PM becomes fixed as a traffic controller for the backlog. When the time devoted to discovery effectively drops to zero, the PM's proposals come close to simply turning stakeholders' sudden ideas straight into tickets. The concrete approach to running user interviews is covered in Designing and conducting user interviews.

How the role changes with the company's stage

Early stage (before PMF)

Before reaching product–market fit (PMF), the bulk of the PM's work leans towards discovery. Rather than feature development, a greater share of the work goes into pinning down "whose problem, and which problem, are we solving," and it is not unusual for the founder themselves to double as the PM.

Growth stage

Once PMF begins to come into view, the focus shifts to metric design and roadmap prioritisation. Work increases around deciding, with a North Star Metric as the anchor, in what order to try multiple initiatives, and this is also the stage at which hiring dedicated PMs tends to advance.

Mature stage

Once the product grows to a scale that spans multiple business units, the PM comes to spend time, in addition to decision-making within their own product area, on coordinating alignment with other teams. In many organisations the balance shifts from new features towards paying down the debt in existing features and defending metrics (improvements that keep existing key metrics from dropping).

Common pitfalls

The most common misunderstanding is the case of hiring a PM as a "development schedule manager." In this case, neither the authority nor the time for discovery is granted, and dissatisfaction arises on both sides that "there is little the PM can actually decide, given the role." Conversely, concentrating too much authority in the PM has the side effect of lowering the sense of ownership among other functions, with engineers and designers adopting a "just build what we're told" posture. The scope of responsibility requires not only a job-description document but an operating practice of confirming, at each actual decision-making moment, which side is the final arbiter. That said, this boundary is not decided once on the org chart and then done with; it should be revisited according to the product's stage of growth.

Read next

The connection between vision and strategy is covered in Product vision, strategy, and roadmap: the differences and how they connect. For the concrete methods of conducting discovery, see Designing and conducting user interviews.