The canonical public framework for product management scores user experience design. The canonical one for design scores product thinking. Neither document mentions that the other exists, and the region they are both quietly reaching into has since become the most valuable part of the map.
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.
Two documents, each crediting the other's discipline, neither acknowledging the other existed.
What the field has to work from
The published ones
Product has one framework the field actually argues about and very little else in public, which is why most product ladders in use are a competency list somebody wrote in a week.
The variation worth noticing is not a framework but a 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 and research all went to seven levels ending at VP, and engineering had seven named titles that were not levels at all, ending at the same word.
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.
And where a ladder stops a level short of its neighbor, as brand did, the drift runs one way. Moving toward the taller ladder reads as a promotion and moving toward the shorter one reads as a step down, regardless of what either person actually decides. That is a fact about the documents, not about the work.
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.
Same numbers, no exchange rate: PM5 and PD5 were both written as fifth levels, and nothing said whether they were the same job at the same price. Engineering’s titles could not be mapped onto either. That is a fact about the documents, not about the work.
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.
The same thing happened on the design side, faster. Writing the spec, framing the problem, deciding what not to build, prioritizing against a goal: all of that now sits between the two lanes rather than inside one. It is the most valuable region on the map and it belongs to nobody, which is why no ladder scores it.
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, not span. Not how much surface, but which decisions this person makes alone. A product manager who owns three products and cannot kill any of them owns nothing. The test is whether they can stop something without asking.
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.
The AI Daily Brief gave the surviving role a name this July: when prototypes are cheap and ideas are abundant, the decision rights move to the editor, the person who says which of the forty deserves to be built. That is a fair description of the top of this table.
I think the answer is narrower than most product managers would like and more durable than they fear. It is the judgment about which of the possible futures is worth this quarter, and the willingness to stop something that is working in order to do it. Everything else on the list is now shared, and pretending otherwise is how you end up with a product organization that is mostly coordinating people who no longer need coordinating.
The whole system
You can read the argument for free. Running it is the hard part.
An essay can tell you the six rows stopped working. It cannot sit in the room in November when two managers disagree about the same person and neither can say why. That is what the workbook is for: one shared core across Engineering, Product, Research and Design (EP(R)D), six levels defined by what a person decides, and the mechanics to grade against them without the cycle turning into a negotiation.
Six levels defined once, by what a person decides alone. The shaded band is the overlap, where most of the work now belongs to no single lane. The marks to the left of each cell are doors: a move sideways at the same level, which is a transfer and not a demotion.
Written to be opened during a cycle rather than read once: on the page, as a PDF set to print, and with the templates as a spreadsheet.
Define it
Grade against it
Run the cycle
Or read section two, free.
v1. The cycle, the calibration room and the evidence standard are the ones I have run at companies of 25, 250 and 2500 people; the six axes are new. One payment, every revision by email.
One of four, each taking a function through the same framework; the system they share is set out in full in the workbook. The others are on design, engineering and research. 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