The last time I wrote a single Product Manager job description and tried to use it across an entire team, it caused six months of leveling confusion, two bad hires, and one very frustrated Staff IC who felt the job was beneath her. That was in 2021. I should have known better. Since then I have written versions of this ladder inside four companies, and the shape that works is remarkably consistent. Four levels. Same six sections each. The scope scales but the operating model does not.
Why a single JD is not enough
A single JD works when the scope of the role is small: one surface area, one reporting line, one set of tradeoffs. The Builder PM role is not that. A Product Builder owns one product area and ships a working prototype before the sprint starts. A Principal Product Builder sets the company's position on agentic systems and ships the flagship AI product the rest of the org is measured against. Calling both the same job is how you end up with bad hiring signals, broken leveling conversations, and senior ICs who leave because the role lost its ceiling.
What changes between levels
Five dimensions scale up, and they are the spine of the ladder. Scope goes from one feature to a cluster to a pillar to company strategy. Architecture decisions go from one workflow to a multi-system design to cross-team primitives to company-wide standards; a Principal is not a Staff who does more architecture, a Principal sets the rules a Staff operates within. Mentorship goes from none to reviewing peers to setting the bar to mentoring Staff and helping hire Principals. External voice goes from none to optional to encouraged to expected. Years of experience go 4+ to 6+ to 9+ to 12+, and these are floors, not ceilings.
What does not change
The operating model. This is the part that keeps breaking in orgs that run the ladder against a legacy PM culture. At every level, the Builder PM ships working prototypes not specs, designs AI systems end-to-end, owns evals, reasons about cost and latency as product decisions, and validates with users not stakeholders. If the org cannot support this, the ladder will not produce the people it describes. Hiring a Staff Builder into a write-and-wait org gives you a frustrated senior IC who leaves in twelve months. Fix the operating model first, then hire against this ladder.
The question I get most is which level to hire first. If you have nobody in the role yet, hire a Senior, because they set the norms the later hires inherit. If you are starting a new pillar inside a larger org, hire a Staff. Principals rarely come in as first hires; the role assumes a team below them and standards worth inheriting.
This week, if you are a PM considering your next move, read the level above yours and underline the three responsibilities you have not yet done. Those are the work you need to show in the next six months. If you are a CPO, read the Principal JD and ask whether your operating model could actually support one. If not, that is this quarter's problem.