Product Builder Job Ladder: Four Fork-Ready JDs from L4 to Principal

The short version

A fork-ready four-level job description ladder for Builder PMs: Product Builder (L4, 4+ years), Senior Product Builder (L5, 6+ years), Staff Product Builder (L6, 9+ years), Principal Product Builder (L7, 12+ years). Five dimensions scale: scope, architecture decisions, mentorship, external voice, years of experience. The operating model does not scale. At every level, the Builder PM ships working prototypes (not specs), designs AI systems end-to-end, owns evals, reasons about cost and latency, validates with users not stakeholders. If you have no Builder PMs yet, hire a Senior first because they set norms. If you're starting a new pillar inside a larger org, hire a Staff. Principals rarely come in cold. Fix the operating model before hiring against the ladder.

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've written versions of this ladder inside four companies. The shape that works is remarkably consistent. Four levels. Same six sections each. The scope scales but the operating model does not.

Last week I published Sample Job Description: Product Builder at the Product Builder level. Enough people wrote in asking "what does this look like for a Senior?" or "how would I hire a Staff into this model?" that I decided to publish the whole thing.

So here it is. Four JDs. One ladder. All downloadable individually, or as a bundle.

Why a Single Job Description Isn't 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. For a full comparison of the old PM role and the Builder role side by side, see Old PM vs. Product Builder: The Ledger. For what hiring a Builder PM actually looks like in practice, see Hiring the Builder PM. A Product Builder is the person who owns one product area and ships a working prototype before the sprint starts. A Principal Product Builder is the person who sets the company's position on agentic systems and ships the flagship AI product that the rest of the org is measured against.

Calling both of those 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.

The first time I saw this go right was inside a team that had written four separate JDs at four separate levels. When we did calibration, we were comparing candidates to the JD for the level they were applying at, not to a generic PM archetype. The quality of the conversation changed overnight.

What Changes Between Levels

Five dimensions scale up. They are the spine of the ladder.

Scope. One feature or area → a cluster → a pillar → company strategy. This is the dimension most orgs get right. Every other dimension follows it or lags behind.

Architecture decisions. One workflow → a multi-system design → cross-team primitives that other PMs build on → company-wide standards. A Principal is not a Staff who does "more" architecture. A Principal sets the rules a Staff operates within.

Mentorship. None expected → reviews peers → sets the bar for Senior and Staff → mentors Staff and helps hire Principals. If your Staff Builder is not raising the craft of the Senior Builders around them, they are miscast.

External voice. None required → optional → encouraged → expected. A Principal who is not shaping how the market thinks about the category is underweighting half the job.

Years of experience. 4+ → 6+ → 9+ → 12+. These are floors, not ceilings. I have seen people level up one tier with half the typical years because their portfolio was the real signal. I have also seen 15-year PMs who did not belong above L5 because they had never built anything in AI.

What Does Not Change

The operating model. This is the part that keeps breaking in orgs that try to 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
• Validates with users, not stakeholders

If the org cannot support this operating model, the ladder will not produce the people it describes. Hiring a Staff Builder into a write-and-wait org does not give you a Staff Builder. It gives you a frustrated senior IC who leaves in twelve months.

Fix the operating model first. Then hire against this ladder.

Which Level Do You Hire First?

This is the question I get asked most often. Here's what I tell people.

If you have nobody in the role yet, hire a Senior Product Builder first. They can build, but they can also set the prototyping and eval norms that the Product Builders who come after them will learn from. A Product Builder as the first hire tends to replicate whatever the org's current norms are, which is exactly what you're trying to change.

If you are starting a new pillar inside a larger org, hire a Staff Product Builder. They need enough scope to shape the architecture from day one, and enough authority through craft to partner with engineering leadership on the technology bets.

Principal Builders are rarely first hires. The role assumes a team below them to raise and standards worth inheriting. Principals usually emerge internally or are hired in when the pillar already has two Staff Builders.

The Four JDs

Each file below is a complete, fork-ready JD. Same shape. Same operating model. Calibrated scope and signals per level.

The fifth file is the full ladder plus compensation guidance in a single markdown file. Drop it into a Notion page when you're calibrating an org or planning a new team.

Pick one and try it. If it feels wrong for your org, edit it. The ladder is a starting point, not a religion.

What To Do This Week

If you are a hiring manager, pick the level you are currently hiring for and replace your existing JD with the one below. Run the first three phone screens against it. Notice what changes in the quality of the candidate pool.

If you are a PM considering your next move, read the level above yours. 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 or VP, read the Principal JD. Ask yourself whether the operating model you have in place could actually support a Principal Builder. If not, that is this quarter's problem.