Ravi Mehta’s product framework scores user experience design. The design ladder I ran scored product thinking. I owned both documents and did not compare them until years later. They were already describing the same work from opposite sides.
Ravi Mehta's product competency toolkit, built at Tripadvisor and the closest thing product management has to a canonical public framework, sorts twelve competencies into four groups: product execution, customer insight, product strategy, and influencing people. Sitting inside customer insight, alongside fluency with data and voice of the customer, is user experience design.
The ladder I inherited at Grammarly did the same thing more explicitly. It scored UI and UX expertise as its own competency, footnoted as required for anybody working on user-facing products, rising from partnering with a designer on mocks at the second level to running research projects unsupervised at the fifth.
Meanwhile the design ladder, in the same company, in the same year, listed product thinking as one of its twelve craft skills. I owned both documents, and did not read them side by side until long after either mattered.
The overlap was written into both ladders. The exchange rate between them was missing.
What the field has to work from
The published ones
Product has one independent framework the field actually argues about and a growing set of company systems published in full. The second group is useful because it shows what survives contact with hiring, reviews and management.
GitLab is a useful stress test because its framework is operational and candid about the mixture: competencies, KPIs, performance and growth all sit close together, while product leadership has its own job family. Wise makes the commercial connection unusually visible by publishing levels and location-specific salary bands together. The UK Government framework shows the opposite scale problem: a common capability language has to work across many departments and professions. All three give managers something concrete to run, and all three show why a level, a quarterly growth plan and a performance score need separate records. The other variation worth noticing is the naming argument: whether the job is a product manager who decides or a product owner who administers a backlog. Ladders that never settle it end up scoring the second job and paying for the first.
What product ladders actually measure
Strip the language and most product ladders measure three things: how much surface you own, how little supervision you need, and how far ahead you can see. Span, autonomy, strategy.
Span is the load-bearing one and it is the one that has aged worst. It counts features, then a product, then multiple products, then a line of business. It is a measure of territory, and territory made sense as a proxy when shipping anything took a quarter and owning more of it genuinely meant deciding more.
The autonomy row measures distance from your manager. Contributes ideas to the backlog, then owns the backlog with supervision, then without it. That ladder had six meaningful levels when a product team was fifteen people. On a team of seven senior people it has about three, and the rest is padding.
Neither row asks the question that actually separates product managers, which is what they will refuse.
The exchange rate problem
At Pitch I ran product, design and research as one organization: six product managers, about twenty-five product designers, a research team and an eight-person brand and marketing design team, all reporting up through me. Which meant the exchange-rate problem was not between two departments. It was inside one, and I was the person both ladders escalated to.
There is a mechanical failure here that nobody notices until somebody transfers. At Grammarly, two years earlier, product management, product design, brand design, research and engineering all used seven abbreviated levels ending at VP. The numbers looked comparable; the documents never said that they were.
So a PM5 and a PD5 were not the same thing, nobody could tell you what the exchange rate was, and compensation bands hung off both. When a designer wanted to move into product, or a product manager into design, the conversation had no arithmetic in it. It was resolved by whoever argued better, which is a bad way to make a pay decision.
Brand stopped one level below the neighboring ladder. A move toward the taller document then looked like a promotion; a move toward the shorter one looked like a step down. The person’s authority could stay exactly the same while the paperwork changed their status.
No exchange rate
Four ladders in the same company, in the same year, and no statement anywhere of how a level in one related to a level in another. Compensation bands hung off all of them. Nobody could tell you what a PM5 was worth in design terms, and the question came up every time somebody wanted to move.
PM5, PD5, UXR5 and ENG5 all carried the number five. The documents never said whether the number represented comparable authority or pay. Engineering also switched from IC to management titles halfway up the line.
What the merge did to the role
The interface between product and engineering used to be an estimate. A product manager described what they wanted, an engineer priced it, and the negotiation between those two numbers was most of the job. A large part of the product ladder is really a measure of how well somebody runs that negotiation.
A product manager who can read the schema and run the query does not need an engineer to price the decision. An engineer who can see the funnel does not need a product manager to justify one. The estimate conversation has largely collapsed into the work, and with it a good chunk of what the middle levels of the ladder were measuring.
Design crossed the boundary even faster. Designers now write specs, frame problems and prioritize against goals as part of the work. Product managers prototype and test interface decisions. The ladders still treat this shared territory as somebody else’s craft, so neither one scores it well.
Product and Design
This one was already true on paper. What changed is that a designer can now produce and test the artifact that used to require a product manager to schedule it.
Product and Engineering
The estimate conversation, which was most of the interface between these two lanes, has largely collapsed into the work.
Read down the middle of both bands and almost nothing in there is a craft skill. The shared region is made of judgment, which is exactly what span and autonomy were never measuring.
What I would score instead
Decision rights. List the decisions this person makes alone. A product manager may cover three products and still lack the authority to stop any of them. Surface area is workload; the ability to end an investment is authority.
Opinions held. The scarcest thing in product work is somebody who will say what should exist and be judged for saying it. Not a prioritization framework, not a well-run process. A position, held when holding it cost time or scope or goodwill, that the company can name.
Judgment density. Whether the room decides faster because they are in it. The product manager who runs an excellent process and generates options indefinitely is adding capacity, not decisions, and those are different levels.
Range across the boundary. Which calls are they trusted to make in engineering's lane or design's? Querying your own data is now the floor, not a credit. Being the person engineering routes a sequencing question to is a level.
And what survives them. A product manager at the higher levels is not remembered for what they shipped. They are remembered for what the product refuses to do, and whether that refusal held after they left.
The six axes, in product’s language
Three of the six levels. Note that none of them mention how many products a person owns.
Read the P4 column and every cell is a refusal with a cost. That is the level most product ladders cannot see, because span and autonomy both rise while a person refuses nothing.
The uncomfortable part
If the shared region between product and design is problem framing, prioritization, data fluency, spec writing and deciding what not to build, then a fair question is what is left that is distinctly product.
Boris Cherny’s original post and replies describe several maker temperaments in teams that use agents. Product work increasingly resembles editing: deciding which of forty plausible prototypes deserves another week and which should end now.
The distinctly product decision is narrower than the old ladder suggests: which possible future deserves this quarter, and what currently working thing should stop to fund it. Much of the surrounding execution is now shared. Product earns its place by making that choice, not by coordinating work other people can already do.
Take the product argument into calibration
Grade the decisions Product keeps—not the neighboring craft it borrowed.
The Leveling workbook separates Product’s own decision rights from the design, research and engineering work around them. A shared six-axis core makes the overlaps comparable without pretending the lanes are identical, and the templates carry that distinction from evidence gathering through calibration.
One of five essays taking a function through the same framework; the system they share is set out in full in the workbook. The others cover design, engineering, research and marketing. Written from having inherited, run and rebuilt leveling and review cycles at three companies of very different sizes, and against the public frameworks that preceded them: the levels framework in Org Design for Design Orgs by Peter Merholz and Kristin Skinner, Rent the Runway’s engineering ladder, and Ravi Mehta’s product competency toolkit. Figures from the AI in Design Report 2026 and Figma’s State of the Designer 2026.
© 2026 Renato Valdés-Olmos