Shreyas Doshi's definition of the product manager role: "to define the product and orchestrate actions across the org to enable its success." Three parts, in descending order of importance:
Whether someone is "doing the real PM role" depends on whether they're the primary person deciding what gets built — independent of job title. A PM-titled person who mostly orchestrates without defining the product is, in Doshi's framing, performing a project-manager role. Someone without the PM title who is primarily defining the product is doing the real PM job. Compare Cagan's Definition of a Product Manager and 'Product Owner' Should Never Be a Standalone Job Title.
Doshi treats "make the product win" and "make customers happy" as behavior-altering goals rather than synonyms: a PM who internally aims at product success will act differently day to day than one aiming at customer happiness, though he doesn't enumerate the specific behavioral differences. He frames common PM-role definitions — impact, customer happiness, problem-solving, customer obsession — as directionally useful but "not direct enough" proxies for the real goal. His definition of product success: "some combination of user adoption, user satisfaction, and unique business impact" — customer satisfaction survives as one input, not the goal itself. Compare Customer Obsession Over Stakeholder Deference.
Doshi says it took him almost ten years as a PM to reach this distinction, and that some PMs never do — positioning it as a hard-won personal realization rather than standard curriculum.
Doshi operationalizes product success as some combination of product adoption, customer satisfaction, and revenue. A given product doesn't need all three — usually at least one, often two, sometimes all three, depending on the product and its stage. This gives "orchestrate actions across the company" a concrete target: alignment is measured against adoption/satisfaction/revenue, not against completion of any specific deliverable.
Doshi draws a hard line between the PM's real job (making the product successful) and the day-to-day actions PMs are often seen doing: running SQL, writing PRDs, running the sprint meeting, writing stakeholder status updates. Each is explicitly named as something a PM "often" or "might" do, not the job itself — conflating the two is what leads PMs and even product leaders to misallocate time, resources, and team responsibilities.
The distinction has an origin story: an earlier attempt at Stripe to define the role via 2–3 page documents assigning specific tasks to PM/designer/tech-lead/engineering-manager columns was tried and failed to build real cross-company understanding. Doshi compressed the definition to three lines for John Collison instead, at a point when Stripe's product management function was still only two years from being confirmed as a permanent bet — the definition was forged to answer an open, existential question about the function, not written as settled doctrine.
The same underlying failure mode — assigning task ownership by role via an explicit matrix — is the shape of RACI (Role-Clarity Matrix) as Product-Team Anti-Pattern and DACI (Decision-Role Matrix) as Product-Team Anti-Pattern as product-team anti-patterns.
Because the job is the outcome (product success) rather than any specific action, Doshi rejects a rigid split where a PM must own certain tasks and never touch others reserved for designers, program managers, or engineering managers. Which actions a PM actually performs should flex with team structure, team strengths, and company culture — e.g., Doshi delegated PRD writing to his engineering counterpart as he became more senior, trusting the team's own strengths to sort out who does what in service of the shared outcome.
This parallels — but is distinct from — Misconception: PM Owns the 'What', Engineering Just Executes the 'How', which rejects a different rigid split (the "what" vs. the "how") for the same underlying reason: fixed task-to-role assignments crowd out flexing around actual team strengths.
Из тем: The Product Operating Model