The Product Manager Role
Ask ten people what a PM does and you'll get ten job descriptions. Here's mine, sharpened over a decade in B2C mobile: a product manager is accountable for the outcome of a product, and produces almost none of it directly. You don't design the screens, write the code, run the ad campaign, or close the sale. You are responsible for whether the thing works, for the business and for the user, and you get there through other people. Hold that contradiction in your head and most of the job starts to make sense.
#The "CEO of the product" myth
You'll hear the PM described as "CEO of the product," a line Ben Horowitz popularized, and I'd retire it. A CEO has authority. They hire, they fire, they allocate. A PM has none of that. What we share with a CEO is accountability without a hiding place: when the product fails, "engineering was late" is not an answer you get to give. So the comparison is half-right and a little dangerous, and it's the framing I push back on most with new PMs, because they hear "CEO" and start issuing orders instead of building the influence the job actually runs on (Leading Without Authority). I'd rather you think of yourself as the person who makes sure the right product gets built and that everyone knows why.
#What you actually do
The day-to-day and the quarter-to-quarter are different jobs, and conflating them is why PMs feel busy and unproductive at the same time.
Unblock the team. Clarify the spec when an edge case surfaces. Make the small decision that's holding up a build. Triage a bug against the roadmap. Sit in standup and listen for the thing nobody's saying. This is the daily work of delivery, and most of it is removing friction so engineers and designers can do their best work. If your calendar is wall-to-wall here, you're a high-functioning facilitator. Useful, but not yet steering.
Decide what's worth building and why. Run Continuous Discovery so you're solving real problems. Set and defend the roadmap. Connect the work to a measurable business outcome. Say no, repeatedly, to good ideas that aren't the best idea. This is where the leverage is, and it's the first thing that gets crowded out by the day-to-day.
The trap is that the execution loop is urgent and the outcome loop is merely important. Protect the outcome loop or you'll spend your career as a very efficient order-taker.
#Outcomes, not output
The single most important sentence in this Atlas: you are measured by outcomes, not output. Shipping ten features is output. Moving retention three points is an outcome. A team can ship constantly and change nothing, which is what a feature factory does. The whole point of the role is to be on the hook for the result, which is why I made Outcomes Over Outputs its own note and why it threads through every competency.
#The four areas, in one breath
What you're accountable for maps cleanly to The PM Competency Model. You execute (define, build, launch, the whole of Product Execution), you understand customers (Customer Insight), you set strategy (Product Strategy), and you influence people (Influencing People) to make all three happen. Four jobs in one. Nobody is equally good at all four, which is the point of The T-Shaped PM and Knowing Your Shape.
At the end of a quarter, can you point to an outcome you owned, name the trade-offs you made to get there, and explain why to anyone in the company? If yes, you're a PM. If you can only point to a list of things that shipped, you're running someone else's roadmap.
#Continue Reading
- Outcomes Over Outputs for the principle that decides whether you're doing this job or a different one.
- Product Manager vs Adjacent Roles for what the PM role is not, and the roles it gets confused with.
- The Four Big Product Risks for the cleanest model of what you're actually accountable for.
- Understanding Trade-offs for the core act underneath the whole role.
- What Is Product Management for the discipline-level definition this note sits inside.