When Larry Page reorganized Google into business divisions in 2011, Shishir Mehrotra, then running product for YouTube, was asked to set up the promotion process for product managers. The rubric he inherited measured one thing: scope. You moved up by owning a bigger area, from a feature to a product to a product line. It sounds reasonable until you watch it operate. As Mehrotra later described it, some groups had a single product like Search while others like Ads had fifty, so the fastest way to get promoted was to transfer onto a bigger team, not to get better at the job. Worse, the rubric punished anyone who took a small, risky, experimental bet. The scope you were handed decided your ceiling, and you did not choose the scope.
That problem is the one almost every product manager runs into around their third or fourth year, usually without a name for it. You are executing well. Your launches land. Your reviews are strong. And you are not moving. The uncomfortable answer is that the thing getting you good reviews and the thing that earns the next level are not the same thing, and most PMs spend years optimizing the first while waiting for the second to happen on its own.
Doing your job well keeps you at your level
Start with the part nobody says out loud in a one-on-one: execution quality is the price of admission, not the lever. Shipping clean, hitting dates, writing tight specs, keeping the team unblocked, all of it keeps you at the level you are at. It is necessary. It is not promotive. A PM who executes flawlessly inside a fixed scope has proven they can do the job they already have, which is a reason to keep paying them, not a reason to give them a bigger one.
Lenny Rachitsky’s widely read breakdown of how to get promoted lists seven strategies, and the two that do the heavy lifting are deliver more impact and take on more scope. Notice that neither one is “execute your current responsibilities better.” That is assumed. It is the floor. The question a calibration committee actually asks is not “did this person do good work” but “is this person already operating at the next level?” Those are different questions, and the gap between them is where careers stall.
This is why the most common piece of promotion advice, “just keep doing great work and it will be recognized,” is quietly false. Great work at your current altitude gets recognized with a good rating and a raise. It does not get recognized with a new level, because a new level is a bet on work you have not been assigned yet. Nobody promotes you into ambiguity they have never seen you handle.
What scope actually is
Here is the shift that makes the rest of this make sense. Scope is not how many features or how large a team you touch. Scope is how much of the problem you are handed versus how much you define yourself. Mehrotra’s framework for this, which he and his team built to fix the broken Google rubric, is called PSHE: Problem, Solution, How, Execution. It maps the PM ladder cleanly, and it is the most useful career tool I have seen in product because it describes growth in terms of what gets taken off your plate from the top, not what gets added at the bottom.
Handed the problem, solution, and how
The early-career PM is given almost everything. Here is the problem, here is the solution we have decided on, here is the plan and the milestones, now manage the execution. The job is real and hard, but the thinking has mostly been done upstream. You are judged on whether the thing ships well. Most APMs and new PMs live here, and the work genuinely teaches you how products get built.
Handed the problem and the solution
A step up, you are given the problem and the agreed solution, and you own the how. What are the milestones, what is the meeting cadence, which documents get written, how do the dependencies sequence, what is the plan when the plan breaks. The day-to-day looks similar to the rung below. The difference is that nobody hands you the plan anymore; you are the one who makes it.
Handed only the problem
Now it gets interesting. You are given a problem statement and nothing else. You define the solution: the target market, the candidate approaches, the pricing, the thing you will actually build and the three things you will not. This is roughly the Senior and Staff territory, and the leap is real. Defining the right solution to a well-posed problem is a fundamentally different skill than executing a defined one, and plenty of excellent executors never make this jump.
Handed a space
At the top, you are handed a space, not even a problem. “Payments.” “Retention.” “The small-business segment.” You come back with the problems worth solving and a case for why those and not others. This is where product leadership actually lives, and it is why Aakash Gupta’s career-progression guide describes senior individual contributors as the people who take on the company’s gnarliest, most ambiguous problems. Ambiguity is not a hazard of the senior job. It is the job.
Why your day looks identical while the job changes underneath you
Mehrotra’s team did something clever: they plotted every PM with the old scope measure on one axis and the PSHE level on the other. People clustered along a diagonal. Early and late in a career, growth showed up mostly as scope expansion, a bigger area. But in the middle, the bulk of the careers, growth was almost entirely vertical. The area you owned stayed roughly the same size. What changed was how much of the problem you were defining yourself.
He called that middle zone the Trough of Disillusionment, and the name is exact. Your day-to-day looks the same as it did a year ago. Same meetings, same team, same product surface. Under a scope-only rubric, you look stuck, and worse, you feel stuck, because the thing that is actually growing, how much ambiguity you are absorbing, is invisible to you and to the person writing your review. Most of the PMs who tell me they have plateaued are standing in this trough, mistaking a change in the nature of their work for a lack of progress.
I sat through enough promotion calibrations in two decades of IT operations leadership to watch this play out from the other side of the table. The pattern was always the same. The person everyone liked, who never missed, whose projects never caught fire, would come up and the room would go quiet, because there was nothing to argue about and nothing to point to either. Meanwhile someone messier, who had walked into an undefined mess and come back with a shape for it, had a story that made the case itself. Reliability kept people employed. Taking the undefined thing and defining it got them promoted. The flawless executor was, without knowing it, making the case that they were perfectly placed exactly where they were.
The uncomfortable catch: scope is given, not taken
There is a trap inside all of this, and it is the same trap that broke the original Google rubric. Mehrotra’s own line is that scope is an input, not an output. You do not get to simply decide you now own payments. Somebody assigns it. Which means the honest version of “take on more scope” is not “demand a bigger title.” It is “make yourself the obvious person to hand the next ambiguous problem to,” and then be visibly good at it before anyone has promised you anything.
That is the move. You operate one rung up the PSHE ladder inside your current role. If you are being handed problem, solution, and how, you start proposing the how before anyone asks, and you are right often enough that people stop writing the plan for you. Once you own the how reliably, you start poking at the solution: “we have been told to build X, but the data suggests the real problem is Y, and here is what I would build instead.” You take the ambiguous, unscoped thing nobody wants to own, the migration with no clear finish line, the segment nobody understands, and you bring back a defined shape.
Companies lean on exactly this when they decide. A leveling-up framework from Whatfix states the rule plainly: a level-up happens only after a person has proven they are already operating at the new scope. Promotion is retroactive. It ratifies a reality that already exists. Gupta’s guide puts the same point in a sentence worth taping to your monitor: titles and salaries are lagging indicators of impact, and the signal to watch is whether you are consistently performing at the next level before you officially hold it. The industry benchmark he cites for time-in-level is roughly 18 to 24 months, but the clock only starts counting once you are visibly doing the higher job, not once you have done your current one long enough.
Making the shift before the title catches up
If you are in the trough and tired of it, stop polishing the thing you are already good at. More execution excellence buys you a better rating and no new level, and I have watched strong PMs spend two extra years learning that the slow way. Three changes move the needle instead.
First, audit where you sit on PSHE for your current work, honestly. For your last three projects, how much of the problem, solution, and plan was handed to you versus defined by you? If the answer is “most of it was handed to me and I executed it beautifully,” you have found why you are not moving. The work was not wrong. It was just one rung below where you need to be operating.
Second, go find ambiguity on purpose. The instinct in the trough is to ask for a bigger, cleaner, better-defined project, because that feels like a promotion. It is a lateral move. The promotion is in the smaller, messier, undefined thing that the team keeps avoiding because nobody knows what “done” means. Owning that is how you demonstrate you can define a solution rather than just ship one, and it connects directly to the kind of invisible, hard-to-credit work that stalls careers when you do it quietly and accelerates them when you define it, name the outcome, and own it in public.
Third, make the vertical growth legible, because in the trough it is invisible by default. The person deciding your level cannot see that your work got harder; the surface looks identical. So you say it. Not “I shipped the feature” but “I was handed a vague retention concern and defined the problem, scoped three candidate solutions, killed two, and the one we built moved the number.” That sentence is a PSHE claim. It tells a calibration room you are already working a level up, which is the only argument that actually lands.
None of this is a trick to beat the system, and it is worth being clear about that, because the same honesty that makes feedback scarce as you get senior makes this hard to see on your own. The system is measuring something real. A senior PM genuinely is more valuable than a junior one, not because they work harder or ship more, but because you can hand them a vaguer problem and trust them to come back with the right answer. Promotion is the company recognizing that it already trusts you with more ambiguity than your title reflects. The flawless execution was never going to earn that on its own, because flawless execution of a defined task is, by definition, a demonstration that the task still had to be defined for you.
The PMs who get unstuck are not the ones who got better at their jobs. They are the ones who, quietly and before anyone asked, started doing a different one.