06:18
product management
Product management is "the art, science, and practice of making products successful," and a product manager's job is to define the product and orchestrate actions across the company toward that end — with success measured by some combination of product adoption, customer satisfaction, and revenue.
Doshi's core definition: product management is the art, science, and practice of making products successful.
The product manager's job, stated succinctly: define the product and coordinate/orchestrate actions across the company to make it successful.
Product success is measured via product adoption, customer satisfaction, and revenue; a given product doesn't need all three, but needs at least one, usually two, sometimes all three.
Common PM deliverables — running SQL, writing PRDs, running sprint meetings, writing stakeholder status updates — are all "actions," not the job itself, and PMs and even product leaders often get lost in these mechanics and forget the real job is product success.
Doshi rejects a rigid division of labor where a PM must own certain tasks and never touch others reserved for designers, program managers, or engineering managers.
The PM's day-to-day/week-to-week/month-to-month responsibilities should flex based on team structure, team strengths, and company culture in service of product success — e.g., Doshi sometimes delegated PRD writing to his engineering counterpart as he became more senior.
Forgetting that product success is the real job leads to poor decisions about time allocation, resource allocation, how you work with teammates, and which artifacts you're responsible for.
Earlier attempts at Stripe to define PM via long 2-3 page documents specifying what PMs, designers, tech leads, and engineering managers should each do failed to create real understanding across the company.
Doshi frames the definition's origin as a direct response to failed prior attempts: multi-page documents delineating role boundaries were written and circulated at Stripe but didn't work, which is what prompted him to compress it to three lines for John Collison.
He explicitly names the trap of conflating actions with the job: SQL, PRDs, sprint meetings, and status updates are called out one by one as things PMs "often" or "might" do without being the job's definition — a rebuttal to task-checklist views of the PM role.
The claim that a PM's responsibilities should be delegated based on team strength is backed by a concrete personal example (engineering counterparts writing PRDs) rather than left abstract, framed as something he did "especially as I became a senior product person."
The video's origin story ties the definition's authority to a specific institutional moment — created for John Collison while Stripe's product management function was still an unproven "experiment" only two years from being confirmed as a permanent bet.
«In my view, product management is the art, science, and practice of making products successful.»
— 01:46
«So the product manager's job is to define the product and to coordinate or orchestrate actions across the company to make the product successful.»
— 02:06
«product success is basically some version of product adoption and customer satisfaction and revenue.»
— 02:40
«A product manager's job is not to run SQL, even though they often run SQL queries. A product manager's job is not to write PRDs, even though they often write PRDs. A product manager's job is not to run the sprint meeting, even though they might run the sprint meeting. A product manager's job is not to write notes or send stakeholder status updates, even though they might do it. Those are all actions.»
— 03:21
«your real job is product success.»
— 03:57
«I've never believed in this rigid split of a product manager must do everything in this column and nothing in this column because the things in this other column a designer should do or a program manager should do or an engineering manager should do.»
— 04:50
Reception
Viewers found the video's definition of product management deeply resonant and worth revisiting, though a few pushed back with substantive debate over what 'defining the product' actually means.
The video is a tight, origin-story-backed distillation of one PM's outcome-first framework for the role, explicitly presented as Doshi's own hard-won view rather than an industry consensus, and it deliberately leaves the boundary question of who owns problem selection open — which the comment section then argues over.
06:18